[Bug 915098] New: yast2 does not reinstall the bootloader
http://bugzilla.suse.com/show_bug.cgi?id=915098 Bug ID: 915098 Summary: yast2 does not reinstall the bootloader Classification: openSUSE Product: openSUSE 13.1 Version: Final Hardware: x86-64 OS: Linux Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: jsrain@suse.com Reporter: ohering@suse.com QA Contact: jsrain@suse.com Found By: --- Blocker: --- I replaced the built-in 1.5TB hard disk with a new 2TB harddisk. The partition content was copied with rsync from the old paritions to the new partitions. I adjusted all relevant settings in /etc/fstab, /etc/grub.conf, /etc/default/grub_installdevice, /boot/grub2/device.map, /etc/sysconfig/bootloader, /etc/default/grub to match the LABEL and /dev/disk/by-* of the new 2TB disk. Then I started yast2 to let it update /boot/grub2/grub.cfg, /boot/grub2/grubenv and to reinstall the bootloader on the 13.1 parition. But all it does is to redo grub.cfg and grubenv. It did not install the bootloader into the root partition. As a result chainloading the given root partition fails. Maybe I just missed the knob to reinstall grub2, instead of just regenerating its runtime config files? Will try again with the Factory partition now. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 Jiri Srain <jsrain@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jreidinger@suse.com Flags| |needinfo?(jreidinger@suse.c | |om) --- Comment #1 from Jiri Srain <jsrain@suse.com> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #2 from Olaf Hering <ohering@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #3 from Olaf Hering <ohering@suse.com> --- Created attachment 621159 --> http://bugzilla.suse.com/attachment.cgi?id=621159&action=edit bug915098-13.1.tar.xz some logs from 13.1. Last run is around '2015-01-18 09:20'. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #4 from Olaf Hering <ohering@suse.com> --- And Factory behaves the same. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #5 from Jiri Srain <jsrain@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #6 from Olaf Hering <ohering@suse.com> --- Does 'grub --batch < /etc/grub.conf' or its grub2 equivalent really take that much time? I doubt that. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 Josef Reidinger <jreidinger@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(jreidinger@suse.c | |om) | --- Comment #7 from Josef Reidinger <jreidinger@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #8 from Olaf Hering <ohering@suse.com> --- (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 are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 Jiri Srain <jsrain@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jsrain@suse.com Assignee|jsrain@suse.com |wimer@suse.com --- Comment #9 from Jiri Srain <jsrain@suse.com> --- 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? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #10 from Olaf Hering <ohering@suse.com> --- (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? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #11 from Josef Reidinger <jreidinger@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #12 from Kenneth Wimer <wimer@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #13 from Josef Reidinger <jreidinger@suse.com> --- (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 :) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #14 from Olaf Hering <ohering@suse.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 --- Comment #15 from Kenneth Wimer <wimer@suse.com> --- (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?) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 Joachim Werner <joe@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joe@suse.com --- Comment #16 from Joachim Werner <joe@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.suse.com/show_bug.cgi?id=915098 http://bugzilla.suse.com/show_bug.cgi?id=915098#c17 Tomáš Chvátal <tchvatal@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #17 from Tomáš Chvátal <tchvatal@suse.com> --- 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 -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com