v19.10 update to kernel version 5.3.0-26-generic fails

[George Ganoe]

When I ran the Software updater on Jan 8, 2020, a security update from kernel version 5.3.0-24-generic to 5.3.0-26-generic was installed. When I rebooted the system, I was dumped to the boot-loaders busy-box prompt. I tried also under the Advanced options for Linux where normal and recovery mode versions of both v5.3.0-26-generic and v5.3.0-24-generic were available. Both of the 5.3.0-26-generic options also sent me to the busy-box prompt. However, when I tried the 5.3.0-24-generic option I was able to get the system started, and it seems to work normally.

Some additional observations:

While watching the messages when trying to get the 5.3.0-26 version going I noticed that it was not able to find the file system for my Ubuntu-Mate installation.

I also noticed that the size of the initrd.img-5.3.0-26-generic is about 4 MBytes smaller than the initrd.img-5.3.0-24-generic.

Since the Ubuntu-Mate file system is in a LVM partition, I am wondering if the initrd.img-5.3.0-26-generic lacks the capability to see the LVM partition.

I have tried to figure out how to unpack the two initrd.img files to see what the differences are, but none of the information I have seen on the web about how to do this works on the Ubuntu versions of the file.

My computer is a Dell XPS-13-9370.

[George Ganoe (geoganoe)]

After continuing the search, I have found the unmkinitramfs command and unpacked the two initrd.img files mentioned above. I can verify that the initrd.img-5.3.0-24-generic does contain the lvm capability, and that the initrd.img-5.3.0-26-generic does not have it. If this is an intended change in the ubuntu-mate support, I will need to find a substitute OS to use as I find the lvm capability invaluable to my Linux experience.

I tried running the "update-initramfs -u" to generate an updated initrd.img file, but it still didn't enable access to the lvm capability even though the messages displayed indicated that lvm would be required:

root@george-xps:~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-5.3.0-26-generic
I: The initramfs will attempt to resume from /dev/dm-1
I: (/dev/mapper/vg0-swapspace)
I: Set the RESUME variable to override this.
root@george-xps:~#

and the initramfs /proc/cmdline is:

BOOT_IMAGE=/boot/vmlinuz-5.3.0-26-generic root=/dev/mapper/vg0-matesys ro recovery nomodeset

At the end of the boot attempt, the following line is printed before the shell prompt:

ALERT! /dev/mapper/vg0-matesys does not exist. Dropping to a shell!

That alert, even though when booting using the initrd.img-5.3.0-24-generic option, the /dev/mapper/vg0-matesys partition is found without problem and boots normally.

I can post a picture of the final screen of messages if it would help solve the problem.

[George Ganoe (geoganoe)]

Since no one has commented on this problem, I will update one more time and then let it go. When the initrd.img-5.3.0-29-generic became available, and my system was upgraded to it, it failed in exactly the same way that the initrd.img-5.3.0-26-generic did. For some reason neither of the initrd images after initrd.img-5.3.0-24-generic would support the LVM configuration on my computer system.

As a test, I set up a test partition in the LVM volume group and did a new install of Ubuntu-Mate version 19.10 into it. The Live boot USB stick installed initrd.img-5.3.0-18-generic, and it booted properly when I restarted the system. After running the Software Updater, which installed the update to initrd.img-5.3.0-29-generic, the system still operates properly. This indicates that something in my main system changed to prevent the initrd image from being generated properly.

Since I don't know enough about how the initrd generator works to be effective, rather than trying to figure out what happened, I decided make a list of all of the applications I installed, the customization I made to the system, and back up my user space, then regenerate the system starting with the version 19.10 USB stick. While that process was quite time consuming, it likely took less time than trying to figure out what went wrong with the system to begin with.

In any case, somewhere there was a bug that made my system unusable, but since I re-installed the system there is no way to find the problem now. So, this bug can be closed as far as I am concerned.

[George Ganoe (geoganoe)]

While the bug did affect me, it no longer does. See below.

[Ubuntu Kernel Bot (ubuntu-kernel-bot)]

This bug is missing log files that will aid in diagnosing the problem. While running an Ubuntu kernel (not a mainline or third-party kernel) please enter the following command in a terminal window:

apport-collect 1859097

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[George Ganoe (geoganoe)]

It would no longer make sense to attempt to provide log files since I re-installed Ubuntu-Mate after not getting any response to my bug report for more than five weeks. The current kernel version that is running on my system no longer exhibits the problem reported here.

As far as I am concerned, this bug can be closed.

[Launchpad Janitor (janitor)]

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]