Boot partition runs out of space within months #1714
Comments
|
At least on EFI installations, the The ESP should be 512M by default, and it should only contain two sets of vmlinuz/initrd files, current and old. The files in this directory aren't named with version numbers, the old ones just have If you believe this is an issue with Pop!_OS rather than your configuration, please provide the output of the following commands (in a text file): The System76 customers can reach out to support for technical assistance. For non-System76 hardware, you can seek community support on Reddit or Mattermost. |
|
@jacobgkau Thanks for the feedback. Definitely my install is as routine as it gets. One partitiion, totally reformatted during the install process. No weird extra harddrives. And I'm not using any apps that should have anything to do with /boot whatsoever. So it's quite a mystery, especially since you mention "-previous", which is not present in any filename. Just ".old" on some of the links. There is no /boot/efi. Does that mean that I'm somehow not using EFI? I'm not really comfortable dumping fingerprinting info on Github, but I'm also not completely averse to sharing some info. |
Probably. You can confirm with
My question now would be how your boot partition could be filling up if you don't have a boot partition. You should not be receiving notifications for a "folder" filling up. Can you please provide a screenshot of the warning you're referring to?
I will explain why I need each output that I asked for:
Depending on the output of the final command, I would recommend trying a |
|
@jacobgkau Thanks for the thorough notes. It turns out that this is my particular firmware problem. At least, that's why it's not booting in EFI (and no, it's not System76). Therefore I'm probably in a small minority of users, so I'll just deal with it manually instead of asking the team to fix it. As to the error message about low space, it occurs in the PopShop, but it went away when I deleted the stale kernel images from /boot a while back. The autoremove tip sounds like a good idea, but I did it once in another OS context and bricked the machine. |
The
Please take a screenshot next time you see this error message/notification so we can see which one you're talking about. |
|
@jacobgkau "Please take a screenshot next time you see this error message/notification so we can see which one you're talking about." OK it's a deal. Presumably within the next few months. Thanks for the detailed comments. |
|
@jacobgkau It happened again in Pop!_Shop! (It actually happened at least twice but I forgot to copy down the message last time.) This interface won't allow me to attach a screenshot, but you can search the source code for the following error message (note the improper capitalization, which might help in searching, but ignore "boot" which is of course variable): Low Disk Space on "boot" |
|
As before, I fixed the problem by going into /boot and doing "sudo rm" with a set of 3 outdated system binaries that were no longer the targets of any simlinks. |
|
That is not a screenshot. Did you see the error message within the Pop!_Shop window, or was it at the top of the screen as a notification? Did you try running an autoremove like I previously recommended this time, before manually deleting those files? That would tell us whether the package manager is capable of handling the problem. |
See above: "This interface won't allow me to attach a screenshot". It's also gone now, but surely the error message can be found by searching the sourcecode for pieces of it. And yes, it was at the top of the screen as a notification. My bad that I forgot to run autoremove. I'll hopefully remember if this occurs again. |
The GitHub interface does allow attaching screenshots, either by dragging and dropping into your message or by clicking
Please let us know what you find. |
|
@jacobgkau LOL I never looked down at the bottom of the response dialog because in literally every other forum tool I've ever used, there's an attachment button in the same toolbar as the one containing text style and linking icons. And that "Attach files..." thing looks like a grayed-out tooltip, not a button. But you're obviously correct in your assertion, so I'll use it next time this happens. Statistically speaking, I'll return with a screenshot in a few months. Sorry about that. |
|
@jacobgkau I have an update on this. I tried autoremove and it DELETED my entire /boot folder, leaving all else intact. It then failed with an error, having successfully rendered my machine unusable and effectively unrecoverable. Fortunately I happen to have realtime backup so my data survived the disaster. Anyways, with respect to the error message that came up when I ran out of space in the boot folder, see attached. |
Can you please provide the complete terminal output of this transaction, including the error you're referring to? |
Your |
|
@jacobgkau Sorry for the delay. You're lucky that I thought to capture the autoremove output just before I shut down, only to find /boot deleted when I powered back up. And of course you're correct: the data was intact (independent of my backup). But thanks for the boot repair link, which I didn't know about. I'll use that if this happens again. ...oops, it's happening again right now! Which is why I remembered that I needed to get back to you. I'll just fix it by deleting unused files in /boot. (I'll rename them first, then reboot and make sure everything is OK, before actually deleting them.) Anyways, here's your "complete terminal output of this transaction". Note where it starts going wonky because it has issues with cryptswap. (OMG! It's an encrypted drive! What do we do now?!) Thanks as always. I hope this will give you some insights. Sorry for the horrible formatting. I don't know how to fix it and "code" tags make things even worse. Github is picking up random text as formatting operations. |
@jacobgkau FYI I was facing this issue and running |
|
@KitFristo Thanks for looking into this. sys/firmware/efi is populated. Therefore I'm booting in EFI mode. Nothing has changed which would lead me to believe that I haven't been doing so all along. (I just didn't know about this particular evidence.) "how your boot partition could be filling up if you don't have a boot partition" Apparently /boot/efi is in its own partition, while /boot isn't. But if that's the reason, then it's really weird that the problem goes away if I delete stale kernels from /boot. (Or at least, it did so the last time I had this problem, which was months ago. Perhaps it wouldn't do so any longer.) Based on your df command, /boot/efi is roughly half full. It currently contains just a single kernel's worth of images. I don't customize my partition configuration at all, leaving just whatever the installer default is. The screenshot you're seeking has already been posted upthread. Sorry I can't be more specific but I will continue to try to provide you with helpful information if you have questions which can be answered approximately. |
1 similar comment
|
@KitFristo Thanks for looking into this. sys/firmware/efi is populated. Therefore I'm booting in EFI mode. Nothing has changed which would lead me to believe that I haven't been doing so all along. (I just didn't know about this particular evidence.) "how your boot partition could be filling up if you don't have a boot partition" Apparently /boot/efi is in its own partition, while /boot isn't. But if that's the reason, then it's really weird that the problem goes away if I delete stale kernels from /boot. (Or at least, it did so the last time I had this problem, which was months ago. Perhaps it wouldn't do so any longer.) Based on your df command, /boot/efi is roughly half full. It currently contains just a single kernel's worth of images. I don't customize my partition configuration at all, leaving just whatever the installer default is. The screenshot you're seeking has already been posted upthread. Sorry I can't be more specific but I will continue to try to provide you with helpful information if you have questions which can be answered approximately. |
|
I have also problem with it. I found also a thread on reddit about it https://www.reddit.com/r/pop_os/comments/l39uu6/low_disk_space_on_efi/ |
|
|
For now as a temp fix removing the oldest directory (in my case |
|
@pktiuk If you look in /boot, you'll also see a bunch of System.map, config, initrd.img, and vmlinuz files. You only need the most recent 2 versions, but the system update process seems to keep older ones as well, taking up space and ultimately resulting in a "partition full" condition. A quicker easier fix would just be to change the installer in order to expand the partition size. Even 10X wouldn't make it very big by modern standards. |
|
@KloudKoder |
|
They usually are. Also, we just made the default ESP version larger, so this should no longer be a problem once we release our latest ISO. |
|
Hi Guys, I also have this problem, the second time now... Two days ago I kind of solved it with but today I'm getting errors and the same solution doesn't work...
Also when I tried to provide the input mentioned above I got error on installing the I am beginner in the Linux world thru PopOs so please keep that in mind if you decide to help me with some info...thanks in advance :) |
|
I also tried |
|
Me again :) |
|
Having this issue myself, but I don't see any older kernels. I only have the two latest ones. |
|
also having this issue |
|
This fix worked for me. I contacted HP Dev One support.
|
|
I don't have an HP dev one, thanks though |
|
Hello, I have the same problem. Do you have any idea what I could delete to free up space ?
|
|
It helps to change the initramfs compression method from Then regenerate initramfs with this command: |
|
Hello @leviport , Thank you for your help. 🙏 |
|
I have the same error without doing anything out of the ordinary so I suggest that this is a definite problem ... The solution appears to be to use xz compression or to increase the size of /boot/efi. Changing to xz compression recovered 100Mb in my case.. |
|
Same problem. Very sad to see this has been an issue for such a long time. |
No, it is not dangerous. It runs when many packages, especially the kernel, are updated with apt or Pop Shop. @cryptoarashi did you try the xz compression workaround I mentioned? |
Yes, thank you, it should alleviate the problem for quite a while, hopefully until the issue is resolved :) |
|
If autoremove is somehow causing problems, then a better way than directly deleting files under /boot is to remove the package responsible for the old files: Frustrating this happens on a barely used 1TB. I have made /boot/ 1GB for a decade or so. Even bigger to store bootable.ISOs under /boot/ |
|
Having the same issue... |
|
I'm also having this issue. Using |
|
I have a 4tb hard drive on a brand new system76 lemur which has run out of space with almost nothing installed on it. Can anyone advise what I should do? Even LibreOffice can't make routine writes to disk so I can't use that. Output of df -h is |
|
I reformatted. That solved it. For now at least. 😵💫 |
|
@sheldonth Try switching to xz compression, like I explained above. To clarify, the /boot/efi partition is filling up, not the rest of your 4TB drive. If you need further assistance, please reach out to our support team here: https://support.system76.com/. Since you are an owner of System76 hardware, they will be happy to help you out. |
Distribution (run
cat /etc/os-release):20.10
Related Application and/or Package Version (run
apt policy $PACKAGE NAME):/boot
Issue/Bug Description:
After typically a few months of use, I get a warning saying that my /boot folder is running low on space. This is because too many old Linux images and associated files are being saved. At most, there only need to be 2 of them, namely, vmlinuz and vmlinuz.old (and associated files). Probably anything beyond that should be deleted as soon as the latest upgrade reboots successfully all the way to desktop.
Steps to reproduce (if you know):
Just keep getting updates until /boot fills up. Most users probably wouldn't know what to do about it, resulting in a costly reinstall.
Expected behavior:
Either delete tertiary OS images and associated files, or change the installer to reserve like 10X as much in /boot (which would still make it quite trivially sized).
Other Notes:
The text was updated successfully, but these errors were encountered: