4

My /boot is full. apt-get autoremove autoclean not working. I chose to delete old linux-image* manually. There are many files like: configVERSION, vmlinuzVERSION, initrd.img*VERSION...

can these be deleted manually too?

VERSION is old version (some of them are dated 2012!).

Kanak
  • 41
  • You can delete these files by hand, but many of them will be regenerated during system updates unless the packages that create the files are removed. Prior to removing these files, you should be sure that you know what version of Ubuntu you are running so that you do not accidentally remove the image of the running OS. uname -r will provide you with the currently executing version. – Charles Green May 06 '17 at 13:19

1 Answers1

11

It's possible to delete just about any file manually, including kernels and initial RAM disks (initrds); however, when the file was installed by a package (as these were), deleting them manually leaves the package system in an inconsistent state. Thus, deleting the files manually is not recommended. I have three suggestions for how to proceed.

Approach 1:

My first choice is this:

  1. Type uname -r to discover what kernel you're currently running. For instance, one of my systems returns 4.8.0-51-generic.
  2. Type ls /boot/vml* to see all your installed kernels.
  3. Select a kernel from those listed that is not the one you're currently using, and that's not the oldest one (which is probably the "base" of the kernel series). The kernel that comes just "before" the one you're running is a good candidate. That might be vmlinuz-4.8.0-46-generic, for example.
  4. Type dpkg -S /boot/vmlinuz-4.8.0-46-generic, changing the kernel version as necessary. (Note that's an uppercase -S in the command.) This should reveal the package name associated with that kernel. In this example, it's linux-image-4.8.0-46-generic. Note that you should not pass a kernel with a name that ends in .efi.signed to dpkg -S; these kernels are installed in a different way that won't work with this command.
  5. Type sudo dpkg -P linux-image-4.8.0-46-generic (changing the kernel version number, of course). This tells the system to delete the package. This may is likely to result in a complaint about broken dependencies. In this case, you should add the package(s) it claims as being dependent on the one you said to remove. In my case, I had to make the command sudo dpkg -P linux-image-4.8.0-46-generic linux-signed-image-4.8.0-46-generic linux-image-extra-4.8.0-46-generic (deleting three packages rather than one).
  6. With any luck, the preceding command will work and clear up enough space for sudo apt-get autoremove to work.

Approach 2:

If this doesn't work, then I recommend manually deleting the .efi.signed version of a kernel you're not using, if it's present. These files are not installed directly; they're created by merging the standard kernel image with a small signature file installed from another package. Thus, deleting them won't upset the package system in the same way that manually deleting a non-signed kernel file will. Note, however, that if Secure Boot is active on your computer, or even if it's not but GRUB is configured to boot through the .efi.signed version of the kernel, deleting this file will make it impossible to boot that kernel. Thus, it's important that you not delete the .efi.signed version of a kernel you're currently using.

Approach 3:

Another approach is to temporarily move your /boot directory off of its separate partition and onto the regular root (/) filesystem. Note that although I've done similar things for other reasons, I've not tried this exact procedure for your exact reason; but it should work. Note also that this is rather risky; a mistake at the wrong point could render your system unbootable! If you're willing to take the chance, the procedure is:

  1. Type sudo mkdir /boot2 to create the /boot2 directory that will temporarily house your kernels.
  2. Type sudo umount /boot/efi. This command will fail on BIOS-based computers, but is necessary if your computer boots via EFI.
  3. Type sudo cp -a /boot/* /boot2/ to copy everything from /boot to /boot2.
  4. Type sudo umount /boot to unmount the /boot directory.
  5. Type sudo rm -rf /boot. This deletes the old /boot mount point and any files that may have wound up accidentally placed "under" it.
  6. Type sudo mv /boot2 /boot. This renames your copy to the original location, as far as Linux is concerned.
  7. Proceed with your sudo apt-get autoremove operation. This should succeed.
  8. Type sudo mv /boot /boot2 to move the updated copy of your kernels out of the way.
  9. Type sudo mkdir /boot to create a fresh mount point for your /boot partition.
  10. Type sudo mount /boot to restore the original /boot partition. Note that it will still be too full.
  11. Type sudo rm -rf /boot/* to delete the contents of the original /boot partition.
  12. Type sudo cp -a /boot2/* /boot/ to copy your modified /boot directory to the /boot partition.
  13. Reboot to be sure everything works.
  14. Type sudo rm -rf /boot2 to delete the temporary files.

A mistake (either by me or by you) could create serious problems, including a complete inability to boot the system. Thus, this approach is something of a last-resort one.

Moving Forward

It's imperative that you do a periodic sudo apt-get autoremove to keep the /boot partition from overfilling. Personally, I do this almost every time I upgrade my packages, and especially if I notice a new kernel was installed. Note that there are a couple of official bugs related to this issue:

The first of those bugs can be fixed for existing systems, but for various reasons even the official released fix isn't 100% effective. The second bug is about a choice made at system installation time, so existing systems continue to suffer from a too-small /boot partition moving forward. The only way to fix that issue is to resize your partitions to increase the size of /boot. Personally, I consider 500 MiB a minimum reasonable size for /boot these days.

Rod Smith
  • 44,284
  • 7
  • 63
  • 105
  • Approach #3 looks scary. I'll have to read it 2 or 3 more times to see if I can follow the logic. But in step #3 and #12, shouldn't the cp be recursive? I may have other issues, but that's a start. – heynnema May 06 '17 at 15:27
  • A tweak on approach 2 would be to zero out (not remove) all the files in /boot associated with an old kernel. That keeps the package manager happy, and may give it enough room to work and actually purge/remove the unwanted files using approach 1. – ubfan1 May 06 '17 at 16:02
  • @heynnema, the -a option to cp causes a recursive copy, but unlike -r, preserves ownership and permissions. @ubfan1, that's an interesting idea, and it would probably work. – Rod Smith May 06 '17 at 22:23