I have been using openSUSE, both versions for many years and have never had any issues of any significance.
My current system has Win 10 and 8 Linux distros installed, all in primary partitions. I have been used to Leap installing the bootloader, when updating it, into the MBR of the hard drive instead of the root of the partition, over-writing my chosen boot manager. It is easy from which to recover, by just reinstalling my bootloader again.
However, today, running YAST 2 totally hosed my hard drive losing all my partitions and I am now running my second full drive restore (I ran YAST a second time to see if I had missed something).
I am more than happy to try to help you resolve this, but it is quite alarming that Tumbleweed is much better behaved.
To all you multibooters out there, BACKUP NOW! I backup daily and was caught unawares by this strange behaviour.
You should tell Yast bootloader to boot from the partition containing “/boot”. Then it won’t overwrite the MBR.
That’s what I use on my laptop, and it has been working fine for years.
However, today, running YAST 2 totally hosed my hard drive losing all my partitions and I am now running my second full drive restore (I ran YAST a second time to see if I had missed something).
I have not yet updated my laptop. But I’m not expecting problems.
I did update another system, but that uses UEFI booting, so probably would not be affected by this bug (if there is a bug).
I am more than happy to try to help you resolve this, but it is quite alarming that Tumbleweed is much better behaved.
As far as I know, the writing of bootloader code to the disk is done by grub2-install. And I don’t think there’s any important difference between the Leap 15.0 version and the Tumbleweed version.
I’m wondering if something is failing in your hard drive.
As I said in my OP, I have been using openSUSE for years and I have been multibooting since my win98 days when PartitionMagic was king. I have never failed to recover from openSUSE writing to the disk’s MBR before. Why it cannot install itself to it’s current location, viz dev/sda1, is beyond me. Only openSUSE Leap has this “feature”. Before updating Leap 15, I updated my Tumbleweed install (zypper dup) and that went perfectly. One does not have the option to direct where grub installs itself (unlike my other distros do) with openSUSE AFAICT, it just always used the drive’s MBR. In the past, a simple reinstall of my boot manager (Boot It Bare Metal) was all that was necessary.
The issue is totally reproducible. My drive is a brand new Samsung SSD and I have no reason to suspect it at this stage. The issue will only come to light when other multibooters using other bootmanagers other than grub update.
When I install I can direct where grub is installed, but whenever it gets updated via YAST it replaces my bootmanager in the MBR. It has been behaving this way for years. None of my other 7 distros, including Tumbleweed, does this. I usually have not distros installed, but had a cull recently.
Looks like this time it trashed the partition table as all my partitions had gone when I examined the drive before restoring. I always install grub into “/” of each Linux partition.
I have never seen that happen. For me, it has always remembered where grub is installed. The file “/etc/default/grub_installdevice” keeps track of that.
That is both weird and interesting! That has been happening to me since going back to at least v11 and over three different PCs! I do not use a separate /boot and always install into the root of /dev/sda1. Anyway, unless somebody from openSUSE shows an interest in this issue or can shed any light on it, I will have to remove Leap 15 from my system and stay with Tumbleweed.
Hi, multibooting here since maybe openSUSE 10.x on both MBR and UEFI and never seen something similar.
On MBR I usually have the openSUSE GRUB manage booting, during install I tick “Install generic code to MBR”, then the actual bootloader is installed on the openSUSE / root partition and I make sure that the “Probe foreign OS” flag is ticked.
With recent versions it is indeed possible that installing the full bootloader directly into the MBR with several boot options exceeds the maximum room for MBR on some disks (those with sector size of 512 bytes IIRC) and possibly overwrite the partition table.
I never mix and match bootloaders from different distros on the same disk, so cannot comment on possible dangerous interactions.
When Installing a Linux distro, I never choose to install anything to the MBR and always install grub into the /root partition, which is always /dev/sda1 as each distro sees it. The only thing common to all my distros is the swap partition.
Nothing left out. The other day I did a “zypper dup” on Tumbleweed without issue. Straight after, did a full update of Leap 15, in exactly the same way as always, with the results described above.
My setup is different to everybody who has posted so far so I am not surprised that they do not have the issue. I do not use a separate /boot partition and grub never gets installed in my MBR by choice…ever. Not much more to say really.
On Tue, 19 Feb 2019 13:54:12 +0000, DrTeeth707 wrote:
> The issue is totally reproducible.
Please submit a bug to bugzilla.opensuse.org with the specific steps
needed to reproduce - that’s the way to get someone to dig into it to
figure out what’s going on.
The options are grub to MBR, grub to the partition containing /boot and optional generic to MBR. (does not need to be separate ). If you already of generic or other code in MBR do not install generic when installing. Note it may default to that since something must be in MBR