Problem booting after Core 162 on Pi3 because /boot directory full

Hi Firemen,
After upgrading to core 162 after 161 before, directory /boot full I got message Pi continue to work fine with old kernel but Pi does not reboot anymore.
I am flashing a new card, and I ll give more space to /boot, but for future Ill prefer cleanning the directory removing old kernesl execept 2 like I do with grub.
Don’t find how to Can the gurus tell me ?
Thanks and Happy New Year Happy tax payers !

Hi,

indeed, over the time, the Linux kernel we ship grew bigger and bigger. Eventually, some very old installations suffer from their /boot partition being too small for an updated kernel.

A reinstallation is the only way to fix this, since we cannot change the partition layout while running on the same mounted partitions.

However, IPFire does only store the current kernel in `/boot/, such as 5.15.6 in this case:

[root@maverick ~]# ls -lah /boot
total 31M
drwxr-xr-x  5 root root 4.0K Dec 12 20:28 .
drwxr-xr-x 21 root root 4.0K Sep  4 10:47 ..
-rw-r--r--  1 root root 178K Dec 12 17:58 config-5.15.6-ipfire
drwxr-xr-x  3 root root  16K Jan  1  1970 efi
drwxr-xr-x  6 root root 4.0K Dec 15 10:32 grub
-rw-r--r--  1 root root  19M Dec 12 18:01 initramfs-5.15.6-ipfire.img
drwx------  2 root root  16K Sep 19  2019 lost+found
-rw-r--r--  1 root root 4.7M Dec 12 17:58 System.map-5.15.6-ipfire
-rw-r--r--  1 root root 6.7M Dec 12 17:58 vmlinuz-5.15.6-ipfire

You should not see any leftovers in /boot, so there is nothing to clean up.

Hope to have helped. :slight_smile:

Thanks, and best regards,
Peter Müller

The Pi version may have missed some of the clean-up…

[root@ipfireRPi4B2 ~]# ls -lah /boot
total 83M
drwxr-xr-x  9 root root  16K Dec 31  1969 .
drwxr-xr-x 21 root root 4.0K Dec 31  1969 ..
-rwxr-xr-x  1 root root  49K Oct 13 08:49 bcm2711-rpi-400.dtb
-rwxr-xr-x  1 root root  49K Oct 13 08:49 bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root root  50K Oct 13 08:49 bcm2711-rpi-cm4.dtb
-rwxr-xr-x  1 root root 2.4K Aug  9 04:19 boot.cmd
-rwxr-xr-x  1 root root  52K Nov 18 10:22 bootcode.bin
-rwxr-xr-x  1 root root   67 Aug  9 04:19 boot.mk
-rwxr-xr-x  1 root root 2.4K Aug  9 04:19 boot.scr
-rwxr-xr-x  1 root root 202K Dec 20 17:03 config-5.15.6-ipfire
-rwxr-xr-x  1 root root 1.9K Dec 26 17:38 config.txt
drwxr-xr-x 10 root root 2.0K Aug  9 03:11 dtb-5.10.55-ipfire
drwxr-xr-x 10 root root 2.0K Nov 17 11:32 dtb-5.10.76-ipfire
drwxr-xr-x 10 root root 2.0K Dec 20 17:04 dtb-5.15.6-ipfire
drwxr-xr-x  3 root root  16K Dec 31  1969 efi
-rwxr-xr-x  1 root root 3.2K Nov 18 10:22 fixup4cd.dat
-rwxr-xr-x  1 root root 5.3K Nov 18 10:22 fixup4.dat
-rwxr-xr-x  1 root root 8.3K Nov 18 10:22 fixup4db.dat
-rwxr-xr-x  1 root root 8.3K Nov 18 10:22 fixup4x.dat
-rwxr-xr-x  1 root root 3.2K Nov 18 10:22 fixup_cd.dat
-rwxr-xr-x  1 root root 7.2K Nov 18 10:22 fixup.dat
-rwxr-xr-x  1 root root  11K Nov 18 10:22 fixup_db.dat
-rwxr-xr-x  1 root root  11K Nov 18 10:22 fixup_x.dat
drwxr-xr-x  5 root root 2.0K Dec 26 15:27 grub
-rwxr-xr-x  1 root root 7.4M Dec 20 17:06 initramfs-5.15.6-ipfire.img
-rwxr-xr-x  1 root root 783K Nov 18 10:22 start4cd.elf
-rwxr-xr-x  1 root root 3.6M Nov 18 10:22 start4db.elf
-rwxr-xr-x  1 root root 2.2M Nov 18 10:22 start4.elf
-rwxr-xr-x  1 root root 2.9M Nov 18 10:22 start4x.elf
-rwxr-xr-x  1 root root 783K Nov 18 10:22 start_cd.elf
-rwxr-xr-x  1 root root 4.6M Nov 18 10:22 start_db.elf
-rwxr-xr-x  1 root root 2.9M Nov 18 10:22 start.elf
-rwxr-xr-x  1 root root 3.6M Nov 18 10:22 start_x.elf
-rwxr-xr-x  1 root root 4.8M Dec 20 17:03 System.map-5.15.6-ipfire
-rwxr-xr-x  1 root root 128K Aug  9 04:19 uboot.env
-rwxr-xr-x  1 root root 545K Aug  9 04:19 u-boot-rpi3.bin
-rwxr-xr-x  1 root root 591K Aug  9 04:19 u-boot-rpi4.bin
-rwxr-xr-x  1 root root  113 Dec 26 17:19 uEnv.txt
-rwxr-xr-x  1 root root  115 Dec 26 15:26 uEnv.txt.org
-rwxr-xr-x  1 root root 7.3M Aug  9 03:13 uInit-5.10.55-ipfire
-rwxr-xr-x  1 root root 7.5M Nov 17 11:35 uInit-5.10.76-ipfire
-rwxr-xr-x  1 root root 7.4M Dec 20 17:06 uInit-5.15.6-ipfire
-rwxr-xr-x  1 root root  26M Dec 20 17:03 vmlinuz-5.15.6-ipfire

EDIT: boot got a little full…

[root@ipfireRPi4B2 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        1.9G     0  1.9G   0% /dev
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           1.9G  272K  1.9G   1% /run
/dev/mmcblk1p3  7.2G  1.5G  5.4G  22% /
/dev/mmcblk1p1  124M  109M   16M  88% /boot
/dev/mmcblk1p2   32M  302K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock
none            1.9G   28M  1.9G   2% /var/log/rrd
none            1.9G  228K  1.9G   1% /var/log/vnstat

Peter,

I believe there is a more fundamental issue with arm6hl compilations. Jon’s post displays what I experienced with both nanopi R1 and bananapi, namely the dross from kernel 5.10.55, that was used with core 160, is retained after upgrade to core 161. That does not over-fill /boot, but the subsequent upgrade to core 162 certainly does, resulting in unrecoverable failure to reboot to core 162.

dtb-5.10.55-ipfire is the main space hog. Anyone who installed at core 160 or earlier, needs to delete that dtb, without fail, prior to upgrading to core 162. It might also be necessary to manually delete dtb-5.10.76-ipfire prior to eventual upgrade to core 163.

Perhaps there is a script in the upgrade process that requires a simple fix ?

Hi everybody Sorry for late answer. For the moment fixed the issue without re installing. Extracted SD moved / partition which is 6G and enlarged /boot to 1G. Copied the /boot of new image with core 162 to old bad boot. Changed the UUID in /boot/uEnv.txt and /etc/fstab. Every OK Didn’t lost anything.

But for THE problem I mentionned, I was talking of Pi3 ( No EFI ) and it seems you are talking of Pi4. Installed first core 160, then updated 161 everything was OK. During update core 162, I got message /boot directory full and so it seems some files were missing in the installed update. The reason is that 3 directories dtb-5… ( one per update ) are present and stay here after each update. Each one is 25M . For my opinin it will be good idea to remove the older one when update is over to save place on boot and may be enlarge a bit /boot on future images… Fill free to ask for more if necessary. Have a nice day

I have found the problem the update check the space on root and then execute:

# Remove the old kernel
rm -rf /boot/System.map-*
rm -rf /boot/config-*
rm -rf /boot/ipfirerd-*
rm -rf /boot/initramfs-*
rm -rf /boot/vmlinuz-*
rm -rf /boot/uImage-*-ipfire-*
rm -rf /boot/zImage-*-ipfire-*
rm -rf /boot/uInit-*-ipfire-*
rm -rf /boot/dtb-*-ipfire-*
rm -rf /lib/modules

We have renamed the kernel, it now has no - after ipfire. (before there was a -multi after this). I will fix this at the next kernel update

4 Likes

Hi,

as Arne already mentioned, this commit fixes the cleanup procedure on ARM devices again.

Sorry for my too optimistic assumption in the first place. :slight_smile:

Thanks, and best regards,
Peter Müller

1 Like

Hi congratulatons to all of you. Good work and Great Software I love !
Sorry for dummy suggestion. I just begin with ipfire.
Happy new year !

Hi,

no worries, this was the exact opposite of a dumb question: You discovered a bug in IPFire and helped us fixing it! :slight_smile:

All the best for 2022!

Thanks, and best regards,
Peter Müller

2 Likes