Again with the file system full. Core 169

roberto · 5 July 2022 09:10

Hi guys.

I have tried to update to “IPFire 2.27 (aarch64) - Core Update 169 Development Build: master/8000bc0a” and this appears:

Regards.

rodneyp · 5 July 2022 22:15

I reported this for core 168, which also put a warning on the Home page. That did update to core 169 and media usage was similar.

file-system-full

It looks like being an ongoing problem for aarch64, which is accommodating both boards that use grub bootloader and require “initramfs” as well as boards relying on “uInit”. Both files are approximately 15 MB. The “dtb” directory can also be expected to increase in size, as more boards are added.

Simplest solution is looking like a larger /boot partition

xperimental · 5 July 2022 23:35

+1. I also reported that for core 167. It seems to be only with arm architecture.

rodneyp · 5 July 2022 23:59

The size of initramfs & uInit have each blown out from 7.7 MB to almost 15 MB in just two minor release updates of kernel. Maybe there is something erroneous in collation of initramfs, in IPF ?

pmueller · 7 July 2022 05:37

Hi all,

first, thank you all for reporting this!

Second, zut alors, I am sorry that this bug slipped into the testing release again. Will take care of a fix, apologies for the inconvenience.

Thanks, and best regards,
Peter Müller

pmueller · 9 July 2022 09:52

Hi all,

this commit deletes the obsolete initial ramdisk on 32-bit ARM systems, preventing /boot from running out of space. The most recent version of Core Update 169 now comes with this fix, so the problem should not occur again.

(On 64-bit ARM, we cannot delete the initrd, since it is required for booting. So this only affects 32-bit ARM devices.)

Thanks, and best regards,
Peter Müller

roberto · 12 July 2022 16:28

With the Core 169 it is not solved.

The only solution (not a solution) is to comment out the “index.cgi” line.

Regards.

pmueller · 13 July 2022 10:58

Hi,

thank you for reporting this.

(To be blunt, I am losing my patience with the ARM desaster. According to Fireinfo, 2.79% of all IPFire installations are running on some kind of ARM device, yet those create like 50% of all the efforts I have to put into Core Updates. I am really not satisfied with this situation… )

All right, what’s the output of

ls -lah /boot

please?

This is not a solution at all, since silencing a warning does not fix the underlying issue the warning should bring to your attention.

Thanks, and best regards,
Peter Müller

jon · 13 July 2022 15:36

FWIW - The upgrade of a RPi4B to CU 169 worked well for me. No issues found.

EDIT: If there is info you’d like me to post, please feel free to ask.

roberto · 13 July 2022 18:32

Hi @pmueller. Thanks for your reply.

This is what I get:

[root@bs ~]# ls -lah /boot
total 85M
drwxr-xr-x  6 root root  16K Jan  1  1970  .
drwxr-xr-x 21 root root 4.0K Jul 12 13:39  ..
-rwxr-xr-x  1 root root  49K Oct 13  2021  bcm2711-rpi-400.dtb
-rwxr-xr-x  1 root root  49K Oct 13  2021  bcm2711-rpi-4-b.dtb
-rwxr-xr-x  1 root root  50K Oct 13  2021  bcm2711-rpi-cm4.dtb
-rwxr-xr-x  1 root root 2.4K May  8 11:58  boot.cmd
-rwxr-xr-x  1 root root  52K Nov 18  2021  bootcode.bin
-rwxr-xr-x  1 root root   67 May  8 11:58  boot.mk
-rwxr-xr-x  1 root root 2.5K May  8 11:58  boot.scr
-rwxr-xr-x  1 root root 202K Jul  7 22:39  config-5.15.49-ipfire
-rwxr-xr-x  1 root root 1.9K Mar 31 10:31  config.txt
drwxr-xr-x 10 root root 2.0K Jul  7 22:40  dtb-5.15.49-ipfire
drwxr-xr-x  4 root root  16K Jan  1  1970  efi
-rwxr-xr-x  1 root root 3.2K Nov 18  2021  fixup4cd.dat
-rwxr-xr-x  1 root root 5.3K Nov 18  2021  fixup4.dat
-rwxr-xr-x  1 root root 8.3K Nov 18  2021  fixup4db.dat
-rwxr-xr-x  1 root root 8.3K Nov 18  2021  fixup4x.dat
-rwxr-xr-x  1 root root 3.2K Nov 18  2021  fixup_cd.dat
-rwxr-xr-x  1 root root 7.2K Nov 18  2021  fixup.dat
-rwxr-xr-x  1 root root  11K Nov 18  2021  fixup_db.dat
-rwxr-xr-x  1 root root  11K Nov 18  2021  fixup_x.dat
drwxr-xr-x  5 root root 2.0K Jul 12 13:26  grub
-rwxr-xr-x  1 root root  15M Jul  7 22:41  initramfs-5.15.49-ipfire.img
-rwxr-xr-x  1 root root 783K Nov 18  2021  start4cd.elf
-rwxr-xr-x  1 root root 3.6M Nov 18  2021  start4db.elf
-rwxr-xr-x  1 root root 2.2M Nov 18  2021  start4.elf
-rwxr-xr-x  1 root root 2.9M Nov 18  2021  start4x.elf
-rwxr-xr-x  1 root root 783K Nov 18  2021  start_cd.elf
-rwxr-xr-x  1 root root 4.6M Nov 18  2021  start_db.elf
-rwxr-xr-x  1 root root 2.9M Nov 18  2021  start.elf
-rwxr-xr-x  1 root root 3.6M Nov 18  2021  start_x.elf
-rwxr-xr-x  1 root root 4.9M Jul  7 22:39  System.map-5.15.49-ipfire
drwxr-xr-x  2 root root 2.0K Apr 13 14:36 'System Volume Information'
-rwxr-xr-x  1 root root 128K May  8 11:58  uboot.env
-rwxr-xr-x  1 root root 545K May  8 11:57  u-boot-rpi3.bin
-rwxr-xr-x  1 root root 591K May  8 11:57  u-boot-rpi4.bin
-rwxr-xr-x  1 root root  167 Jul 12 13:26  uEnv.txt
-rwxr-xr-x  1 root root  167 Jul 12 13:23  uEnv.txt.org
-rwxr-xr-x  1 root root  15M Jul  7 22:41  uInit-5.15.49-ipfire
-rwxr-xr-x  1 root root  27M Jul  7 22:39  vmlinuz-5.15.49-ipfire
[root@bs ~]#

I know it’s not a solution, but it’s to not see that bleeding note.

Best regards.

pmueller · 13 July 2022 18:40

Hi,

I am puzzled to see this one still being present on your system, since this is precisely the file my aforementioned commit should have deleted during the upgrade.

Thanks, and best regards,
Peter Müller

roberto · 13 July 2022 18:47

Hi again @pmueller.

So, I could delete it without fear, right?.

Thks

pmueller · 13 July 2022 18:49

Oh, wait, you are running on ARM64, not ARM32, are you?

roberto · 13 July 2022 18:52

This is my profile:

https://fireinfo.ipfire.org/profile/7e28e7a0e63dac590109d065a871811a7dfc794b

In footer putting this:

IPFire 2.27 (aarch64) - Core Update 169

Thanks

pmueller · 13 July 2022 18:55

Hi,

in this case, you will need the initial ramdisk for booting, please do not delete it.

That puts (a) me at ease because my commit apparently wasn’t a NOOP and (b) us back to the drawing board for finding out why /boot is that full on your machine…

Thanks, and best regards,
Peter Müller

jon · 13 July 2022 21:15

my list looks almost identical. All of the files sizes are the same except for three near the bottom of the list.

Roberto’s list is on the left and my list is on the right.

[root@ipfireRPi4B9 ~]# 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  264K  1.9G   1% /run
/dev/mmcblk1p3  7.2G  1.6G  5.3G  23% /
/dev/mmcblk1p1  124M   97M   27M  79% /boot
/dev/mmcblk1p2   32M  302K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock
none            1.9G  228K  1.9G   1% /var/log/vnstat
none            1.9G   31M  1.9G   2% /var/log/rrd

rodneyp · 13 July 2022 22:10

As mentioned earlier, the size of initramfs suddenly doubled, with one core update. It seems unlikely that the size of the modules within would have doubled, so were additional modules included and are those necessary ? As I understand it, initramfs need contain only modules such as SATA, USB, sd, ext4 and vfat, needed for booting, although network modules might also be required, because booting of IPFire will hang if red0 is not active.

The issue might not be confined to ARM, because initramfs in x86_64 has become almost as large, but without uInit there, disk free is not a problem

arne_f · 14 July 2022 06:59

There are RPi4 dtb files present so this is an arm64 system, the initramfs should be here for grub.
conclusion: 128 MB boot is to small for the future…

arne_f · 14 July 2022 07:06

The new dracut version put more firmware and modules to the initrd to solve some compatiblity problems, also it use a different/faster compression.

rodneyp · 14 July 2022 23:49

Noted

When a testing release is likely to fill a 128 MiB /boot, on aarch64, could that please be flagged in the release announcement.

My only aarch64 is a nanopi R1S H5, which does not run IPFire reliably anyway, but is on a uSD card and could fairly easily have partitions resized. What size /boot is the project likely to implement ?