Final leg of 14.04 upgrade failed, getting package processing errors

[Steve the Pocket]

I've been running on a pre-release version of 14.04 since the second beta, and the automatic update tool has been incredibly unreliable. Several times it's failed to download and install all of the package updates, has refused to elaborate on what went wrong (Attention software designers who apparently never used Windows prior to Vista: Having a GUI does not have to mean leaving your users completely in the dark regarding errors, especially ones that cause system instability!), and on one occasion completely removed KDE instead of updating it.

Well, during what I believe was meant to be the final leg of the transition from the prerelease to final (judging by when it happened), something failed again. Restarting left me with, if I recall correctly, a normal-looking login screen but no way to log in because my keyboard and mouse weren't working. I shut down and figured I'd get back to it when I wasn't so busy; it's not my primary system and at this rate it never will be. Today I finally got the time to look at it, and booted into the recovery menu without bothering to double-check what was going wrong, figuring I'd just run the same set of commands as last time and everything would be fine. I started with dpkg --configure -a, and right off the bat ran into problems I hadn't encountered before:

dpkg: error processing package linux-generic (--configure): dependency problems - leaving unconfigured

and a little further down:

gzip: stdout: No space left on device
E: mkinitramfs failure cpio 141 gzip 1
update-initramfs: failed for /boot/initrd.img-3.13.0-20-generic with 1.
dpkg: error processing package initramfs-tools (--configure): subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 linux-image-extra-3.13.0-20-generic
 linux-image-3.13.0-24-generic
 linux-image-extra-3.13.0.24-generic
 linux-image-generic
 linux-generic
 initramfs-tools

Now, I'm not versed in what packages do what, but it was pretty clear that these are pretty important low-end components. Rather than stop there, I decided to try running apt-get update and apt-get install -f to see if it would be able to recover the broken packages. In the fast scroll of messages I spotted many of the same errors. It sounds like it's saying "these packages are broken and can't be fixed because of reasons." What do I do now? When I ran restart to double-check what the effect of my issues was, it brought me to what appears to be a functional KDE desktop now, except the screen is shrunken down and bordered with black.

[oshunluvr]

gzip: stdout: No space left on device

Are you using a separate partition for /tmp or is your root partition full?

[Steve the Pocket]

I just checked and... ooh, it turns out somehow /boot/ ended up on its own partition and it's only 246 MB. That would probably do it. I'm going to double its size and see what happens.

EDIT: Well, shoot. The Partition Manager won't let me resize anything, despite having 500GB of unallocated space. Am I going to have to reformat the whole disk and start from scratch?

[oshunluvr]

You can't resize or move mounted partitions - you have to boot to a live usb or cd.

Rather than resize, you could just move the boot partition back into your root or remove your old kernels - all except the one you're currently booting to. That should give you enough space.

[Steve the Pocket]

You think maybe my 12.04 kernel is still sitting around wasting space? That might explain why my boot partition is so much smaller than it apparently needs to be. I don't know how to do either of the things you just mentioned.

[oshunluvr]

Open a terminal, type

uname -r

this will tell you what kernel you're using. Then type

ls /boot

and you'll see several files names starting with "initrd" among others. Note the version numbers of all the ones below your current kernel. In other words, versions of a lesser number than your version. Then for each of these, type

sudo apt-get remove linux-image-<VERSION NUMBERS HERE>

and apt should find a remove the image and associated files. I would guess you have 5 or 6 at least. Do the oldest ones first and do at least 3-4 of them. This should give you enough room to proceed with the upgrade.

[Steve the Pocket]

I started with 3.2, and it looked like the program tried automatically installing 3.13.0-24 in its place and spat out the same error messages as apt-get install -f did. It appears to have successfully removed the 3.2 kernel though. Should I keep going and disregard the errors in hopes that it will eventually free up enough space to successfully install 3.13.0-24?

[oshunluvr]

Well, check the free space and try the install again. If it fails, remove another...

[Steve the Pocket]

I ended up running apt-get -autoremove instead. Failing to do this before is probably a big part of how I got into this mess, which makes me wonder why Kubuntu's automatic update system doesn't do any autoremove process on its own, or even provide any obvious way to do it manually. If putting /boot in its own, dinky partition is a common recommendation — as it apparently was when I installed it — then anything designed to add more stuff to that folder should be expected to do proper cleanup.

Anyway, everything's straightened out now, from the looks of things.

[oshunluvr]

I think not everyone would want autoremove run without interaction. However, you could easily make it a cronjob or desktop-exit function for yourself.

As far as having a separate /boot being a recommendation: AFAIK, unless you use RAID or a file system unsupported by GRUB this has never been needed or recommended for at least the last 7-8 years. Additionally, having a separate /boot adds - as you have discovered - an added item of responsibility. You might consider moving away from this arrangement as soon as you have the time. The only way to do this I know of is to boot to a live environment, make a new folder in your root partition, move the files, edit fstab (removing the /boot partition line), then manually edit grub.cfg (changing the boot location UUID to the same one as the root location) or boot manually to the new kernel location. Once booted, run update-grub for fix grub for good. Or wait it out until the next version upgrade and do a new install without the separate boot folder. Other than the reasons above, I can't think of any advantage to having a separate /boot.

I think what would be very useful is some automatic warning system when any partitions approached being full. Especially one needed for the system to boot. I have seen a distro (can't remember which one) which would automatically remove kernels older than two previous versions from the one just installed. I thought it a keen idea. You never had less or more than three kernels installed - the previous one, your current one, and the one you just installed.

[oshunluvr]

I did a little research. It seems the main reason in the past was to have a separate /boot because large hard drives were introduced in the late 90's before the kernel/grub could address the potentially large partitions. Other reasons include using LVM or encryption of the root partition - which are still valid reasons I think. I use a multi-device btrfs file system that isn't (yet?) supported by grub (although a single drive btrfs system is fine) but I also use a dedicated grub install rather than booting directly to my main install (I have 4 installs at the moment) so the separate /boot isn't needed.

One could also have a separate /boot/grub partition rather than the whole of /boot. Thus placing grub's files in a reachable place without worrying about kernels filling up the partition.

Supposedly, the later versions of apt allow autoremove to to target kernel files older than two version ago.