Hacker News Reader

Comment by karlmdavis | Hacker News Reader

- FLAVOR: Ubuntu Desktop

- HEADLINE: Please, please, please fix space issues with /boot.

- DESCRIPTION:

I'm constantly running out of space in /boot, due to kernel updates. It drives me so incredibly batty. If I had to guess, this is due to poor defaults in the installer for folks that opt to encrypt their whole disk. Even still, this system was setup back on 14.04 (don't think it started on 12.04), and I have no intention of reinstalling from scratch just to fix it.

Publish something official on how to fix this problem! Make it easy and stress free! Yell at the people who didn't catch this bug before it went out! Sorry, but this is just a really bad problem: it leads to folks like me wasting time, and probably a whole bunch of other folks just not being able to install updates, and no idea why.

- ROLE/AFFILIATION: software developer in the federal government

View on HN

+1 -- This is the one and only problem I have to regularly help my non-technical Ubuntu friends (and their friends) with. Every few months they cannot install updates anymore because their /boot fills up and apt fails to install a new kernel package.

The simplest fix would probably be to make /boot large enough by default (in the order of 10GB or 20GB or so -- the current size is 512MB IIRC).

A better fix would be to purge old unused kernels automatically but as far as I understand there were some difficult edge cases around that.

This is the main problem that keeps me from wanting to set up less technical family members on Ubuntu. It's possible to get in a spot where even a simple command won't solve this.

> The simplest fix would probably be to make /boot large enough by default (in the order of 10GB or 20GB or so -- the current size is 512MB IIRC).

Sure, I'll just use 1/6th of SSD to store 60 megabytes.

  $ du -hs /boot/
  56M	/boot/

If 512M is not enough space for /boot you're doing something wrong.

If you're running updates weekly it will fill up on Ubuntu. This is a recent problem, and I've only experienced it on my laptop with full-disk encryption.

The update process generates on the order of 100mb/month.

It's not new. It's been happening to me since I started using Ubuntu in the 8.x range.

>If 512M is not enough space for /boot you're doing something wrong.

I don't know what planet you're living on but it's certainly not this one. Between a Ubuntu desktop, a laptop and personal server with multiple Ubuntu VM's on it, all of which are kept up rigorously to date, I fix this problem at least three times a year, every year.

The command line process to fix it[1] is a multi-stage mess of dense bash-foo that comes with a 140 word, two paragraph explanation so that /ubuntu veterans/ can figure out what is going on without resorting to scouring the man page for flags. The friendly GUI process to fix it relies on a third party tool that is no longer maintained[2].

It is not possible to explain to non-technical users what is happening here, which means the only thing they can do when they see this is call their technical friend and cry for help. This is exactly the kind of user experience that makes people think Linux is not ready for widespread desktop use.

This is definitely something the OS should take care of itself. I'm ignorant of the challenges that caused it to be this way in the first place, but in my ignorance I would advocate that:

a) the partition be made larger by default b) the OS auto-purge any kernel package more than three revisions old

[1] https://askubuntu.com/questions/89710/how-do-i-free-up-more-... [2] https://launchpad.net/ubuntu-tweak/

Um, isn't the fix `sudo apt auto-remove --purge`, which autodetects unused kernels? What am I missing?

https://news.ycombinator.com/item?id=14005528

Following the chain of links and answers and explanations, we come to the conf file that says in the comments that it commonly results in two (2) kernels being saved, but can sometimes results in three (3) being saved.

IOW, it does automatically remove old kernels, it just keeps the last 2-3.

So, yes, run "apt-get autoremove", that's it.

If you do not run that command before /boot fills up, and you have a full /boot with a partially installed kernel, then that command fails. So this works fine if you remember to call it regularly, but it does not solve the problem once it occurs.

Interesting. I haven't encountered that edge case. I've many times filled /boot and resolved by doing an auto remove.

It seems silly to me that I need to manage this myself. Why do I need to be worrying about different kernel versions? I just want to make websites.

I think it has solved the problem for me, but still is not a good solution for anyone who would answer "What's a terminal?"

I love having a terminal with bash and use it constantly, but I don't think it should be needed for the system to just go on working.

Here is my old-timey one-liner personal solution[0] for it that has worked flawlessly so far, obscure theoretical edge-cases be damned, because the non-edge case situation is just awfully worse and practically impactful.

(warning, rant inside)

[0] https://gist.github.com/lloeki/520acee8ba3b44c532c7

I've been using Ubuntu either part or full time since 2007. I've literally never encountered this.

Which is not to say you're lying, I'm just sort of flabbergasted that this is an issue for so many people. Do you run autoremove much? Maybe that would solve it for you?

I run ubuntu 16.04 on a laptop, desktop and a TV streamer and I get this all the time. My boot partition on the desktop is 15gig and it gets plugged every now and then.

I've hit this before, but honestly do not think it's a big deal. Sure the installer could default to a larger boot, but it's manually configurable during install. And cleaning it up once in a while is just good sys admin practice.

sudo bash -c "apt auto-remove --purge; apt update; apt upgrade" is what I usually run.

Prefer they focus engineering cycles on actual engineering problems.

Yup! That "something wrong" is installing every single kernel update for two, three, four years and not deleting any of the old kernels.

Super common in enterprise deployments. I ran into this a bunch on my $EMPLOYER-issued workstation.

The installer should handle this. When you apt-get upgrade anything besides the kernel, does it leave the old version lying around?

I understand that it may be wise to keep the old kernel around so the system can be booted in case there is a hardware incompatibility or breakage in the new release, but that justifies only one additional kernel. Ubuntu keeps those kernels sitting there until you `apt-get autoremove`, and that means that unless you're running that command routinely, the boot partition is going to fill up at some point, no matter how big you make it.

This is especially a problem for people who use the unattended-upgrades package. I've autoremoved and had it clean up almost a gig of old kernel images before.

Sorry, but Ubuntu is doing something wrong here, not me. This should be handled automatically. Ubuntu wants to be the system for everybody, but you can't expect people to open the terminal and fix this manually. Making boot 20GB is ridiculous, but 1GB should be no problem, and for me 2GB would be OK if that means that this problem will disappear forever.

And I believe my boot partition is only 256MB, and I didn't set it to that. That was a system default.

Ubuntu is absolutely doing something wrong here and we'll get that fixed. Thanks!

For Ubuntu Desktop, it may make sense for the package manager to keep only the latest 2 or 3 kernels, and automatically purge the rest.

I had the /boot filling up problem but had thought it was fixed, I'm on 16.04+. I'm pretty sure the last two kernel updates I did removed older kernels leaving me with the current one and previous one ... ?

Nope, still doesn't do it without manually invoking autoremove.

You can configure apt unattended upgrades to autoremove by default, perhaps you did that?

Solus uses https://github.com/ikeydoherty/clr-boot-manager now, which purges old kernels and modules, but keeps the modules for the currently running system so HW still works

Doesn't `apt-get autoremove` remove those old kernels? Not that it's a solution; it should of course be done automatically! Here's what I get when using it:

    > apt-get autoremove
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    The following packages will be REMOVED:
      linux-headers-3.19.0-79 linux-headers-3.19.0-79-generic
      linux-image-3.19.0-78-generic linux-image-3.19.0-79-generic
      linux-image-extra-3.19.0-78-generic linux-image-extra-3.19.0-79-generic
    0 upgraded, 0 newly installed, 24 to remove and 39 not upgraded.
    After this operation, 1,732 MB disk space will be freed.
    Do you want to continue? [Y/n]

Whenever a kernel is updated autoremove should be called immediately afterwards. It should be called before the restart now / restart later dialog box of update-notifier appears.

Currently, Ubuntu installs a new kernel and update-notifier tells the user a reboot is needed. The autoremove notification only appears when using the terminal which explains why users are running into this issue. Also, update-notifier informs the user another reboot is needed after autoremove is run.

To avoid this mess I’ve commented out the lines of /etc/apt/apt.conf.d/99update-notifier and wrote my own updater using bash and zenity and incorporated needsrestart. It’s not pretty but it works.

Care to share it? Maybe it could help others...

I thought about sharing it but like I said it’s not pretty. It involves editing sudoers and holding back config updates for sudoers and update-notifier-common which might cause problems in the future if you’re not aware. I’d much rather see Canonical address it properly.

absolutely not, automatically running auto remove may lead to bad things; on occasion autoremove flags other more useful packages for removal.

For example I'm using LVM with my installation on my Ubuntu laptop and after updating the kernel and running "apt autoremove" it removed the LVM package leaving me scratching my head shortly on reboot as to why it wouldn't find my root filesystem (frankly i have no idea how it became "unneeded").

A more sensible approach is how Red Hat do it with YUM/DNF, that is, to allow a certain number of the same packages to be installed, "installonly_limit" in yum.conf. Doing this means that when a new kernel gets installed the oldest is removed to keep the the system at the limit specified.

On my RHEL/CentOS machines I tend to narrowly provision /boot to around 250-500MB. set "installonly_limit" to 2 and the system will keep the most recent kernel and one back. it works for me.

I see you’re point, though I too use LVM and haven’t seen that happen... weird. I could have been more exact with my response as autoremove does more than just remove old kernels. Anyway, it would be nice to see Canonical resolve this.

Except, it would be nice to keep a few of the (recent) older kernels, in case things go awry with the new update.

I agree.

I'm running Ubuntu 16.10 currently. A kernel upgrade hosed my setup yesterday, and having an older kernel available saved my butt. I was able to do another `apt-get update` and things eventually worked with the latest kernel.

This already happens: apt autoremove won't remove the package for the running kernel. It'll clean up "old" (N-1 and lower) kernels, but installing kernel N+1 won't allow kernel N to be deleted as long as kernel N is still executing.

Once you reboot/kexec into the N+1 kernel, it'll let you remove the N (now N-1) kernel, bringing you down to one. But at that point you've proven the new kernel works—at least well enough to get to a shell you can run apt autoremove from.

This is why autoremove isn't so auto: if it happened automatically after reboot, it might be running on a now-wedged system (e.g. one that can't bring up the display manager), removing the last-known-good kernel and leaving you with only the broken one.

I think the right middle-ground solution would just be for installing kernel updates to touch a file, and for Desktop Environments to notice that file and trigger a dialog prompt of "you've just rebooted into a new kernel. Everything good?"—where answering "yes" runs apt autoremove. On a wedged system, you can't answer the prompt, so the system won't drop the old kernel. (In other words, just copy the "your display settings were changed. Can you read this?" prompt. It's a great design!)

Wouldn't a good solution then be to run autoremove before installing a new kernel?

That way, you have kernel N running, first autoremove wipes kernels N-1 and older, then it installs kernel N+1, so that when you reboot into N+1, you'll always have known-good kernel N if it doesn't work.

It's a very similar solution to how a good programmer solves an off-by-one error, doing a shift/rotate shuffle on a for/while loop.

What happens when you have a high-uptime system where you repeatedly "apt dist-upgrade" and end up installing packages for kernels N+1, N+2, N+3, etc., all without rebooting into any of them?

I agree that if the user manually runs an apt [dist-]upgrade—or really any manual apt command—that that's a good time to do apt maintenance work. (Homebrew does maintenance work whenever you invoke it and there haven't been any complaints so far.) But kernels usually get installed automatically, so it can't just run then.

Now, if there was a specific concept of a "last-known good kernel" (imagine, say, the grub package generating+installing a virtual package when you run grub-install, that depends on whatever kernel you specified as your recovery kernel, ensuring it remains around), then your approach could work—you'd always have two kernels, the LKG for a recovery boot, and the newest for a regular boot.

Exactly what happens on Fedora.

Fedora/RHEL yum has a much better solution: installonly_limit, defaulting to 3. Kernels which have been updated will only be kept up to this depth. The excess are automatically trimmed during update.

>Doesn't `apt-get autoremove` remove those old kernels?

Of course it doesn't! Why would you assume such a silly thing? /s https://askubuntu.com/questions/563483/why-doesnt-apt-get-au...

> It's better to err on the side of saving too many kernels than saving too few

But Muh Freedoms! I hate to be subject to one man's opinion of things /s

It's also kind of a garbage argument.

People who know they have broken kernels don't keep upgrading them, they stop and fix them.

People who don't know they have broken kernels also don't know they can boot with an older kernel, so they get nothing from the "backup".

We want to leave some time for people to realize their kernel is broken, so keeping three is probably just fine. Honestly, it would probably be adequate to just bump the oldest one off the queue whenever a newer one is requested. If you've got a tiny boot partition, maybe that means only two revisions. If you've got a huge boot partition it could be 20.

But just keeping them all and making people manually uninstall them gains you nothing, it's user-hostile for no reason.

Yes, it does remove old kernels. Read the very link you posted.

I confirm that it doesn't autoremove. I had to empty /boot on some servers lately.

Anyway sometimes one wants to keep old kernels. I have an old laptop that runs OK with a 3.something kernel and has wierd video sync problems with any newer ones. Ubuntu 16.04 keeps running with that old kernel so I keep booting from that, maybe once or twice per year.

However the proper solution would be pinning a package and autoremoving the others.

> The simplest fix would probably be to make /boot large enough by default (in the order of 10GB or 20GB or so -- the current size is 512MB IIRC).

What? This is ridiculous and unacceptable. I don't use Ubuntu anymore, can someone tell me what is filling up the boot partition?

I'm currently on ArchLinux and mine is 200MB and it's 14% full! I can't fathom what could occupy so much space.

It's the way kernel update come in apt. The kernel update is a new package, not an upgrade of a previous kernel package. Thus the old kernels are left in place and the new ones installed alongside. After about 3 kernels have been made available in /boot the previously recommended size for /boot is full and attempted update to a new kernel fails.

It can be manually fixed by removing older kernels ("sudo apt purge ...").

Perhaps I'm mistaken but i thought a fix was in place for this, maybe it was something third-party but apt definitely offered to remove unused kernel package for me recently.

In other words: integrate purge-old-kernels

http://manpages.ubuntu.com/manpages/xenial/man1/purge-old-ke...

Maybe add some stats to know which kernels have booted successfully, so one knows which old ones can be safely deleted, and keep the last 1 or 2 good ones (not always the latest!).

$ apt-get install purge-old-kernels

    The program 'purge-old-kernels' is currently not installed.
    You can install it by typing: apt install byobu

"byobu"? packages.debian.org to the rescue...

https://packages.debian.org/jessie/byobu "Using Byobu, you can quickly create and move between different windows over a single SSH connection or TTY terminal, split each of those windows into multiple panes, monitor dozens of important statistics about your system, detach and reattach to sessions later while your programs continue to run in the background."

Uhm... what?

> "byobu"? packages.debian.org to the rescue...

You don't ned to use packages.debian.org to look up what packages do.

> apt show byobu .. Description: text window manager, shell multiplexer, integrated DevOps environment Byobu is Ubuntu's powerful text-based window manager, shell multiplexer, and integrated DevOps environment.

Quite right. One uses packages.ubuntu.com:

* http://packages.ubuntu.com/yakkety/all/byobu/filelist

(-:

byobu is basically an abstraction over screen and tmux, letting you use either with some common keybindings for spawning new windows and a common toolbar at the bottom telling you disk usage and load average and the like. I am not sure why purge-old-kernels is in the byobu package, that seems like a really poor placement for it.

It is a bad place for it. But it's there because I wrote both of them, and Byobu is always everywhere I want it to be, and I generally always want purge-old-kernels there too.

But yes, you're very right. It needs to be moved out.

Forgive the intrusion, just want to say thanks for Byobu. I use it regularly, and it's much nicer than bare tmux or screen.

:-) Thanks!

Are you sure you typed exactly that?

For `apt-get install purge-old-kernels` I get

    E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
    E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?

And for `sudo apt-get install purge-old-kernels`, I get

    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    E: Unable to locate package purge-old-kernels

But I can reproduce your error by `purge-old-kernels` alone. That is indeed strange.

EDIT: I straced bash by `strace -o bashlog -f -s 10000 bash` and found the culprit to be /usr/lib/command-not-found. Indeed, if you run `/usr/lib/command-not-found -- purge-old-kernels` directly, you get that same message about byobu.

EDIT2: I assumed this was some kind of bug with the database, but now I actually tried installing byobu and it does make purge-old-kernels available.

The first of the two errors has nothing to do with the package itself - packages need root permisions to be managed, which is what exactly the error is telling you:

    E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
                                                                     ^^^^^^^^^^^^^

In your case, you didn't prepend `sudo`.

Regarding the second, which is instead the core of the problem, see the man page (http://manpages.ubuntu.com/manpages/xenial/man1/purge-old-ke...):

    Provided by: byobu_5.106-0ubuntu1_all bug

Therefore the correct (and full) command is:

    sudo apt-get install byobu

As pointed out in another comment, such package is arguably a poor placement for this type of utility.

I'm aware that the first errors don't have anything to do with the package itself, but this was the command line given. I was wondering what kind of setup might lead to an apt-get command (without sudo even) to display that error message.

One case (which may be irrelevant in this context, but still a valid scenario) is auto-updates being executed in the background.

So I'm the author of both Byobu and purge-old-kernels. It's in Debian, because I help push it there after I push it to Ubuntu.

It's completely wrong that purge-old-kernels is in Byobu, rather than in the kernel or directly handled by dpkg/apt. Thanks for all the feedback here -- we'll get that cleaned up in 17.10!

It shouldn't be needed. AFAIK part of the post-installation script of a new kernel already marks the oldest kernels for removal with `apt-get autoremove`. They just need to run it automatically after an upgrade.

Unfortunately, that's not enough. There are many corner cases where kernel packages hang around much longer than they should, for odd reasons.

Another related issue: I have helped get a few co-workers set up with Ubuntu on their laptops. Inevitably, once every few months, one comes to me and says "I just ran an update and the 'Restart' popup came up, so I restarted, now my laptop says 'No bootable devices found.'" This happens when Ubuntu is installed in UEFI mode. A kernel update sometimes wipes out the boot image. To fix it, I to get into the BIOS and reselect a bootable UEFI image. This should never, ever happen.

I have similar experience, but with Virtualbox in UEFI mode. After any restart, UEFI will complain that it cannot find anything bootable, I will run the bootloader from UEFI shell (Virtualbox does not have BIOS menus), in booted system run the efibootmgr to register it, just to have it lost at next reboot and doing the dance again.

Only Ubuntu does that, other linux distributions don't have this problem.

+1 - I didn't even know this was an issue. Usually i just use apt to update and run autoremove after I get a new kernel and verify it is working.

I recently installed Ubuntu on some old computers for my relatives and they really like it. If they keep updating and after a couple of months their system fails to work that will be a disaster for any good will they will have developed for Ubuntu.

This needs to be fixed NOW! How can Ubuntu even pretend to be a viable desktop operating systems if normal updating renders the system unusable?!

+1 then I can kill my custom "remove oldest kernels, except the running one, and leave at least two other kernels" script.

Yes, I had this same problem when I was on Xubuntu. Fedora and CentOS(and I'm assuming many other distros) seem to handle kernel updates just fine without forcing me to manually clean out old images from /boot periodically (was always too lazy to write a script).

What Fedora and CentOS do is a generic yum/dnf option: installonly_limit. It allows you to keep limit on the amount of packages with the same name and different versions, kernel included.

would you mind sharing this in the meantime?

I've been using this for years. I believe it only keeps one old kernel version though, not two like you requested. Tested and working for weekly use since 12.04 though 16.04:

echo $(dpkg --list | grep linux-image | awk '{ print $2 }' | sort | sed -n '/'`uname -r`'/q;p') $(dpkg --list | grep linux-headers | awk '{ print $2 }' | sort -n | sed -n '/'"$(uname -r | sed "s/$[0-9.-]*$-$[^0-9]\+$/\1/")"'/q;p') | xargs sudo apt-get -y purge

I guarantee there's a way to get that pipe to purge all packages in your system.

This is the new way to do it:

    sudo purge-old-kernels --keep 3 -qy

TIL

I agree, I've had to deal with this issue many times. I think it has happened at least 4 times in the last year. A few times I had to manually go in and start deleting old kernels because it had completely run out of space, so apt couldn't do anything without crashing.

I eventually set up a cron script to regularly delete everything except the last 3 kernels. I think this should really be the default behavior. "Save all the old kernels until you run out of space and everything crashes" doesn't sound like a very sane default.

+1 as well. This made me brick my entire installation (entirely my own fault: trying to fix it with insufficient knowledge). It made me switch to another distribution.

Despite having cleaned out old kernels before, I spaced one day and accidentally removed the kernel I was running. This is fixable if you boot a live distro you can mount the relevant volumes (like your root disk to /mnt/foo, and your boot partition to /mnt/boot), then, after a chroot to /mnt/foo you can re-install the kernel. Here is an article describing it (but it misses mounting the boot partition) http://askubuntu.com/questions/28099/how-to-restore-a-system...

+1. This is one of my major annoyances w/ Ubuntu. Been using it 3 years now and this seems like a fundamental issue that should be fixed.

It's user error on your part. The proper way to upgrade a Debian/Ubuntu system is:

  $ apt-get dist-upgrade
  $ apt-get autoremove

dist-upgrade installs new kernels, and autoremove will automatically remove old kernels (and keep the last 2 most recent ones.)

autoremove followed by dist-upgrade to 16.04 for me somehow decided to build multiple kernel versions and ran out of space on /boot mid build. That was really annoying to fix.

Run autoremove after dist-upgrade.

dist-upgrade shouldn't try and move you to another release version, do-release-upgrade alone does that, as far as I know. Things get a little more confusing using apt update/upgrade vs. apt-get update/dist-upgrade, they don't seem to be quite the same in all cases for me. But I agree with the general frustration that it shouldn't be necessary to run apt(-get) autoremove frequently to keep /boot from filling up with old kernels.

There is a lot of confusion in this thread.

dist-upgrade is NOT (in most cases) meant to upgrade to a newer distribution (eg. Ubuntu 14.04 to 16.04). dist-upgrade is just like upgrade except it also installs additional packages if necessary (eg. linux-kernel-4.1 AND linux-kernel-4.2).

Most people should always run "apt-get dist-upgrade" and never "apt-get upgrade" in order to simply keep their packages up-to-date.

An actual distribution upgrade is triggered by a different command. On Ubuntu: do-release-upgrade

I like to use apt-get dist-upgrade --auto-remove, all in one step. Though for kernels they will be removed on the next invocation after reboot as the default logic keeps the last installed kernel version as well as the current one.

As for the original issue of not cleaning up the kernels, this is fixed in xenial/16.04 but not in trusty/14.04, see bug report here: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bu...

Xenial/16.04 has other issues regarding kernel cleanup involving DKMS leaving files behind:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717584

https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1515513

I quit using Ubuntu as a Desktop OS because this was so obnoxious. I would gladly return if they fix this.

This will get fixed. Mark my words ;-)

Awesome! thanks, looking forward to it!

This is a feature (kernel update) that is used by everyone, including newbs. They don't have to understand anything to enjoy the update, and they shouldn't have to understand anything to avoid the space filling issue.

Lots of ways to fix it, I don't claim to know which is best:

* Always leave N% /boot available, and delete or move old kernels to satisfy that.

* Move old kernels to /old_kernels, outside of /boot. Driven either by satisfying N% space, or no more than K number of kernels kept in /boot.

* Opt in, opt out, ask this on installation and for non-server installs, default to "never have to think about this again."

* Easily configurable in the "whatever that box was called when I last used Ubuntu years ago" box.

sounds like you're keeping too many old kernels, I've had this problem too in the past..try this nice little oneliner: dpkg --list | grep linux-image | awk '{ print $2 }' | sort -V | sed -n '/'`uname -r`'/q;p' | xargs sudo apt-get -y purge

really, this is what your package manager should do automatically before/after installing new kernels

for your reference: http://askubuntu.com/questions/2793/how-do-i-remove-old-kern...

That's not a good one liner, because it doesn't do anything about the linux-headers packages (which are hundreds of thousands of small files) or the linux-image-extra packages.

Just run "apt-get autoremove".

This would be fantastic. This problem has no official or easy solution for non-technical people and delays updates which could cause security issues. Please, please provide a fix for this!

-FLAVOR: and Ubuntu Server +1

Bit late to the party, but I believe this was fixed in xenial/16.04 but not trusty/14.04

The relevant bug report is here: https://bugs.launchpad.net/ubuntu/+source/update-manager/+bu...

Side note, give up on a separate /boot in future, not needed 99.9% of the time.

Indeed this is due to missing options in the installer: with some manual fiddling, it's long been possible to make grub boot from encrypted disk (thus removing the need for a separate /boot and its space issues): https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1062623

You could probably fix this on your system without installing from scratch, but it would take some careful planning (mostly wrt backups!). You'd need to boot from a recovery cd or such, copy /boot into /, edit /etc/fstab accordingly, and then follow the last few steps in the bug report above (from the chrooting onwards). I'd probably test this in a VM first.

This might be aggravated by this DKMS bug which was found in v2.2.0.3, which incidentally is used in Ubuntu 16.04 LTS, and maybe other versions. It doesn't remove old initrd files in /boot which lead to full /boot issues and subsequent update problems

I manually removed a bunch of old initrd images the other day.

http://askubuntu.com/questions/616512/purging-old-kernels-fa...

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=717584

They've got a bug reported upstream. We need this fixed in Ubuntu

Ubuntu Launchpad bug here regarding DKMS leaving old files to fill /boot:

https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1515513

You can add yourself to the list of people affected to increase the Bug Heat and get this issue fixed.

Why do you have a /boot partition?

  $ mountpoint /boot
  /boot is not a mountpoint

I don't know if this is the default, but my KUbuntu machines have been fine for many years without a separate /boot.

Ubuntu mounts my EFI partition as /boot.

I try to do the same, but sometimes there's no way around it. LUKS comes to mind: can't boot an encrypted kernel because EFI/BIOS has no decryption facilities. I'm sure there are other cases, but this is the only one that comes to mind.

If you want to install with full disk encryption, you normally want a /boot partition.

In theory, GRUB can load kernels off of a LUKS-encrypted partition, but in practice I've never managed to set that up without having two passphrase prompts, one from GRUB and one for mounting the root filesystem under Linux.

LUKS.

I don't use Ubuntu, but in Fedora it keeps only a handful of old kernels (i.e. one or two back) and deletes the rest. I guess Ubuntu just holds onto every kernel you've ever had since the beginning of time?

Why is boot still a separate partition. I most cases it doesn't need to be.

LUKS

omg, I am on 14.04 LTS and didn't believe until now it is not fixed in newer releases! :)

I've also encountered this issue, and I assumed it was a bug to do with the fact that I sometimes use apt-get and sometimes accept the Ubuntu GUI software update prompts.

If people are encountering it on this wide a scale, it must be a truly severe problem (that's also probably causing many people who haven't learned about apt-get to give up on software updates entirely!).

This is the primary reason I've recently replaced Ubuntu as the OS on my home server/NAS. I'd be happy to come back!

This is an annoying problem indeed but there is an easy workaround. Here is a script I use whenever I ran out of space on /boot partitition:

https://gist.github.com/vzaliva/bee68ed709ddd2724791a56714ec...

Ubuntu should just integrate Debian's /etc/kernel/postinst.d/apt-auto-removal script.

This more than anything. I believe it is this issue (at least for me): https://bugs.launchpad.net/ubuntu/+source/unattended-upgrade...

+1 I recently had this issue. I have Ubuntu on my machine (not dual boot) and I installed with all the default options. I hardly installed any heavy applications and it started saying it cannot install updates as /boot is full. Thanks for bringing this up.

The old kernels should be purged automatically on desktops. That really is an annoying issue.

I used to use Arch and seriously one of my favourite things to see was an update that used negative disk space. Apt has come a long way, but this DEFINITELY needs to be fixed.

I had this problem on a previous work laptop. Very annoying. I thought it was the local IT people who had installed it wrong.

apt autoremove will clean it up.

Only if you catch it in time, before you've completely run out space. `apt autoremove` will crash if there is not enough space on the disk.

Which would be another worthwhile fix: some way to run `apt remove` or `apt autoremove` in a zero free-space environment. It could detect it and pick pick data somewhere (like /usr/src) to persist to memory temporarily while it works, then replace.

I've never noticed autoremove removing old kernel images in /boot.

+1 ... plusa nice command to clean out unused kernels

Yes! Please!!

Reply on news.ycombinator.com