10 ms·

+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 u

by stsp 10y ago

+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.

TheCowboy 10y ago
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.
justinsaccount 10y ago
> 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.
- deleted 10y ago
  [deleted]
- lukeschlather 10y ago
  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.
  - jayess 10y ago
    It's not new. It's been happening to me since I started using Ubuntu in the 8.x range.
- Sir_Substance 10y ago
  >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-space-in-boot/90219#90219 https://askubuntu.com/questions/89710/how-do-i-free-up-more-... [2] https://launchpad.net/ubuntu-tweak/ https://launchpad.net/ubuntu-tweak/
  - kobeya 10y ago
    Um, isn't the fix `sudo apt auto-remove --purge`, which autodetects unused kernels? What am I missing?
    - Sir_Substance 10y ago
      https://news.ycombinator.com/item?id=14005528 https://news.ycombinator.com/item?id=14005528
      - alphapapa 10y ago
        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.
- cbhl 10y ago
  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.
  - cookiecaper 10y ago
    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.
- hollander 10y ago
  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.
  - dustinkirkland 10y ago
    Ubuntu is absolutely doing something wrong here and we'll get that fixed. Thanks!
unethical_ban 10y ago
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.
- pbhjpbhj 10y ago
  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 ... ?
  - cookiecaper 10y ago
    Nope, still doesn't do it without manually invoking autoremove.
  - kobeya 10y ago
    You can configure apt unattended upgrades to autoremove by default, perhaps you did that?
benwaffle 10y ago
Solus uses https://github.com/ikeydoherty/clr-boot-manager 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
fredsted 10y ago
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]
- nominated1 10y ago
  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.
  - cr0sh 10y ago
    Care to share it? Maybe it could help others...
    - nominated1 10y ago
      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.
  - Tsiklon 10y ago
    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.
rocho 10y ago
> 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.
- pbhjpbhj 10y ago
  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.

by stsp 10y ago

TheCowboy 10y ago

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.

justinsaccount 10y ago

> 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.

deleted 10y ago
[deleted]
lukeschlather 10y ago
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.
- jayess 10y ago
  It's not new. It's been happening to me since I started using Ubuntu in the 8.x range.
Sir_Substance 10y ago
>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-space-in-boot/90219#90219 https://askubuntu.com/questions/89710/how-do-i-free-up-more-... [2] https://launchpad.net/ubuntu-tweak/ https://launchpad.net/ubuntu-tweak/
- kobeya 10y ago
  Um, isn't the fix `sudo apt auto-remove --purge`, which autodetects unused kernels? What am I missing?
  - Sir_Substance 10y ago
    https://news.ycombinator.com/item?id=14005528 https://news.ycombinator.com/item?id=14005528
    - alphapapa 10y ago
      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.
cbhl 10y ago
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.
- cookiecaper 10y ago
  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.
hollander 10y ago
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.
- dustinkirkland 10y ago
  Ubuntu is absolutely doing something wrong here and we'll get that fixed. Thanks!

unethical_ban 10y ago

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.

pbhjpbhj 10y ago
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 ... ?
- cookiecaper 10y ago
  Nope, still doesn't do it without manually invoking autoremove.
- kobeya 10y ago
  You can configure apt unattended upgrades to autoremove by default, perhaps you did that?

benwaffle 10y ago

Solus uses https://github.com/ikeydoherty/clr-boot-manager 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

fredsted 10y ago

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]

nominated1 10y ago
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.
- cr0sh 10y ago
  Care to share it? Maybe it could help others...
  - nominated1 10y ago
    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.
- Tsiklon 10y ago
  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.

rocho 10y ago

> 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.

pbhjpbhj 10y ago
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.