FYI:bug: intel-ucode 20241112-1 complains that no space left on device

dalu · 2024-11-13 13:16:23

Upgrading

A 512MB /boot should be large enough for anything.

error: Partition /boot too full: 5125 blocks needed, 4753 blocks free
error: not enough free disk space
error: failed to commit transaction (not enough free disk space)
Errors occurred, no packages were upgraded.
 -> error installing repo packages

The space calculation is wrong.

sudo tree -d /boot
/boot
├── efi
├── grub
│   ├── fonts
│   ├── locale
│   ├── themes
│   │   └── starfield
│   └── x86_64-efi
└── lost+found

9 directories
sudo du -h /boot 
16K	/boot/lost+found
2.4M	/boot/grub/fonts
3.4M	/boot/grub/x86_64-efi
5.3M	/boot/grub/locale
2.9M	/boot/grub/themes/starfield
2.9M	/boot/grub/themes
14M	/boot/grub
4.0K	/boot/efi
433M	/boot

l /boot 
total 420M
drwxr-xr-x  5 root root 4.0K Nov 13 13:47 .
drwxr-xr-x 17 root root  318 Apr  9  2024 ..
drwxr-xr-x  2 root root 4.0K Jan  7  2018 efi
drwxr-xr-x  6 root root 4.0K Feb  2  2024 grub
-rw-------  1 root root 240M Nov 13 13:47 initramfs-linux-fallback.img
-rw-------  1 root root 159M Nov 13 13:47 initramfs-linux.img
-rw-r--r--  1 root root 7.8M Nov 12 18:20 intel-ucode.img
drwx------  2 root root  16K Nov 18  2023 lost+found
-rw-r--r--  1 root root  13M Nov 13 13:40 vmlinuz-linux

sudo df -h /boot 
Filesystem      Size  Used Avail Use% Mounted on
/dev/nvme2n1p2  488M  433M   19M  96% /boot

I had to rm /boot/initramfs-linux-fallback.img
then install intel-ucode
and there's enough space left, as you can see.

Last edited by dalu (2024-11-13 13:16:52)

V1del · 2024-11-13 13:54:47

While there might be something off about the calculation, but you are basically full. The filesystem check happens before removal of the old data so you could argue that it's totally sufficient, but 96% usage and barely 16MB of buffer is really going to be eventually problematic (and if it removes stuff first and then notices you're running out of space, you're basically SOL). One major thing that likely got added was that nouveau supporting GSP firmware will lead to quite a bloating of the initramfs. You could fix that by omitting the kms hook in /etc/mkinitcpio.conf and instead listing the kernel modules you actually want early loaded explicitly, but you're dancing around some big space constraints here.

If you don't change boot related HW you can also consider disabling the generation of the fallback image altogether.

Last edited by V1del (2024-11-13 16:31:51)

WorMzy · 2024-11-13 15:45:15

Not an Installation issue, moving to NC.

cryptearth · 2024-11-13 16:14:02

the guide recommends a boot partition of at least 1gb
https://wiki.archlinux.org/title/Instal … le_layouts

dalu · 2024-11-14 16:32:26

V1del wrote:

While there might be something off about the calculation, but you are basically full. The filesystem check happens before removal of the old data so you could argue that it's totally sufficient, but 96% usage and barely 16MB of buffer is really going to be eventually problematic (and if it removes stuff first and then notices you're running out of space, you're basically SOL). One major thing that likely got added was that nouveau supporting GSP firmware will lead to quite a bloating of the initramfs. You could fix that by omitting the kms hook in /etc/mkinitcpio.conf and instead listing the kernel modules you actually want early loaded explicitly, but you're dancing around some big space constraints here.
If you don't change boot related HW you can also consider disabling the generation of the fallback image altogether.

512-433=79MB is far from full
eventually problematic, with an error message though.
idk how long I've been with arch, 15? years ~ and I've never needed the fallback kernel option, even once,
so thanks, that's what I'll do.

If anyone is interested how,
edit /etc/mkinitcpio.d/linux.preset
replace

PRESETS=('default' 'fallback')

with

PRESETS=('default')

cryptearth wrote:

the guide recommends a boot partition of at least 1gb
https://wiki.archlinux.org/title/Instal … le_layouts

Dude... this is my 24th year with Linux. I've never needed 1GB or even 512MB, not even close.
For instance, my Gentoo server has 7 kernels with initramfs files and system.maps in /boot and uses a whole 165MB.

I know, Mr. smartass will not say but this is Archlinux, to which I'll say, constraints change over the years.
No one likes a smartass.

cryptearth · 2024-11-14 16:54:06

dalu wrote:

cryptearth wrote:
the guide recommends a boot partition of at least 1gb
https://wiki.archlinux.org/title/Instal … le_layouts
Dude... this is my 24th year with Linux. I've never needed 1GB or even 512MB, not even close.
For instance, my Gentoo server has 7 kernels with initramfs files and system.maps in /boot and uses a whole 165MB.
I know, Mr. smartass will not say but this is Archlinux, to which I'll say, constraints change over the years.
No one likes a smartass.

well - no matter the os - if you use the efi system partition only for the bootloader and not overload it with kernels and initrds one can get away with as little as 20-30 MB - hence a regular windows install gets away with just 100 MB - but the way computers boot and where they store the files required has changed
I know linux since the early 2000s - back then a 350mhz amd k6 with 64mb of ram and a sis 6326 with just 8mb of vram was enough - and a 4gb hdd was HUGE - but these days are gone
a modern uefi is more than 16mb - and that's just the compressed image one can download from the support site - and as linux keeps dragging along drivers for decades old hardware with just new stuff gets added on top - well - at some point even 1gb won't be enough anymore to hold all boot data
also - as it seems: instead of first purging old files or just overwrite them both windows and linux seem to go the fallback way: first write the new data and then delete the old one
I also can't tell you why your initrd are so big - mine are about half - so your mkinitcpio seem to add a lot of early boot stuff - maybe check if it's all required

frostschutz · 2024-11-14 16:56:58

This calculation is done by pacman (libalpm/diskspace), and it leaves a safety margin (cushion).

/* cushion is roughly min(5% capacity, 20MiB) */

https://gitlab.archlinux.org/pacman/pac … c#L354-358

mesaprotector · 2024-11-14 18:25:58

You can also likely compress the initramfs more in /etc/mkinitcpio.conf. If you wanted to keep the fallback image (though I've never needed it either) I bet this would add enough free space to solve the issue.

I'm guess you have a few extra modules specified in mkinitcpio.conf, because 240MB is huge, even for a fallback. Even with the nvidia modules added in I didn't get near that.

V1del · 2024-11-14 18:51:32

If I'd wager a guess then potentially all the linux-firmware packages are installed, despite likely not needing most of them and/or the default kms hook, which will bring in all the nvidia firmware needed for Turing since nouveau got support for it.

ewaller · 2024-11-14 19:10:29

Might I suggest we tone down the drama a bit and stick to the technical discussion?

Arch Linux

#1 2024-11-13 13:16:23

FYI:bug: intel-ucode 20241112-1 complains that no space left on device

#2 2024-11-13 13:54:47

Re: FYI:bug: intel-ucode 20241112-1 complains that no space left on device

#3 2024-11-13 15:45:15

Re: FYI:bug: intel-ucode 20241112-1 complains that no space left on device

#4 2024-11-13 16:14:02

Re: FYI:bug: intel-ucode 20241112-1 complains that no space left on device

#5 2024-11-14 16:32:26

Re: FYI:bug: intel-ucode 20241112-1 complains that no space left on device

#6 2024-11-14 16:54:06

Re: FYI:bug: intel-ucode 20241112-1 complains that no space left on device

#7 2024-11-14 16:56:58

Re: FYI:bug: intel-ucode 20241112-1 complains that no space left on device

#8 2024-11-14 18:25:58

Re: FYI:bug: intel-ucode 20241112-1 complains that no space left on device

#9 2024-11-14 18:51:32

Re: FYI:bug: intel-ucode 20241112-1 complains that no space left on device

#10 2024-11-14 19:10:29

Re: FYI:bug: intel-ucode 20241112-1 complains that no space left on device

Board footer