Comment on a recent update involving the boot partition files

[randallrathbun]

To openSuse personnel who create updates:

A recent update involved files in the /boot area. However the update routine did NOT bother to check if the /boot partition was mounted, but it went ahead anyway and ran the dracut command to create a new initrd and other associated files, only when attempting to write this out, did it discover that the /boot partition was missing, and then popped an error message.

Unfortunately the damage was done, when rebooting the system, it could only come up to the GRUB> cli.

Using traditional methods such as mount root, mount boot, chroot, grub-install did NOT work.

Booting into the rescue mode did NOT work either.

Rerunning the upgrade choice only showed that some script was appending extra entries to the /boot/grub2/devicemap file, thus giving an error during the critical boot install.

Using a Knoppix disk did not work either, as the chroot command did not work correctly.

After using up over 3 hours of time, trying different methods, was success encoutered upon using the Boot Linux choice, and the quickly running the Yast2 boot manager routine, to rewrite the partition. It took manual labor to clean up the boot parameters in the manager routine also.

It is extremely important, when any update is run to the /boot partition to make sure FIRST that the partition is mounted, rather than to hurriedly run the updates as if everything was nominal.

This will prevent giving a bad image to the customer, with an unbootable system, of the OpenSuse software.

Thank you for taking note of this professional tip, to help insure that openSuse will continue to maintain a professional image.

[knurpht]

@randallrathbun

To openSuse personnel who create updates:

A recent update involved files in the /boot area. However the update routine did NOT bother to check if the /boot partition was mounted, but it went ahead anyway and ran the dracut command to create a new initrd and other associated files, only when attempting to write this out, did it discover that the /boot partition was missing, and then popped an error message.

Unfortunately the damage was done, when rebooting the system, it could only come up to the GRUB> cli.

Using traditional methods such as mount root, mount boot, chroot, grub-install did NOT work.

Booting into the rescue mode did NOT work either.

Rerunning the upgrade choice only showed that some script was appending extra entries to the /boot/grub2/devicemap file, thus giving an error during the critical boot install.

Using a Knoppix disk did not work either, as the chroot command did not work correctly.

After using up over 3 hours of time, trying different methods, was success encoutered upon using the Boot Linux choice, and the quickly running the Yast2 boot manager routine, to rewrite the partition. It took manual labor to clean up the boot parameters in the manager routine also.

It is extremely important, when any update is run to the /boot partition to make sure FIRST that the partition is mounted, rather than to hurriedly run the updates as if everything was nominal.

This will prevent giving a bad image to the customer, with an unbootable system, of the OpenSuse software.

Thank you for taking note of this professional tip, to help insure that openSuse will continue to maintain a professional image.

Hi. Eh, openSUSE has no personel. We’re a community run by volunteers. openSUSE also has no customers, only users, contributors. And it spells ‘openSUSE’, that’s our name.
But, you’re speaking of an unmounted /boot partition. If /boot lives on a separate partition, it should always be mounted unless someone with root access unmounted it. Can you explain why /boot was not mounted?

[dcurtisfra]

@randallrathbun

Using a Knoppix disk did not work either, as the chroot command did not work correctly.

If you were to boot an openSUSE installation DVD, you would notice that, there’s a selection item named “Rescue System”: <https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.trouble.html#sec.trouble.data.recover.rescue>.

@randallrathbun

This will prevent giving a bad image to the customer, with an unbootable system, of the OpenSuse software.

The openSUSE documentation contains instructions on how to update and upgrade systems:
“YaST Online Update”: <https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.onlineupdate.you.html>;
“Upgrading the System and System Changes”: <https://doc.opensuse.org/documentation/leap/startup/html/book.opensuse.startup/cha.update.osuse.html>.

There’s also a couple of Support Database (SDB) articles:
SDB: System upgrade: <https://en.opensuse.org/SDB:System_upgrade>;
SDB: Offline upgrade: <https://en.opensuse.org/SDB:Offline_upgrade> [Please ignore the emoticon in the URL – there’s a Forums issue … ].

A not so often documented issue is:

System updates and system upgrades are only successful on systems which have a package database which has been verified to be error-free.For example “zypper verify” and “rpm --rebuilddb”.

Which leaves the question, given all the openSUSE documentation related to system update and system upgrade, what caused your system to misbehave during or after an update (or upgrade)?