Bug 1126007 - Latest YAST update trashes hard drive - reproducible
Latest YAST update trashes hard drive - reproducible
Status: NEW
Classification: openSUSE
Product: openSUSE Distribution
Classification: openSUSE
Component: Bootloader
Leap 15.0
x86-64 Other
: P5 - None : Critical (vote)
: ---
Assigned To: Jiri Srain
Jiri Srain
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2019-02-20 00:58 UTC by aaaaaaaaaaa aaaaaaaaaaa
Modified: 2019-12-30 15:29 UTC (History)
2 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---
jsrain: needinfo? (guy)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description aaaaaaaaaaa aaaaaaaaaaa 2019-02-20 00:58:56 UTC
My current system has windows 10 and 8 Linux distros installed; all in primary partitions.

My partitioning tool and boot manager is Boot It Bare Metal (BIBM) and the disk is EMBR. This MBR system is in the public domain, IIRC.

For all my Linux installs, I always create my partition first and make it active so the installer sees it. I say "partition" as I use a common swap partition for all my distros.

I always install the bootloader to /dev/sda1. IIRC, openSUSE surprisingly defaults to this location.

Over many openSUSE versions and over 3 PCs, whenever grub has been upgraded, I have had to reactivate my bootloader by a simple reinstall and my boot menu and all partitions were present and correct. I have had to do this as after a grub upgrade, my PC would boot straight into openSUSE.

The other day, I upgraded Tumbleweed by running "zypper dup" without issue.

I then proceeded to update Leap 15 by running YAST as usual. After, the PC booted to Leap so I attempted to reactivate BIBM. Instead of being presented with the usual menu, found I was being presented with all the steps of a fresh install. Examining my drive revealed that *all* my partitions had disappeared and only that of Leap 15 remained. I restored the previous night's backup and the same thing happened again.

I have been using openSUSE since v11 and this caught me totally by surprise.

I am happy to try to help you get to the bottom of this.
Comment 1 Jiri Srain 2019-02-20 08:43:43 UTC
What does mean "running YaST as usual"? Can you provide the YaST logs?

During the upgrade process, YaST should not touch partitioning at all.

https://en.opensuse.org/openSUSE:Report_a_YaST_bug
Comment 2 aaaaaaaaaaa aaaaaaaaaaa 2019-02-20 15:22:29 UTC
Hi,

"Running YAST as usual" = Loading YAST, enter admin password, select online update and select all suggestions.

I do not have any logs available. I would have to trash my hard drive again and then go through a 90 min restore of my backup. It will be a few days before I can do this. Would any of my past logs be of any use before I go to the extreme measure above? In the past when grub has been updated, by bootloader has been affected as if the update was not installed into  /dev/sda1.

Could you please tell me exactly which logs you would like as https://en.opensuse.org/openSUSE:Report_a_YaST_bug seems to ask for a lot. As I think that grub updating is the issue I may just install that one its own and see what happens.

Cheers
Comment 3 Ladislav Slezák 2019-02-20 16:42:11 UTC
BTW what does it mean "update trashes harddrive"? Files are lost? Partitions are lost? Disk is zeroed? ???

(In reply to aaaaaaaaaaa aaaaaaaaaaa from comment #0)
> My current system has windows 10 and 8 Linux distros installed; all in
> primary partitions.
> 
> My partitioning tool and boot manager is Boot It Bare Metal (BIBM) and the
> disk is EMBR. This MBR system is in the public domain, IIRC.

I'm afraid that this setup is unsupported, if you use your own boot manager and partitioning scheme you have to manage and update it yourselves.

(In reply to aaaaaaaaaaa aaaaaaaaaaa from comment #2)
> Hi,
> 
> "Running YAST as usual" = Loading YAST, enter admin password, select online
> update and select all suggestions.

The YaST online update only updates the RPM packages, nothing more. 

> In the past when grub has been updated, by bootloader has been affected
> as if the update was not installed into  /dev/sda1

I'm a bit puzzled, I'm not familiar with BIBM, but if you use your own boot manager why you use grub in openSUSE? Should it boot openSUSE directly? Where you install the openSUSE bootloader (grub)? To the root partition?

> I do not have any logs available. I would have to trash my hard drive
> again and then go through a 90 min restore of my backup.

I have no idea how to debug this. The only thing which might affect the disk is updating the grub package. 

> As I think that grub updating is the issue I may just install that one
> its own and see what happens.

I'd suggest to lock the grub packages in the package manager so it is not updated. If the system boots fine then you probably can live with an outdated bootloader. Or you could try installing the updates one by one and see where it breaks exactly.
Comment 4 aaaaaaaaaaa aaaaaaaaaaa 2019-02-20 17:12:19 UTC
(In reply to Ladislav Slezák from comment #3)
> BTW what does it mean "update trashes harddrive"? Files are lost? Partitions
> are lost? Disk is zeroed? ???

The answer is in my original post. In short, only the openSUSE partition remains, my MBR has been totally wiped and 9 partitions lost.

> (In reply to aaaaaaaaaaa aaaaaaaaaaa from comment #0)
> > My current system has windows 10 and 8 Linux distros installed; all in
> > primary partitions.
> > 
> > My partitioning tool and boot manager is Boot It Bare Metal (BIBM) and the
> > disk is EMBR. This MBR system is in the public domain, IIRC.
> 
> I'm afraid that this setup is unsupported, if you use your own boot manager
> and partitioning scheme you have to manage and update it yourselves.

Every other distro, including Tumbleweed, works 100%. I have lost count of the distros I have installed, that worked fine, that I have chosen not to keep. That is without getting into Windows version and other esoteric OSs that I have installed. I was attempting to support openSUSE and give back to the project by being helpful in trying to fix an issue that Leap only has. When installing a distro, it only sees the partitions that I allow it to, which is sda1 and the swap partition, sda2. I am NOT doing anything unsupported as far as the installer is concerned. If it is not supported, then fine. There are other distros. 

> 
> (In reply to aaaaaaaaaaa aaaaaaaaaaa from comment #2)
> > Hi,
> > 
> > "Running YAST as usual" = Loading YAST, enter admin password, select online
> > update and select all suggestions.
> 
> The YaST online update only updates the RPM packages, nothing more. 

It installs grub and that is likely where the issue is. Other distros, when updating grub, actually present a dialogue asking me to confirm where I would like it installed.

> > In the past when grub has been updated, by bootloader has been affected
> > as if the update was not installed into  /dev/sda1
> 
> I'm a bit puzzled, I'm not familiar with BIBM, but if you use your own boot
> manager why you use grub in openSUSE? Should it boot openSUSE directly?
> Where you install the openSUSE bootloader (grub)? To the root partition?

I have always understood that Linux needs a bootloader, viz grub these days to boot. I install it to the root partition.
 

> I'd suggest to lock the grub packages in the package manager so it is not
> updated. If the system boots fine then you probably can live with an
> outdated bootloader. Or you could try installing the updates one by one and
> see where it breaks exactly.

I do not like computers to win and do not like to leave issues unsolved.

Cheers
Comment 5 Josef Reidinger 2019-12-30 15:29:36 UTC
(In reply to aaaaaaaaaaa aaaaaaaaaaa from comment #4)
> (In reply to Ladislav Slezák from comment #3)
> > BTW what does it mean "update trashes harddrive"? Files are lost? Partitions
> > are lost? Disk is zeroed? ???
> 
> The answer is in my original post. In short, only the openSUSE partition
> remains, my MBR has been totally wiped and 9 partitions lost.

That is strange as only think that can potentially do it is mis-configuration that write legacy generic MBR boot code to MBR table.

> 
> > (In reply to aaaaaaaaaaa aaaaaaaaaaa from comment #0)
> > > My current system has windows 10 and 8 Linux distros installed; all in
> > > primary partitions.
> > > 
> > > My partitioning tool and boot manager is Boot It Bare Metal (BIBM) and the
> > > disk is EMBR. This MBR system is in the public domain, IIRC.
> > 
> > I'm afraid that this setup is unsupported, if you use your own boot manager
> > and partitioning scheme you have to manage and update it yourselves.
> 
> Every other distro, including Tumbleweed, works 100%. I have lost count of
> the distros I have installed, that worked fine, that I have chosen not to
> keep. That is without getting into Windows version and other esoteric OSs
> that I have installed. I was attempting to support openSUSE and give back to
> the project by being helpful in trying to fix an issue that Leap only has.
> When installing a distro, it only sees the partitions that I allow it to,
> which is sda1 and the swap partition, sda2. I am NOT doing anything
> unsupported as far as the installer is concerned. If it is not supported,
> then fine. There are other distros. 

Hmm, TW and Leap share its source code, so it should be same code executed. If distro can see only partitions that you allow, then it is strange for me, how it can wipe it out for you when access is restricted. To be honest I never met BIBM before.

> 
> > 
> > (In reply to aaaaaaaaaaa aaaaaaaaaaa from comment #2)
> > > Hi,
> > > 
> > > "Running YAST as usual" = Loading YAST, enter admin password, select online
> > > update and select all suggestions.
> > 
> > The YaST online update only updates the RPM packages, nothing more. 
> 
> It installs grub and that is likely where the issue is. Other distros, when
> updating grub, actually present a dialogue asking me to confirm where I
> would like it installed.

In opensuse it remembers during installation where it is installed and update of grub refresh location selected during install.
You can find that location in /etc/default/grub_installdevice

> 
> > > In the past when grub has been updated, by bootloader has been affected
> > > as if the update was not installed into  /dev/sda1
> > 
> > I'm a bit puzzled, I'm not familiar with BIBM, but if you use your own boot
> > manager why you use grub in openSUSE? Should it boot openSUSE directly?
> > Where you install the openSUSE bootloader (grub)? To the root partition?
> 
> I have always understood that Linux needs a bootloader, viz grub these days
> to boot. I install it to the root partition.

In fact linux needs something that loads its kernel respective initrd. You can use whatever you want to load that and one of option is grub2 which opensuse supports in installation, but of course you can use different ones and then simple select in installer "none" bootloader. Which means I will manage loading initrd myself.

>  
> 
> > I'd suggest to lock the grub packages in the package manager so it is not
> > updated. If the system boots fine then you probably can live with an
> > outdated bootloader. Or you could try installing the updates one by one and
> > see where it breaks exactly.
> 
> I do not like computers to win and do not like to leave issues unsolved.

well, if you do not like workarounds I worry then it needs to be debugged with help of snapshots what is done wrongly in your specific case.

> 
> Cheers