[opensuse] Leap 42.2 overwrote Archlinux mbr on /dev/sda on grub update for SuSE install on /dev/sdb
SuSE Devs, I am Real Unhappy with fact that a 2nd update of grub2 on my laptop has overwritten the master boot record for the Archlinux install I had on /dev/sda when Leap is installed and boots from a completely separate drive (/dev/sdb). This is a follow-on post to a similar "Leap 42.2 overwrote Win10 mbr on /dev/sda on grub update for SuSE on /dev/sdb" Why can't grub keep its damn hands off disks that do NOT belong to it by default? Instead, it broke booting Arch by setting the incorrect initrd. The opensuse grub update set: initrd /intel-ucode.img causing a KERNEL PANIC on the next boot of Arch -- WTF? Well no wonder, the initrd for arch is: initrd /intel-ucode.img /initramfs-linux.img Why the hell are you touching the mbr on /dev/sda when the opensuse install is on /dev/sdb and boots EXCLUSIVELY from /dev/sdb without any chainload or syslinux call (my bios tells it to boot from the 2nd drive). What do we find in the new grub2 update? os-prober is run without any notice to the user on grub update (which is something that should ONLY RUN on distro INSTALL, not thereafter, and certainly NOT without express configuration *by the user* to initiate the chaos it is likely to cause depending on whether a USB device is also plugged in at the time of update. Now some misguided (but presumably well meaning) soul has included: GRUB_DISABLE_OS_PROBER="false" in /etc/default/grub guaranteeing that the havoc causing os-prober will run wild on each grub patch, update, or randomly triggered recompile by build service and start writing unwanted entries into grub.cfg and then for some bewildering reason writes the mbr to the wrong disk. (the GRUB_DISABLE_OS_PROBER entry was not present in /etc/default/grub before the update -- I have since changed it to "true") C'mon... You guys usually do such a good job, but this "Russian Roulette" grub update business has got to stop. An UPDATE of grub should NEVER write a bootloader to a device where one does not already exist. That is NOT an UPDATE of a bootloader -- that is a complete NEW INSTALL that should not be triggered on 'update'. Further, after the last update that thrashed the Win10 mbr, I expressly set grub_installdevice so that /dev/sda is NOT the grub_installdevice: # cat /etc/default/grub_installdevice /dev/sdb1 /dev/sdb activate generic_mbr However Leap still overwrote the mbr on /dev/sda ?? -- David C. Rankin, J.D.,P.E. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Wed, Feb 1, 2017 at 1:25 PM, David C. Rankin
SuSE Devs,
You are aware that it is user list, are not you? ...
Instead, it broke booting Arch by setting the incorrect initrd. The opensuse grub update set:
initrd /intel-ucode.img
causing a KERNEL PANIC on the next boot of Arch -- WTF?
Well no wonder, the initrd for arch is:
initrd /intel-ucode.img /initramfs-linux.img
Bug number, please. ...
# cat /etc/default/grub_installdevice /dev/sdb1 /dev/sdb activate generic_mbr
However Leap still overwrote the mbr on /dev/sda ??
Assuming nothing yet changed, please run https://github.com/arvidjaar/bootinfoscript and make RESULTS.txt available. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 02/01/2017 02:43 AM, Andrei Borzenkov wrote:
On Wed, Feb 1, 2017 at 1:25 PM, David C. Rankin
wrote: SuSE Devs,
You are aware that it is user list, are not you? ...
I'm sure he is aware. And Thanks to David for posting it here so that others can be forewarned to unplug our USB drives or take other actions to protect their secondary boot drive any time we update kernels etc. Sure, a bug report is in order. But users have to be protected in the meantime. -- After all is said and done, more is said than done. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
David C. Rankin composed on 2017-02-01 04:25 (UTC-0600): ...
Why the hell are you touching the mbr on /dev/sda when the opensuse install is on /dev/sdb and boots EXCLUSIVELY from /dev/sdb without any chainload or syslinux call (my bios tells it to boot from the 2nd drive). ...
Have you checked enough boots to be sure /dev/sda is always /dev/sda and not sometimes /dev/sdb after you've booted via a BIOS HD selection menu? Some BIOS have inexplicable memories and produce unexpected consequences when physical device order isn't intact at kernel load time. / specification in Grub and /etc/fstab by default are made via UUID nowadays, so boot will usually take place regardless whether the BIOS and the kernel are in sync as to which HD is which, if Grub is competently setup/installed to get a chosen kernel and initrd loaded. When one uses a BIOS boot menu to select a boot device, the first device isn't necessarily the same one that looking at motherboard ports and cables would lead one to believe is first, which is one of the reasons why alternatives to booting by device names were originally developed. If BIOS and kernel/disk driver are out of sync, Grub install device via device name, with perl and/or YaST as potential interlopers, AFAICT cannot necessarily produce the result expected by a human every time. -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrei Borzenkov
-
David C. Rankin
-
Felix Miata
-
John Andersen