GRUB Partition Full on some systems

W54J04S07T · 2025-08-15 14:09:15

FYI...

As of today running pacman -Syu for full update results in the GRUB partition getting filled.
The culprit "appears" to be with mkinitcpio, but this is intermittent. It results in linux and linux-lts
image ( .img ) files which are quite large ( 120 -180MB for fallback images ) and low double digit MB size
( as opposed to e.g. 9MB on other systems boot images ) .

Running a separate "mkinitcpio -p linux" does not correct this problem.

Any idea why some images in the grub partition are typically small and
some seemingly random systems will generate outsized images?

V1del · 2025-08-15 14:33:17

Fallback includes everything, they are expected to grow large. The biggest size increase will be linux-firmware-nvidia, which you could just remove if you don't have an nvidia card. Alternatively if you aren't changing your boot relevant HW often it's also fairly safe to not generate the fallback image and only generate the image that will only include modules that are in active use on the system: https://wiki.archlinux.org/title/Mkinit … generation, also the kms hook that's active by default will lead to loading of every GPU driver even if you don't actually have them, a good option to get the early KMS effect is to remove that hook but explicitly list out the GPU modules in use in the modules section.

Last edited by V1del (2025-08-15 14:34:48)

mpan · 2025-08-15 14:37:37

The “/boot” seems to be too small. No less than 1G is recommended nowadays.

If it’s intermittent, it may be because the new image is being built before the old one is removed.

The main culprit is likely your video card firmware (picked up by the kms hook) or the fallback image. The latter is needed, if you change your hardware, including USB-attached devices. So if both of those conditions are met:

You don’t plan to change hardware,
You have a recent live USB and it works,

you should be able to safely skip generating fallback images. See “/etc/mkinitcpio.d/linux.preset” and the `PRESETS` line. Mind that you still need to remove the old image after that.

cryptearth · 2025-08-15 15:22:09

mpan wrote:

it may be because the new image is being built before the old one is removed.

this would hint towards someone had a bad play with hooks already as usually when pacman sees a mkinitcpio required it first purges the existing kernel and initrd and then building the new ones
so on a "regular" arch setup it should never happen that first new stuff is tried to put in place before the old one gets deleted - as it would result in just overwriting the existing files and then deleting them ending up in no boot files at all

@OP
what's the size of your /boot? seems to be a mountpoint and hence either the ESP or a separate XBOOTLDR
if it's your ESP it's likely at the start of your drive with your root (or swap) partition following
I recommend to NOT try to move you root to the right as it will require extensive copying of all affected data (and caused dataloss in the past by people getting impatient when they see several hours) - rather either make /boot not a mountpoint anymore but rather use /efi for your ESP and bootloader only or shrink your last partition from the right to make space for an additional XBOOTLDR which usually only requires slight modifications of the filesystem before altering the partition

// edit
out of fun
/efi - just for grub on a 1GB ESP: 16MB
/boot - on / but I thought about to change that: 55MB
so alltogether about 70MB - would even fit on a default 100MB Windows-ESP as the windows boot stuff takes up about 20MB - yes, would be a tight fit but a fit nonetheless
so running out of space for grub? don't understand the question

Last edited by cryptearth (2025-08-15 15:39:39)

mpan · 2025-08-15 16:53:30

cryptearth wrote:

mpan wrote:
it may be because the new image is being built before the old one is removed.
this would hint towards someone had a bad play with hooks already as usually when pacman sees a mkinitcpio required it first purges the existing kernel and initrd and then building the new ones
so on a "regular" arch setup it should never happen that first new stuff is tried to put in place before the old one gets deleted - as it would result in just overwriting the existing files and then deleting them ending up in no boot files at all

I’d swear this is a regular Arch setup and I didn’t had a bad play with hooks. Yet clearly images are built on triggers which are not used for image removal.

60-mkinitcpio-remove.hook:

[Trigger]
Type = Path
Operation = Remove
Target = usr/lib/modules/*/vmlinuz

[Trigger]
Type = Package
Operation = Remove
Target = mkinitcpio
Target = mkinitcpio-git

[Action]
Description = Removing linux initcpios...
When = PreTransaction
Exec = /usr/share/libalpm/scripts/mkinitcpio remove
NeedsTargets

90-mkinitcpio-install.hook

[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Operation = Remove
Target = usr/lib/initcpio/*
Target = usr/lib/firmware/*
Target = usr/src/*/dkms.conf
Target = usr/lib/systemd/systemd
Target = usr/bin/cryptsetup
Target = usr/bin/lvm

[Trigger]
Type = Path
Operation = Install
Operation = Upgrade
Target = usr/lib/modules/*/vmlinuz

[Trigger]
Type = Package
Operation = Install
Operation = Upgrade
Target = mkinitcpio
Target = mkinitcpio-git

[Action]
Description = Updating linux initcpios...
When = PostTransaction
Exec = /usr/share/libalpm/scripts/mkinitcpio install
NeedsTargets

Last edited by mpan (2025-08-15 16:53:50)

W54J04S07T · 2025-08-15 18:35:12

V1del wrote:

Fallback includes everything, they are expected to grow large. The biggest size increase will be linux-firmware-nvidia, which you could just remove if you don't have an nvidia card. Alternatively if you aren't changing your boot relevant HW often it's also fairly safe to not generate the fallback image and only generate the image that will only include modules that are in active use on the system: https://wiki.archlinux.org/title/Mkinit … generation, also the kms hook that's active by default will lead to loading of every GPU driver even if you don't actually have them, a good option to get the early KMS effect is to remove that hook but explicitly list out the GPU modules in use in the modules section.

Well, in one case the GPU is nVidia... an old laptop that isn't likely to ever have a H/W change.
So this ( eliminate fallback generation ) might be the best for that machine.

The other is a integrated AMD cpu/gpu... doesn't need nvidia.

W54J04S07T · 2025-08-15 18:43:55

cryptearth wrote:

mpan wrote:
...
@OP
what's the size of your /boot? seems to be a mountpoint and hence either the ESP or a separate XBOOTLDR
if it's your ESP it's likely at the start of your drive with your root (or swap) partition following
I recommend to NOT try to move you root to the right as it will require extensive copying of all affected data (and caused dataloss in the past by people getting impatient when they see several hours) - rather either make /boot not a mountpoint anymore but rather use /efi for your ESP and bootloader only or shrink your last partition from the right to make space for an additional XBOOTLDR which usually only requires slight modifications of the filesystem before altering the partition
// edit
out of fun
/efi - just for grub on a 1GB ESP: 16MB
/boot - on / but I thought about to change that: 55MB
so alltogether about 70MB - would even fit on a default 100MB Windows-ESP as the windows boot stuff takes up about 20MB - yes, would be a tight fit but a fit nonetheless
so running out of space for grub? don't understand the question

All these machines are 512MB Grub partition ( a basic setup from > 5 years ago )
followed by
xx - GB swap
followed by xxx - GB /root

... so I take it from your comments, that it might be possible to shrink SWAP by .5-1GB
and expand GRUB partition to 1GB ... Am i reading you correctly? Is this do-able
and is it a simple matter thru "GParted" on a live system or is there a better
( safer ) option to do this? Details?

Last edited by W54J04S07T (2025-08-15 18:46:09)

close2zero · 2025-08-15 19:18:30

There are probably a safer way to do this. But then you have to wait until someone more suitable than me to provide you with a bettes and safer solution.

You are lucky you've got your swap- and not your root partition after /boot. Then it is a bit safer to fix. There is always a risk using gparted. So if you're going to use it, make sure to make a full system backup using rsync before you use gparted to fix this issue.

Yes you can shrink your swap partition and grow your /boot partition. If you are going down this path you need to turn your swap off (swapoff) and umount your /boot. Then you can shrink your swap partition first. Then grow your /boot partition. I don't remember if gparted is making a new PARTUUID by doing this. If that is the case, make sure you to make a record of them, so you can put the correct PARTUUID back with gparted, if it has that option. If not use tune2fs to do it.

If you will go for this option, do not do it without having archiso on a thumb-drive, and as I've mentioned before: Do a full system backup using rsync.

seth · 2025-08-15 21:00:17

All these machines are 512MB Grub partition ( a basic setup from > 5 years ago )
followed by
xx - GB swap
followed by xxx - GB /root

PSA: this is a *terrible* topic to paraphrase on.

We don't even know what you're referencing but the partition layout doesn't even have to align w/ the count.
Post the output of "fdisk -l"

In general and theory you could umount the /boot partition, swapoff the swap disk, alter the partition table, grow the FS of the /boot partition, partprobe, mkswap, swapon and be done.
In particular practice, you might find yourself swearing while searching for your backups…

W54J04S07T · 2025-08-16 15:32:56

seth wrote:

All these machines are 512MB Grub partition ( a basic setup from > 5 years ago )
followed by
xx - GB swap
followed by xxx - GB /root
PSA: this is a *terrible* topic to paraphrase on.
We don't even know what you're referencing but the partition layout doesn't even have to align w/ the count.
Post the output of "fdisk -l"

sample SDA system disk...

Disk /dev/sda: 232.89 GiB, 250059350016 bytes, 488397168 sectors
Disk model: Samsung SSD 850
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: nnnnnnnnnnnnnnnnnnnnnnnnnnnn

Device Start End Sectors Size Type
/dev/sda1 2048 65535 63488 31M BIOS boot
/dev/sda2 65536 1114111 1048576 512M Linux filesystem
/dev/sda3 1114112 136144895 135030784 64.4G Linux swap
/dev/sda4 136144896 488397134 352252239 168G Linux filesystem

... and yes they are all done this way for about 9 years now.

In general and theory you could umount the /boot partition, swapoff the swap disk, alter the partition table, grow the FS of the /boot partition, partprobe, mkswap, swapon and be done.

Thankyou for this.
In fact, I fired up a test virtual machine to try this on ... just in case...
In practice I found that you simply fire up Gparted and do almost everything you mentioned in there.
SwapOff the swap partition
shrink the swap partition by 512MB from the beginning of the partition
SwapOn the partition. (<<< and select apply )
select the grub partition ( SDA2 in the above fdisk example )
Unmount ( right click on the grub partition and select )
expand the GRUB partition by 512MB
Mount the partition to /BOOT
select apply.
reboot...

In particular practice, you might find yourself swearing while searching for your backups…

Expletives are standard around here... all day everyday... and are deleted often...

seth · 2025-08-16 15:51:40

For the posted layout it's safe to merge steal the head of sda3 into sda2 (and as mentioned: since neither swap - provided sufficient RAM - nor /boot are runtime critical, you can do this online)
nb. that the start and end sectors are what's relevant here, never the partition index (so if you had created that layout but sda1,2,4,3 you'd still be good to steal from 4 into 2, but if the swap was not directly behind he grub partition, things would get more dicey)

W54J04S07T · 2025-08-16 16:22:31

seth wrote:

For the posted layout it's safe to merge steal the head of sda3 into sda2 (and as mentioned: since neither swap - provided sufficient RAM - nor /boot are runtime critical, you can do this online)
nb. that the start and end sectors are what's relevant here, never the partition index (so if you had created that layout but sda1,2,4,3 you'd still be good to steal from 4 into 2, but if the swap was not directly behind he grub partition, things would get more dicey)

It occurs to me that the current "archinstall" script for new installs should probably default
to 2GB for GRUB along with the option to change it during new installs. These days with swap on RAM etc...
it goes straight from GRUB to root partition... so a little (or a lot )
of leeway for GRUB might be the safe move.

Consider a GRUB with Linux, Linux-lts, Linux-zen, linux-hardened, etc ...
yeah, the now standard 1GB for Grub might not cut it anymore...

Arch Linux

#1 2025-08-15 14:09:15

GRUB Partition Full on some systems

#2 2025-08-15 14:33:17

Re: GRUB Partition Full on some systems

#3 2025-08-15 14:37:37

Re: GRUB Partition Full on some systems

#4 2025-08-15 15:22:09

Re: GRUB Partition Full on some systems

#5 2025-08-15 16:53:30

Re: GRUB Partition Full on some systems

#6 2025-08-15 18:35:12

Re: GRUB Partition Full on some systems

#7 2025-08-15 18:43:55

Re: GRUB Partition Full on some systems

#8 2025-08-15 19:18:30

Re: GRUB Partition Full on some systems

#9 2025-08-15 21:00:17

Re: GRUB Partition Full on some systems

#10 2025-08-16 15:32:56

Re: GRUB Partition Full on some systems

#11 2025-08-16 15:51:40

Re: GRUB Partition Full on some systems

#12 2025-08-16 16:22:31

Re: GRUB Partition Full on some systems

Board footer