[opensuse] Leap 42.2 overwrote Win10 mbr on /dev/sda on grub update for SuSE on /dev/sdb
All, This was somewhat disturbing. I have 2 drives in my laptop, win10 on /dev/sda and Leap 42.2 on /dev/sdb. I boot either by selecting the drive I want to boot with the quick select bios boot option (e.g. press F9, the select hd1, hd2 of network boot) A couple of days ago, there was an update to grub2, and whatever hook is in place forced a grub reinstall. The problem is that grub installed to /dev/sda (writing itself to my win10 drive, instead of writing itself to my opensuse drive). This was quite surprising when I next tried to boot win10. Thankfully, grub detected and set up a chain-load for win10, but the issue is -- why would it touch /dev/sda, when it was booted from and running on /dev/sdb. I was able to recover/remove grub from /dev/sda with a call to bootsect, but I want to prevent this from ever happening again. I suspect part of the problem was the original installation of grub2 by yast and the creation of the archaic /boot/grub2/device.map containing '(hd0) /dev/sda' during install. I have rewritten device.map to contain (hd1) /dev/sda (hd0) /dev/sdb What I need to know is "Are there any other hooks or defaults in the way opensuse calls `grub-install` following a grub2 update that would cause it to write to /dev/sda instead of the drive opensuse is running on?" (after that we can get to 'why in the heck did an update to grub require a grub-install on a working system to begin with?' there was no kernel update or any change that would warrant a reinstall of grub to the drive) -- 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 January 14, 2017 7:18:38 PM PST, "David C. Rankin" <drankinatty@suddenlinkmail.com> wrote:
All,
This was somewhat disturbing. I have 2 drives in my laptop, win10 on /dev/sda and Leap 42.2 on /dev/sdb. I boot either by selecting the drive I want to boot with the quick select bios boot option (e.g. press F9, the select hd1, hd2 of network boot) A couple of days ago, there was an update to grub2, and whatever hook is in place forced a grub reinstall. The problem is that grub installed to /dev/sda (writing itself to my win10 drive, instead of writing itself to my opensuse drive). This was quite surprising when I next tried to boot win10.
Thankfully, grub detected and set up a chain-load for win10, but the issue is -- why would it touch /dev/sda, when it was booted from and running on /dev/sdb. I was able to recover/remove grub from /dev/sda with a call to bootsect, but I want to prevent this from ever happening again.
I suspect part of the problem was the original installation of grub2 by yast and the creation of the archaic /boot/grub2/device.map containing '(hd0) /dev/sda' during install. I have rewritten device.map to contain
(hd1) /dev/sda (hd0) /dev/sdb
What I need to know is "Are there any other hooks or defaults in the way opensuse calls `grub-install` following a grub2 update that would cause it to write to /dev/sda instead of the drive opensuse is running on?"
(after that we can get to 'why in the heck did an update to grub require a grub-install on a working system to begin with?' there was no kernel update or any change that would warrant a reinstall of grub to the drive)
I've been watching the same complaints on a couple of other distros. Upshot: dual booting is a risky business. Any update of either side can nuke the other half. Something, most of the time, you can get it back working. I no longer do it. Ever. Separate single disks, or virtualbox. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
John Andersen composed on 2017-01-14 21:12 (UTC-0800):
dual booting is a risky business. Any update of either side can nuke the other half. Something, most of the time, you can get it back working.
It does not have to be that way.https://old-en.opensuse.org/Bugs/grub#How_does_a_PC_boot_.2F_How_can_I_set_u... still applies as well now as it ever did - make and keep the MBR on BIOS disksneutral, and Grub updating won't stomp out bootability of other installations.
I no longer do it. Ever. Separate single disks, or virtualbox.
All the Intel PCs I own that I know for a fact remain bootable are multiboot. Total count of Intel PCs I own that I know for a fact remain bootable is in excess of 30. Of these, only about 4 or maybe 5 have more than one mass storage device installed, of which two have two because using MD RAID and only have 3 or 4 installed operating systems. Average number of installed operating systems on Intel PCs I know for a fact remain bootable is well in excess of 12. None employ virtualization except eCS, which is used only for running DOS apps in video modes unsupported except by booting DOS directly from the hardware. All the Intel PCs I own that I know for a fact remain bootable have no version of Grub installed to any MBR. All have legacy PC MBR code installed, with boot initialized according to whichever primary is marked "active". All the Intel PCs I own that I know for a fact remain bootable do have at least one partition formatted EXT2 with Grub Legacy used as primary bootloader, at least for GNU distros, if not for every installation. openSUSE outnumbers all other operating systems combined on all my Intel PCs that I know for a fact remain bootable, while only about half have as many as one Windows installation, of which two are Windows 10, none 8.x, none 7, none Vista. Minimum number of openSUSE installations on any of my PCs is 3, but average count is well above that. cf. http://fm.no-ip.com/PC/install-doz-after.html -- "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
On 2017-01-15 06:12, John Andersen wrote:
On January 14, 2017 7:18:38 PM PST, "David C. Rankin" <> wrote:
I've been watching the same complaints on a couple of other distros.
Upshot: dual booting is a risky business. Any update of either side can nuke the other half. Something, most of the time, you can get it back working.
I no longer do it. Ever. Separate single disks, or virtualbox.
He has separate single disks. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
On 01/15/2017 03:26 AM, Carlos E. R. wrote:
I no longer do it. Ever. Separate single disks, or virtualbox. He has separate single disks.
Apparently not. He has multiple single disks, all of which are available for the trashing when grub is updated. -- After all is said and done, more is said than done.
On 01/15/2017 11:19 AM, John Andersen wrote:
On 01/15/2017 03:26 AM, Carlos E. R. wrote:
I no longer do it. Ever. Separate single disks, or virtualbox. He has separate single disks. Apparently not. He has multiple single disks, all of which are available for the trashing when grub is updated.
Yes and yes... :) That was the point. I have multiple single disks that are separate in the laptop. opensuse on /dev/sdb and win10 on /dev/sda. (Yes, we will eventually virtualize the win10 disk within linux, but I'm still kicking around whether to use virtualbox or KVM, (I've run vbox for years and years, but have recently been using KVM where there is hardware support, but I'm still making friends with all the Tap and VDE2 network bridge setup alternatives, etc.)) However, in the interim, there should be no reason why I can't spin both disks (well, sda is ssd), without having to worry about one overwriting the boot loader on the other. The problem is how the boot loader is being managed on Leap. If there is a change to the naming of the boot image, then a grub-mkconfig is required, but there is NEVER an excuse for updates to a running system triggering the INSTALL of a bootloader -- none. Whatever is doing this needs to be fixed. The system got booted somehow, and a `zypper up -r update` should not start writing to any MBR at all. (I take John's warnings to heart here -- that could scramble things royally, I just dodged the 'fried win10' bullet by virtue of a chainload entry and by the grace of god that bytes 3-63 in the MBR didn't prevent a win10 boot) The purpose of the post was to find out "What in opensuse Leap is triggering the 'grub-install' -- and how to prevent it from ever happening again?" I've straightened out the device.map file (the existence of which is dubious at best with grub2), but what are the other hooks in Leap that could trigger a `grub-install` and where can I get rid of them? I'll have more time this weekend to look, but if anybody else knows, I'd appreciate the knowledge. -- David C. Rankin, J.D.,P.E.
15.01.2017 06:18, David C. Rankin пишет:
All,
This was somewhat disturbing. I have 2 drives in my laptop, win10 on /dev/sda and Leap 42.2 on /dev/sdb. I boot either by selecting the drive I want to boot with the quick select bios boot option (e.g. press F9, the select hd1, hd2 of network boot) A couple of days ago, there was an update to grub2, and whatever hook is in place forced a grub reinstall. The problem is that grub installed to /dev/sda (writing itself to my win10 drive, instead of writing itself to my opensuse drive). This was quite surprising when I next tried to boot win10.
Thankfully, grub detected and set up a chain-load for win10, but the issue is -- why would it touch /dev/sda, when it was booted from and running on /dev/sdb. I was able to recover/remove grub from /dev/sda with a call to bootsect, but I want to prevent this from ever happening again.
I suspect part of the problem was the original installation of grub2 by yast and the creation of the archaic /boot/grub2/device.map containing '(hd0) /dev/sda' during install. I have rewritten device.map to contain
(hd1) /dev/sda (hd0) /dev/sdb
What I need to know is "Are there any other hooks or defaults in the way opensuse calls `grub-install` following a grub2 update that would cause it to write to /dev/sda instead of the drive opensuse is running on?"
Please show content of /etc/default/grub_installdevice.
(after that we can get to 'why in the heck did an update to grub require a grub-install on a working system to begin with?' there was no kernel update or any change that would warrant a reinstall of grub to the drive)
If you are not going to install updated grub, you can just as well lock it to prevent further updates. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 01/15/2017 12:17 AM, Andrei Borzenkov wrote:
Please show content of /etc/default/grub_installdevice.
(after that we can get to 'why in the heck did an update to grub require a grub-install on a working system to begin with?' there was no kernel update or any change that would warrant a reinstall of grub to the drive)
If you are not going to install updated grub, you can just as well lock it to prevent further updates.
$ l /etc/default total 64 drwxr-xr-x 2 root root 4096 Jan 14 20:50 . drwxr-xr-x 131 root root 12288 Jan 17 18:19 .. -rw-r--r-- 1 root root 2385 Oct 18 07:51 cdrecord -rw-r--r-- 1 root root 1757 Dec 28 19:50 grub -rw-r--r-- 1 root root 1392 Oct 28 14:18 grub.old -rw-r--r-- 1 root root 40 Dec 19 12:07 grub_installdevice -rw-r--r-- 1 root root 1757 Oct 18 05:10 nss -rw-r--r-- 1 root root 1870 Oct 7 12:52 passwd -rw-r--r-- 1 root root 1374 Jan 5 11:18 rmt -rw-r--r-- 1 root root 2197 Oct 18 07:51 rscsi -rw-r--r-- 1 root root 1210 Jan 5 11:18 star -rw-r--r-- 1 root root 313 Nov 30 07:18 su -rw-r--r-- 1 root root 118 Nov 7 13:48 useradd -rw-r--r-- 1 root root 1155 Oct 30 11:11 vm-install and $ cat /etc/default/grub_installdevice /dev/sda1 /dev/sda activate generic_mbr (WTF?) that shouldn't be there. Thank you Andrei. Why do we have such a file? That is dangerous as heck. -- 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 01/17/2017 08:41 PM, David C. Rankin wrote:
$ cat /etc/default/grub_installdevice /dev/sda1 /dev/sda activate generic_mbr
(WTF?) that shouldn't be there. Thank you Andrei. Why do we have such a file? That is dangerous as heck.
This seemed to have been brought to the devs attention 4+ years ago: https://lists.opensuse.org/opensuse-bugs/2012-08/msg02182.html -- 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 2017-01-18 03:41, David C. Rankin wrote:
and
$ cat /etc/default/grub_installdevice /dev/sda1 /dev/sda activate generic_mbr
(WTF?) that shouldn't be there. Thank you Andrei. Why do we have such a file? That is dangerous as heck.
Just for comparison, this is mine: cer@Telcontar:~> cat /etc/default/grub_installdevice /dev/disk/by-label/a_boot_2 cer@Telcontar:~> On another machine it doesn't exist: Isengard:~ # cat /etc/default/grub_installdevice cat: /etc/default/grub_installdevice: No such file or directory Isengard:~ # ls /etc/default/ cdrecord google-chrome grub grub.old nss passwd rmt rscsi star su useradd Isengard:~ # This machine failed to boot recently because the UEFI boot entry had changed, apparently, to an unbootable entry, after an update of many things by YaST. Coincidence or red herring, I don't know. On a third machine: cer@minas-tirith:~> cat /etc/default/grub_installdevice /dev/sda4 cer@minas-tirith:~> On another install of that same machine: cer@minas-tirith:~> cat /other/etc/default/grub_installdevice /dev/disk/by-uuid/768baa80-5273-4588-8084-13fae6e4dc56 cer@minas-tirith:~> This is not consistent: label, uuid, traditional device, nothing... -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
18.01.2017 06:15, Carlos E. R. пишет:
On another machine it doesn't exist:
Isengard:~ # cat /etc/default/grub_installdevice cat: /etc/default/grub_installdevice: No such file or directory Isengard:~ # ls /etc/default/ cdrecord google-chrome grub grub.old nss passwd rmt rscsi star su useradd Isengard:~ #
This machine failed to boot recently because the UEFI boot entry had
This file is not needed on EFI ...
This is not consistent: label, uuid, traditional device, nothing...
Well, apparently it follows changes in YaST over time.
On 2017-01-18 04:22, Andrei Borzenkov wrote:
18.01.2017 06:15, Carlos E. R. пишет:
On another machine it doesn't exist:
Isengard:~ # cat /etc/default/grub_installdevice cat: /etc/default/grub_installdevice: No such file or directory Isengard:~ # ls /etc/default/ cdrecord google-chrome grub grub.old nss passwd rmt rscsi star su useradd Isengard:~ #
This machine failed to boot recently because the UEFI boot entry had
This file is not needed on EFI
Ah, ok.
...
This is not consistent: label, uuid, traditional device, nothing...
Well, apparently it follows changes in YaST over time.
All those machines are either recently freshly installed with 42.2, or upgraded to 42.2 from 13.1. And in the upgrade case they both had grub 1 previously, so grub 2 was installed now. So, all of them had grub 2 installed less than a month ago. -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
18.01.2017 05:41, David C. Rankin пишет:
$ cat /etc/default/grub_installdevice /dev/sda1 /dev/sda activate generic_mbr
(WTF?) that shouldn't be there. Thank you Andrei. Why do we have such a file?
This is where YaST stores configured bootloader location. It has to keep it somewhere. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2017-01-18 04:21, Andrei Borzenkov wrote:
18.01.2017 05:41, David C. Rankin пишет:
$ cat /etc/default/grub_installdevice /dev/sda1 /dev/sda activate generic_mbr
(WTF?) that shouldn't be there. Thank you Andrei. Why do we have such a file?
This is where YaST stores configured bootloader location. It has to keep it somewhere.
I guess he means it is the wrong drive ;-) -- Cheers / Saludos, Carlos E. R. (from 42.2 x86_64 "Malachite" at Telcontar)
participants (5)
-
Andrei Borzenkov -
Carlos E. R. -
David C. Rankin -
Felix Miata -
John Andersen