/boot too small to upgrade kernel using f2fs

[PhracturedBlue]

This appears to be the same issue as: https://github.com/armbian/build/issues/1318

As of using kernel 5.9.10 on LePotato with f2fs as my root filesystem using EMMC boot, I was unable to update from 20.11 to 20.11.3 (5.9.14) without manually removing the old kernel 1st. I do not have multiple kernels installed and this is a fresh install from 5.9.10. The error was an out of disk-space condition:

Performing actions...
(Reading database ... 158588 files and directories currently installed.)
Preparing to unpack .../linux-dtb-current-meson64_20.11.3_arm64.deb ...
Unpacking linux-dtb-current-meson64 (20.11.3) over (20.11) ...
dpkg: error processing archive /var/cache/apt/archives/linux-dtb-current-meson64_20.11.3_arm64.deb (--unpack):
 cannot copy extracted data for './boot/dtb-5.9.14-meson64/amlogic/meson-gxl-s905d-libretech-pc.dtb' to '/boot/dtb-5.9.14-meson64/amlogic/meson-gxl-s905d-libretech-pc.dtb.dpkg-new': failed to write (No space left on device)
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Preparing to unpack .../linux-image-current-meson64_20.11.3_arm64.deb ...
Unpacking linux-image-current-meson64 (20.11.3) over (20.11) ...
dpkg: error processing archive /var/cache/apt/archives/linux-image-current-meson64_20.11.3_arm64.deb (--unpack):
 cannot copy extracted data for './boot/System.map-5.9.14-meson64' to '/boot/System.map-5.9.14-meson64.dpkg-new': failed to write (No space left on device)
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/linux-dtb-current-meson64_20.11.3_arm64.deb
 /var/cache/apt/archives/linux-image-current-meson64_20.11.3_arm64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)

The filesystem was 100% full:

cd /boot; ls -lart
total 81335
drwxr-xr-x 19 root root     4096 Nov 25 03:15 ..
-rw-r--r--  1 root root  5121511 Dec 12 10:35 System.map-5.9.10-meson64
drwxr-xr-x  4 root root     1024 Dec 12 10:35 dtb-5.9.10-meson64
-rw-r--r--  1 root root   222558 Dec 12 10:35 config-5.9.10-meson64
-rw-r--r--  1 root root    38518 Dec 12 10:35 boot.bmp
-rw-r--r--  1 root root     1536 Dec 12 10:35 armbian_first_run.txt.template
-rw-r--r--  1 root root 24869376 Dec 12 10:35 vmlinuz-5.9.10-meson64
lrwxrwxrwx  1 root root       22 Dec 12 10:35 uInitrd -> uInitrd-5.9.10-meson64
-rw-r--r--  1 root root     7074 Dec 12 10:35 boot.cmd
-rw-r--r--  1 root root     7146 Dec 22 08:56 boot.scr
-rw-r--r--  1 root root 14067987 Dec 22 08:57 uInitrd-5.9.10-meson64
-rw-r--r--  1 root root 14067923 Dec 22 08:57 initrd.img-5.9.10-meson64
-rw-r--r--  1 root root        0 Dec 22 10:45 armbianEnv.txt.out
-rw-r--r--  1 root root      161 Dec 22 21:15 armbianEnv.txt
lrwxrwxrwx  1 root root       18 Dec 23 05:22 dtb -> dtb-5.9.10-meson64
-rw-r--r--  1 root root        0 Dec 23 05:23 .next
lrwxrwxrwx  1 root root       22 Dec 23 05:23 Image -> vmlinuz-5.9.10-meson64
drwxr-xr-x  3 root root     1024 Dec 23 05:23 .
-rw-r--r--  1 root root 24869440 Dec 23 05:23 uImage

df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p1   89M   86M     0 100% /boot

After removing the 5.9.10 kernel, I was able to upgrade to 5.9.14, but just barely:

df -h .
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk0p1   89M   87M     0 100% /boot

It appears that the best option is to use an ext4 boot if kernels are going to continue to grow this way? Maybe f2fs should not be offered as an option?

[lanefu]

Were you upgrading via apt. or via dpkg?

Uninstalling prior kernel historically has been the normal process, but the upgrade process is supposed to uninstall the prior package first... may be an issue there.

A recent commit also increased the default boot volume size to 200meg, so that will be default on future release images... the nand-sata-install script needs to be updated to change that default as well.

[PhracturedBlue]

I used aptitude which is my standard package management system. after hitting the above, re-installing the needed packages left me with a corrupted ramdisk (I have no idea why, but the 1st 64bytes of uInitrd were zeroed-out making u-boot unable to parse it) Since I needed to repartition the boot disk anyway, I've just gone to ext4 which makes this entire set of issues go away. After that, the update to 5.9.14 went smoothly

[lanefu]

Okay. Thanks for reporting. Sorry it happened.

[EvilOlaf]

A recent commit also increased the default boot volume size to 200meg, so that will be default on future release images... the nand-sata-install script needs to be updated to change that default as well.

It should be already? https://github.com/armbian/build/commit/4947f95b4612d533982baa1641540a874788d198#diff-2d8c1ea9df9fd394a04da32fc4d1ea88ea9961ff964f4005fccc1364f7e899e3

[igorpecovnik]

Apparently fixed, coming with next update - or by manual fixing.