Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
CwF wrote:Let's not get ahead of ourselves here, as p.H. pointed to, ONLY the result images for the system need to be there, NOT the whole downloaded deb file. Otherwise I to would be out of space, instead of 2/3 free with my buster kernel in 255MiB. It takes 54MB and is a 270MB DL, yet lives...the one I posted earlier is a 23MB image, tidier yet still from a much larger download..
Maybe the OP should post the contents of / and /boot so we can see the 2-3 other kernels still in there.
dbip wrote:With "315MiB for the entire root partition" you mean such small space?
Yes. One 4.9 kernel requires 140 MiB for itself and 20 to 60 MB for its initramfs.
A kernel update requires as much available free space. It means that you need at least 140*2+20 = 300 MiB for the kernel alone. This leaves only 15 MiB for the rest of / (including /etc and /lib). I'm afrait it won't work.
Head_on_a_Stick wrote:I suppose you could clear some space for a new partition and mount it under /lib
Don't do that. /lib is not supposed to be separated, it is supposed to be available before mounting any filesystem other than / and /usr.
However /lib* may be a symlink pointing into /usr which is mounted at early boot by the initramfs.
This is the size of the top directories in that partition:
dbip wrote:From what I understand lib can't be moved (only mapped)
What do you mean by "mapped" ?
Since Buster, /lib can be symlinked to /usr/lib as part of /usr merge. Merging /lib into /usr/lib may cause file conflicts in previous versions.
However I guess you could symlink /lib/modules to /usr/lib/modules as a temporary workaround.
I have no experienced advice for this. A simple answer is to expand / or relocate /lib. That path is not something I've ever needed to do. With my resources I'd image it and try some solutions virtually. I think I'd first try and steal some /usr space for root. I'd use another machine to manipulate the disk. Doing in within the OS, well I'd wait for some other answers. I stopped using partitions within a device space long ago, in the rare case a device/partition needs more space, I do what I said on a second machine, image it to a bigger disk and expand it to fill, done.
If your sda1 and sda5 are contiguous then that's the first try - reduce sda5 and give it to sda1. That would be straight forward for Gparted, maybe live but I would do it on another machine.
Ya know, it is remotely possible to remove the working kernel, upgrade/install a new one in a single session. I want to say I tried that many years back and can't really remember the outcome. But I do remember for sure that removing the working kernel will prompt a few times if you're sure and it will continue to run the current session. If anything at all happens before the new one is installed you're hosed...