The Volume 'boot' has only 0 bytes disk space Debian 12 Cinnamon SOLVED

Alexzee

Well-Known Member
Joined
Jun 1, 2019
Messages
3,759
Reaction score
2,017
Credits
22,478
I checked on all of my Debian partitions and I can't tell if there are too many kernels or what.
When I did a fresh installation of Debian 12 I gave 300 MiB's for the boot partition. That's what was recommended in the Debian documentation.

Code:
debian-box:~$ dpkg -l | grep linux-image-
ii  linux-image-6.1.0-13-amd64               6.1.55-1                             amd64        Linux 6.1 for 64-bit PCs (signed)
ii  linux-image-6.1.0-15-amd64               6.1.66-1                             amd64        Linux 6.1 for 64-bit PCs (signed)
ii  linux-image-6.1.0-16-amd64               6.1.67-1                             amd64        Linux 6.1 for 64-bit PCs (signed)
ii  linux-image-amd64                        6.1.67-1                             amd64        Linux for 64-bit PCs (meta-package)
debian-box:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.8G     0  7.8G   0% /dev
tmpfs           1.6G  1.7M  1.6G   1% /run
/dev/sdb1        77G   14G   59G  20% /
tmpfs           7.8G     0  7.8G   0% /dev/shm
tmpfs           5.0M   12K  5.0M   1% /run/lock
/dev/sdb3       300M  300M     0 100% /boot
/dev/sdb2       480G   12G  444G   3% /home
tmpfs           1.6G  104K  1.6G   1% /run/user/1000

The current kernel installed is:
Code:
6.1.0-15-amd64

Would deleting old kernels be the best practice?
 


I'd use sudo apt autoremove --purge which should remove all but the two most recent kernels.
 
300meg should work, but it's cutting it a bit close.

264K config-6.6.3-200.fc39.x86_64
264K config-6.6.4-200.fc39.x86_64
264K config-6.6.6-200.fc39.x86_64
18M efi
2.4M grub2
111M initramfs-0-rescue-c9ac45c71f6947ba969445d5e82b0d8b.img
36M initramfs-6.6.3-200.fc39.x86_64.img
36M initramfs-6.6.4-200.fc39.x86_64.img
36M initramfs-6.6.6-200.fc39.x86_64.img
24K loader
16K lost+found
0 symvers-6.6.3-200.fc39.x86_64.xz
0 symvers-6.6.4-200.fc39.x86_64.xz
0 symvers-6.6.6-200.fc39.x86_64.xz
8.4M System.map-6.6.3-200.fc39.x86_64
8.4M System.map-6.6.4-200.fc39.x86_64
8.4M System.map-6.6.6-200.fc39.x86_64
14M vmlinuz-0-rescue-c9ac45c71f6947ba969445d5e82b0d8b
14M vmlinuz-6.6.3-200.fc39.x86_64
14M vmlinuz-6.6.4-200.fc39.x86_64
14M vmlinuz-6.6.6-200.fc39.x86_64

All those files together are 319Meg on my system. I typically make /boot 1GB or sometimes even 2G.
My distro dynaically links almost all the drivers, but some distro's statically compile them in, that makes
the kernel very large. ( I do have one kernel that's over 220Meg )
 
I'd use sudo apt autoremove --purge which should remove all but the two most recent kernels.
Will this command work?
Code:
sudo apt remove --purge linux-image-6.1.0-13-amd64

Is it safe to get rid of the headers too?

Code:
apt list -i linux-image* linux-headers*
Listing... Done
linux-headers-6.1.0-13-amd64/stable,now 6.1.55-1 amd64 [installed,auto-removable]
linux-headers-6.1.0-13-common/stable,now 6.1.55-1 all [installed,auto-removable]

Thanks for such a quick reply on the weekend.
 
Last edited:
300meg should work, but it's cutting it a bit close.

264K config-6.6.3-200.fc39.x86_64
264K config-6.6.4-200.fc39.x86_64
264K config-6.6.6-200.fc39.x86_64
18M efi
2.4M grub2
111M initramfs-0-rescue-c9ac45c71f6947ba969445d5e82b0d8b.img
36M initramfs-6.6.3-200.fc39.x86_64.img
36M initramfs-6.6.4-200.fc39.x86_64.img
36M initramfs-6.6.6-200.fc39.x86_64.img
24K loader
16K lost+found
0 symvers-6.6.3-200.fc39.x86_64.xz
0 symvers-6.6.4-200.fc39.x86_64.xz
0 symvers-6.6.6-200.fc39.x86_64.xz
8.4M System.map-6.6.3-200.fc39.x86_64
8.4M System.map-6.6.4-200.fc39.x86_64
8.4M System.map-6.6.6-200.fc39.x86_64
14M vmlinuz-0-rescue-c9ac45c71f6947ba969445d5e82b0d8b
14M vmlinuz-6.6.3-200.fc39.x86_64
14M vmlinuz-6.6.4-200.fc39.x86_64
14M vmlinuz-6.6.6-200.fc39.x86_64

All those files together are 319Meg on my system. I typically make /boot 1GB or sometimes even 2G.
My distro dynaically links almost all the drivers, but some distro's statically compile them in, that makes
the kernel very large. ( I do have one kernel that's over 220Meg )
If I resize the /boot partition will the system still boot?
(In a triple booted system)
 
Will this command work?

It should.

Is it safe to get rid of the headers too?

For the deleted kernels, yes.

Remember to leave the most recently previously installed kernel, just as a way to ensure you can boot if the current kernel has issues.
 
Running:
It should.



For the deleted kernels, yes.

Remember to leave the most recently previously installed kernel, just as a way to ensure you can boot if the current kernel has issues.
Didn't rm the previous kernel or the fallback.
Running:
Code:
sudo apt --purge autoremove
Worked.

Rebooted and updated Grub in LMDE6 on this triple booted rig.
Rebooted again into Debian 12 and all is well.

Found this page online to be helpful and it confirms the command that you recommended. Thanks brother!

 
Would a simple script or cron job that run's at boot time automatically rm old kernel's?
 
Thanks brother!

'Snot a problem...

Would a simple script or cron job that run's at boot time automatically rm old kernel's?

You could just run the command as a part of your regular upgrade. You don't technically even need the purge.

This is my alias:

alias update="sudo apt update && sudo apt upgrade -y && sudo apt autoremove

I just type 'update' into the terminal on a regular basis. That keeps things updated and cleaned out. I should probably modify it to 'full-upgrade'

You can assign that whole thing to corn if you want to. Well, minus the alias bit. I've acclimated to this and it's just a normal thing for me to remember to type 'update' in the terminal every so often. I may even do it more than once in a single 24 hour period.
 
I don't ever make a separate partition for /boot - I keep mine under the root partition /

So far it has stood me in good stead.

Wiz
 
I checked on all of my Debian partitions and I can't tell if there are too many kernels or what.
When I did a fresh installation of Debian 12 I gave 300 MiB's for the boot partition. That's what was recommended in the Debian documentation.
In relation to the /boot partition, if one makes it a separate partition, they effectively limit and strangle the filesystem to its given size, and the user then has to be concerned about it, like in this case. If /boot is simply in the /root partition, it works more efficiently with the filesystem in the sense that there's not allocated space in such a partition just taking up space and doing nothing, and the concern about its size disappears.

In any case, in UEFI systems, the EFI system partition is essentially serving the same traditional purpose of the boot partition, and it's really the separate partition that is the only essential one. It doesn't gather up files like a boot partition may with kernels and images and config files. Opinions of course vary on these matters, but that/s not unusual. YMMV.
 
I don't ever make a separate partition for /boot - I keep mine under the root partition /

So far it has stood me in good stead.

Wiz
Thanks, I may go back to that.
Sometimes following the documentation isn't always practical.
 
In relation to the /boot partition, if one makes it a separate partition, they effectively limit and strangle the filesystem to its given size, and the user then has to be concerned about it, like in this case. If /boot is simply in the /root partition, it works more efficiently with the filesystem in the sense that there's not allocated space in such a partition just taking up space and doing nothing, and the concern about its size disappears.

In any case, in UEFI systems, the EFI system partition is essentially serving the same traditional purpose of the boot partition, and it's really the separate partition that is the only essential one. It doesn't gather up files like a boot partition may with kernels and images and config files. Opinions of course vary on these matters, but that/s not unusual. YMMV.
Without performing a fresh install I think I may be limited to increasing the size of the /boot partition.
Right?
 
With what you had at #1, in part

Code:
debian-box:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.8G     0  7.8G   0% /dev
tmpfs           1.6G  1.7M  1.6G   1% /run
/dev/sdb1        77G   14G   59G  20% /
tmpfs           7.8G     0  7.8G   0% /dev/shm
tmpfs           5.0M   12K  5.0M   1% /run/lock
/dev/sdb3       300M  300M     0 100% /boot
/dev/sdb2       480G   12G  444G   3% /home

... it would appear you could carve back a little of the space from /home/ 's 444G available and add it to /boot

If you like, a screenshot from GParted of /dev/sdb might assist, and you would need to perform the operation from /dev/sda or other drive, or else bootable GParted or LiveCD disk.

Wiz
 
With what you had at #1, in part

Code:
debian-box:~$ df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            7.8G     0  7.8G   0% /dev
tmpfs           1.6G  1.7M  1.6G   1% /run
/dev/sdb1        77G   14G   59G  20% /
tmpfs           7.8G     0  7.8G   0% /dev/shm
tmpfs           5.0M   12K  5.0M   1% /run/lock
/dev/sdb3       300M  300M     0 100% /boot
/dev/sdb2       480G   12G  444G   3% /home

... it would appear you could carve back a little of the space from /home/ 's 444G available and add it to /boot

If you like, a screenshot from GParted of /dev/sdb might assist, and you would need to perform the operation from /dev/sda or other drive, or else bootable GParted or LiveCD disk.

Wiz
The WD HDD is where my Slackware installation is:-
Pic of /dev/sdb in g-parted attached--
 

Attachments

  • Slackware.png
    Slackware.png
    192.2 KB · Views: 64
Rebooted and updated Grub in LMDE6 on this triple booted rig.
Rebooted again into Debian 12 and all is well.

If that is still applicable, I think I would leave well enough alone.

Wiz
 
BTW I am no good with Slackware:eek:, yet.
 
If that is still applicable, I think I would leave well enough alone.

Wiz
Agreed.
If I have any more flip flopping of my drives I may have to kick LMDE6 to the curb.
 
BTW I am no good with Slackware:eek:, yet.
Roger that:-
Slackware is a good teacher. It takes time to get well antiquated with it as it's a completely different package management system.:)
 

Members online


Top