Don’t forget your linux-image-extras

It seems like the right time to rant about Ubuntu after a few wines stemming from a 3-year-old’s birthday barbecue.

It concerns Ubuntu’s seemingly won’t-be-resolved problem of kernel updates running out of space in /boot. There is so much emotion on the internet dedicated to this issue I couldn’t resist adding some more. And, I don’t see why I should have to configure automatic update installation to make this go away. I run an LVM/LUKS setup which requires a separate /boot, so it seems there is no escape.

What I usually encounter is half installed/configured kernels due to lack of disk space. Usually there’s enough space for 2.5 kernels, such that if I remove the oldest kernel I have lying around there’s enough space to complete the installation of the new kernel. However, this time it appears I got slack, and left my laptop’s kernel in the half-updated state for two Ubuntu kernel patch cycles, which lead Ubuntu to attempt installation of a fourth kernel after a failed attempt at the third. As it turned out it appears there was enough space to drop this second new kernel onto the system, but again not enough space to complete its installation.

To be clear, it’s usually the generation of the initramfs for the new kernel which fails. It’s triggered as a kernel post-install script and takes up the bulk of the space in /boot. This leaves the door open to my problem above where a second new kernel was installed in the space that would have otherwise been taken up by an initramfs for the first new kernel, if its generation succeeded.

The upshot of this was that removing older kernel caused the two newer kernels to attempt reconfiguration, with the operation again running out of disk space at the point of generating the initramfs for the newest kernel. Removing both new kernels got me to a point where I could retry the upgrade.

However, the obvious follow-up apt dist-upgrade didn’t attempt to install the latest kernel update, so I tried installing the latest kernel manually with sudo apt install linux-image-4.8.0-45-generic . This was successful. Great. So I reboot, and what I discover is that this leads to an unresponsive LVM LUKS password screen. The graphics and prompt are present, but the system is unresponsive to keyboard input.

Rebooting and manually selecting the kernel from GRUB leaves me at the ‘loading initrd` message, with no further action. To be honest, this isn’t the greatest failure mode.

Rebooting again, attempting (and failing) to enter my disk encryption password at the LUKS prompt screen and then switching VTs lead nowhere — no gettys were spawned, and switching back to VT7 didn’t bring back the LUKS password screen. Instead, it showed my disk encryption password in plaintext at the top of the terminal, presumably due to a mis-directed keyboard. Awesome.

Booting into safe mode for the -45 kernel got me to a text-mode LUKS password prompt, and after entering it root could be mounted. So this was a win, except running the dpkg command from the Ubuntu rescue mode ncurses menu didn’t find anything to fix. Further, attempting to start NetworkManager didn’t lead to a functional network, because at this point, why would it?

Well, as it turns out, it was because there was no driver bound to the WiFi adapter. And there’s no iwlwifi driver under /lib/modules/4.8.0-45-generic. Because installing the kernel as I had above doesn’t pull in linux-image-extras-4.8.0-45-generic. As it turns out, installing the extras package also resolves the LUKS password screen issue — I rebooted and everything worked as expected, which was great, but the experience leaves a bitter taste in my mouth each time I encounter it.

Given my experiences with Ubuntu and OSX, the moral of the story appears to be to run Windows.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.