Bug 915098

My guess: YaST only reinstalls bootloader if it is needed (it is not if you just e.g. change kernel parameters). Therefore you would need to touch some settings regarding where to install bootloader (its location).

Josef, can you, please, veryfy this judgement?

(In reply to Jiri Srain from comment #1)
> My guess: YaST only reinstalls bootloader if it is needed (it is not if you
> just e.g. change kernel parameters). Therefore you would need to touch some
> settings regarding where to install bootloader (its location).

But why would yast do that? If such thing happens during update of the kernel, thats fine. But if I go to YaST I expect the full run: generate proper grub.conf, generate proper grubenv, install grub to the configured location. For short, do everything required that the system could start. I see no knobs to force reinstall. And thats fine, there should be no such knob.

Created attachment 621159 [details]
bug915098-13.1.tar.xz

some logs from 13.1. Last run is around '2015-01-18 09:20'.

And Factory behaves the same.

That's not the expected behavior; we got in the past complaints that YaST writes more than necessary, which means that it takes longer than needed. That's why YaST modules were optimized to only write settings which have actually changed.

Does 'grub --batch < /etc/grub.conf' or its grub2 equivalent really take that much time? I doubt that.

Yes, jiri is right. Reason is that users complain, that they just want to edit some settings and it rewrite bootloader location, that they already replaced by something else and they do not want it. You need to change location to force writing new one.

Maybe yast can have something like force mode for repairing, that write everything even if it is already read as set.

(In reply to Josef Reidinger from comment #7)
> You need to change location to force writing new one.

Which location would that be? I mean, it will write to locations its not supposed to write to.

And running grub2-mkconfig already takes ages today, even with all knobs being off. So I think an unconditional run of 'grub --batch < /etc/grub.conf' or similar will cause no complain.

The response to such user complains there should be some hard profiling data, where the time is actually spent. Do such data exist already?

You saw other Josef's reason. And, shouldn't initrd be also recreated (and this really can be time consuming)?

I think that it is fair to expect that configuration files are in sync with what's already in the system. It's kind of weird that users adjust configuration manually and don't apply it the same way.

Anyway, to handle this use case: We can add an explicit option which will cause complete initialization as during bare-metal installation.

Ken, since you work on new mock-ups, could you, please, take this requirement into account?

(In reply to Jiri Srain from comment #9)
> You saw other Josef's reason. And, shouldn't initrd be also recreated (and
> this really can be time consuming)?

Why would the initrd need to be recreated? You mean the fallback root device? This is an was root=LABEL=whatever, so in my case its not required.

> I think that it is fair to expect that configuration files are in sync with
> what's already in the system. It's kind of weird that users adjust
> configuration manually and don't apply it the same way.

I did adjust everything with sed(1). What does the last sentence mean?

(In reply to Olaf Hering from comment #10)
> (In reply to Jiri Srain from comment #9)
> > You saw other Josef's reason. And, shouldn't initrd be also recreated (and
> > this really can be time consuming)?
> 
> Why would the initrd need to be recreated? You mean the fallback root
> device? This is an was root=LABEL=whatever, so in my case its not required.

But your case is not the only one and other users can complain

> 
> > I think that it is fair to expect that configuration files are in sync with
> > what's already in the system. It's kind of weird that users adjust
> > configuration manually and don't apply it the same way.
> 
> I did adjust everything with sed(1). What does the last sentence mean?

to be honest if you can use sed, then "grub2-install /dev/sda1" should be trivial for you. Yast is focused on users that do not know details and want just use computer and have easy way to setup stuff without too much knowledge.

Can't YaST just check to see if there is a bootloader installed at the given location and if not, reinstall it?

I would *really* like to avoid adding another button to this ui. Especially one to solve the problem of an advanced user who messed things up by hand and with the terminal. If the above solution is not possible, I would still not add a button to this ui. It is clearly an advanced user doing advanced things so they should simply finish their advanced task by hand.

How many users will this happen to? What kind of users are they? Simply adding more and more functionality to YaST to solve every possible use-case is making YaST unusable through complexity.

(In reply to Kenneth Wimer from comment #12)
> Can't YaST just check to see if there is a bootloader installed at the given
> location and if not, reinstall it?
> 

It is quite hard. I can detect if there is something that looks like grub2 code, but hard to quess if it will work and if it do exactly what expected.

> I would *really* like to avoid adding another button to this ui. Especially
> one to solve the problem of an advanced user who messed things up by hand
> and with the terminal. If the above solution is not possible, I would still
> not add a button to this ui. It is clearly an advanced user doing advanced
> things so they should simply finish their advanced task by hand.
> 
> How many users will this happen to? What kind of users are they? Simply
> adding more and more functionality to YaST to solve every possible use-case
> is making YaST unusable through complexity.

It is hard to say, but I think very limited amount of users, but if it happen to beginner, then he is in troubles, because without bootloader it is hard to play with pc :)

(In reply to Kenneth Wimer from comment #12)
> Can't YaST just check to see if there is a bootloader installed at the given
> location and if not, reinstall it?

The detection would take more time than to actually write the few bytes of first-stage bootloader unconditionally.

In the end its a matter of deciding what yast bootloader is supposed to do. IMO it should do everything required to get the thing booting.

One that works its time to optimize, based on profile data. And I doubt such optimizing would need any yast2 changes.

(In reply to Josef Reidinger from comment #13)
> (In reply to Kenneth Wimer from comment #12)
> > Can't YaST just check to see if there is a bootloader installed at the given
> > location and if not, reinstall it?
> > 
> 
> It is quite hard. I can detect if there is something that looks like grub2
> code, but hard to quess if it will work and if it do exactly what expected.
> 
> > I would *really* like to avoid adding another button to this ui. Especially
> > one to solve the problem of an advanced user who messed things up by hand
> > and with the terminal. If the above solution is not possible, I would still
> > not add a button to this ui. It is clearly an advanced user doing advanced
> > things so they should simply finish their advanced task by hand.
> > 
> > How many users will this happen to? What kind of users are they? Simply
> > adding more and more functionality to YaST to solve every possible use-case
> > is making YaST unusable through complexity.
> 
> It is hard to say, but I think very limited amount of users, but if it
> happen to beginner, then he is in troubles, because without bootloader it is
> hard to play with pc :)

A beginner user would not get into this situation to begin with. 

This should happen somehow magically in the background or not at all. If the auto-detection would take too long then I would suggest simply reinstalling it every time. A user would not do this very often so any complaints of it taking too long are not valid unless it takes a long time to reinstall (more than 30 seconds?)

I think this bug describes a very rare corner case, so I'd reject it as a WONTFIX.

It's a completely different story whether we should have something like a "disk replacement recovery tool" that takes care of the full migration from one disk to the other, including the grub2 setup and (re-)writing the bootloader.

Feel free to open a FATE request for that.

This version of openSUSE changed to end-of-life (EOL [1]) status. As such
it is no longer maintained, which means that it will not receive any
further security or bug fix updates.
As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
openSUSE, or consider the bug still valid, please feel free to reopen this
bug against that version, or open a new ticket.

Thank you for reporting this bug and we are sorry it could not be fixed
during the lifetime of the release.

[1] https://en.opensuse.org/Lifetime