Core Update 167 requires additional step for ARM users before rebooting

Hi,

unfortunately, there is still a quirk present in Core Update 167, affecting installations running on ARM: Because the packaged initial ramdisk for u-boot was missing in the update, ARM installations stall on booting after the upgrade, since the kernel version in the ramdisk differs from the actually installed kernel.

Due to capacity constraints and some core developers being unavailable during the QA phase, this bug was unfortunately not fixed while Core Update 167 has still been in testing.

ARM users are therefore strongly advised to run an additional command after having installed Core Update 167, but before rebooting. On 64-bit ARM (aarch64), it is:

cd /boot && mkimage -A arm64 -T ramdisk -C lzma -d initramfs-5.15.35-ipfire.img uInit-5.15.35-ipfire 

32-bit ARM systems require this command instead:

cd /boot && mkimage -A arm -T ramdisk -C lzma -d initramfs-5.15.35-ipfire.img uInit-5.15.35-ipfire 

By this command, a regeneration of the initial ramdisk is forced, including the correct kernel version.

We sincerely apologize for inconveniences caused by this error.

Special thanks go to @arne_f for his efforts on investigating on this front.

Thanks, and best regards,
Peter MĂĽller

4 Likes

[NanoPi R1] Running the below under /boot

mkimage -A arm -T ramdisk -C lzma -d initramfs-5.15.35-ipfire.img uInit-5.15.35-ipfire

Returns:

mkimage: Can’t open initramfs-5.15.35-ipfire.img: No such file or directory

The director contents are

drwxr-xr-x  3 root root  16K Jan  1  1970 .
drwxr-xr-x 21 root root 4.0K Apr 28 08:58 ..
-rwxr-xr-x  1 root root 2.4K Apr 26 14:40 boot.cmd
-rwxr-xr-x  1 root root  52K Nov 18 16:22 bootcode.bin
-rwxr-xr-x  1 root root   67 Apr 26 14:40 boot.mk
-rwxr-xr-x  1 root root 2.5K Apr 26 14:40 boot.scr
-rwxr-xr-x  1 root root 199K Apr 26 13:07 config-5.15.35-ipfire
-rwxr-xr-x  1 root root 1.9K Apr 26 12:59 config.txt
drwxr-xr-x  2 root root  72K Apr 26 13:08 dtb-5.15.35-ipfire
-rwxr-xr-x  1 root root 3.2K Nov 18 16:22 fixup4cd.dat
-rwxr-xr-x  1 root root 5.3K Nov 18 16:22 fixup4.dat
-rwxr-xr-x  1 root root 8.3K Nov 18 16:22 fixup4db.dat
-rwxr-xr-x  1 root root 8.3K Nov 18 16:22 fixup4x.dat
-rwxr-xr-x  1 root root 3.2K Nov 18 16:22 fixup_cd.dat
-rwxr-xr-x  1 root root 7.2K Nov 18 16:22 fixup.dat
-rwxr-xr-x  1 root root  11K Nov 18 16:22 fixup_db.dat
-rwxr-xr-x  1 root root  11K Nov 18 16:22 fixup_x.dat
-rwxr-xr-x  1 root root  40K Apr 26 14:38 MLO
-rwxr-xr-x  1 root root 783K Nov 18 16:22 start4cd.elf
-rwxr-xr-x  1 root root 3.6M Nov 18 16:22 start4db.elf
-rwxr-xr-x  1 root root 2.2M Nov 18 16:22 start4.elf
-rwxr-xr-x  1 root root 2.9M Nov 18 16:22 start4x.elf
-rwxr-xr-x  1 root root 783K Nov 18 16:22 start_cd.elf
-rwxr-xr-x  1 root root 4.6M Nov 18 16:22 start_db.elf
-rwxr-xr-x  1 root root 2.9M Nov 18 16:22 start.elf
-rwxr-xr-x  1 root root 3.6M Nov 18 16:22 start_x.elf
-rwxr-xr-x  1 root root 3.9M Apr 26 13:07 System.map-5.15.35-ipfire
-rwxr-xr-x  1 root root 128K Apr 26 14:40 uboot.env
-rwxr-xr-x  1 root root 504K Apr 26 14:38 u-boot.img
-rwxr-xr-x  1 root root 485K Apr 26 14:39 u-boot-rpi1.bin
-rwxr-xr-x  1 root root 478K Apr 26 14:39 u-boot-rpi2.bin
-rwxr-xr-x  1 root root 491K Apr 26 14:39 u-boot-rpi3.bin
-rwxr-xr-x  1 root root  114 Apr 26 14:59 uEnv.txt
-rwxr-xr-x  1 root root    0 May  3 10:06 uInit-5.15.35-ipfire
-rwxr-xr-x  1 root root 5.6M Apr 26 13:07 vmlinuz-5.15.35-ipfire

Hi Peter, is there a workaround for people that already rebooted after installing Core Update 167?
My “problem” is that I installed on an SSD that I can’t just pop into a USB port of another computer to download the backup file.
Thank you.

If you have already rebootet you need an other linux system to generate the initramdisk.
On many distributions mkimage is also compiled for x86. and packaged as u-boot-tools or u-boot-mkimage.

Is your boot volume full?

Please help me testing a fix for this. (I’m not at home)
Install core166 and after this change to testing tree and this update to core167.

If this works now i can add this fix also to stable tree.

Arne, I got the instructions wrong and executed the workaround against the “booted” ipfire boot partition, hence uInit-5.15.35-ipfire got overwritten… (ignorant!)
I later fixed it by copying the same 14M file from the install img onto the boot

The boot was never full considering I did a fresh install of core 167 after the ipfire installation got affected from the upgrade.

Device	        Mounted on	Size  Used	Free
/dev/mmcblk1p1	/boot	    124M  74M	51M

Okay, I’ve ordered an M-SATA case with USB Support from A* so that I can access the SSD in the unit…

Negative - it is a 60GB SSD

On an RPi4B ( Raspberry Pi 4 Model B Rev 1.1 / Revision : c03111)

Started with IPFire 2.27 (aarch64) - Core Update 166.

Did the updated to CU 167 via WebGUI pakfire. All looks A-OK.

before reboot I ran:

[root@ipfireRPi4B-9 ~]# cd /boot && mkimage -A arm64 -T ramdisk -C lzma -d initramfs-5.15.35-ipfire.img uInit-5.15.35-ipfire 
Image Name:   
Created:      Tue May  3 12:11:54 2022
Image Type:   AArch64 Linux RAMDisk Image (lzma compressed)
Data Size:    15255153 Bytes = 14897.61 KiB = 14.55 MiB
Load Address: 00000000
Entry Point:  00000000

[root@ipfireRPi4B-9 boot]# reboot

The WebGUI came back, after reboot, as expected and I am on IPFire 2.27 (aarch64) - Core Update 167

No testing but things seem OK. Do you want to see any logs?

2 Likes

On an R2S - A new build of CU 166 to 167 did not work.

Started with IPFire 2.27 (aarch64) - Core Update 166. This was a current download from the IPFire archives today.

First boot I got this message:

Here is df after first boot of CU 167 and before CU 167 update:

[root@ipfireR2S ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        471M     0  471M   0% /dev
tmpfs           489M     0  489M   0% /dev/shm
tmpfs           489M  268K  489M   1% /run
/dev/mmcblk0p3  7.2G  1.6G  5.3G  23% /
/dev/mmcblk0p1  112M  103M  9.1M  92% /boot
/dev/mmcblk0p2   32M  152K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock
none            489M   68K  489M   1% /var/log/vnstat
none            489M   25M  464M   6% /var/log/rrd
[root@ipfireR2S ~]# 

I started the update anyway and it seemed to finish OK. But the CU 167 filled up the \boot directory.

[root@ipfireR2S ~]# cd /boot && mkimage -A arm64 -T ramdisk -C lzma -d initramfs-5.15.35-ipfire.img uInit-5.15.35-ipfire 
mkimage: Write only 9781184/15275663 bytes, probably no space left on the device

.
Here is df after the CU 167 update but before reboot.

[root@ipfireR2S boot]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        471M     0  471M   0% /dev
tmpfs           489M     0  489M   0% /dev/shm
tmpfs           489M  272K  489M   1% /run
/dev/mmcblk0p3  7.2G  1.4G  5.5G  21% /
/dev/mmcblk0p1  112M  112M     0 100% /boot
/dev/mmcblk0p2   32M  152K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock
none            489M   68K  489M   1% /var/log/vnstat
none            489M   26M  464M   6% /var/log/rrd
[root@ipfireR2S boot]# 

Anything I can delete from CU 166 \boot directory?


EDIT:

Test #2

I grabbed a new SDCard and tried the R2S build again. This time I got slightly different results for the install of IPFire. The Test #2 there was an error during the boot.

U-Boot SPL 2021.07 (Mar 31 2022 - 11:56:36 +0000)
Trying to boot from MMC1
mmc_load_image_raw_sector: mmc block read error
SPL: failed to boot from all boot devices
### ERROR ### Please RESET the board ###

I powered down and up the R2S and the boot started again and looked OK. But on Test #2 (with the error) there was no size issue.

Here is df after first boot of CU 167 CU 166 for Test #2:

[root@ipfireR2S-2 ~]# df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        471M     0  471M   0% /dev
tmpfs           489M     0  489M   0% /dev/shm
tmpfs           489M  268K  489M   1% /run
/dev/mmcblk0p3  7.2G  1.6G  5.3G  23% /
/dev/mmcblk0p1  112M   87M   25M  78% /boot
/dev/mmcblk0p2   32M  152K   32M   1% /boot/efi
/var/lock       8.0M   12K  8.0M   1% /var/lock
none            489M   68K  489M   1% /var/log/vnstat
none            489M   26M  464M   6% /var/log/rrd
[root@ipfireR2S-2 ~]# 

This doesn’t quite make sense so I thought I would repost what I see:

The update now works correctly on bananapi (arm6hl)
patched_update.zip (837 Bytes)
.

  • kernel 5.15.23 files are deleted
  • uInit-5.15.35-ipfire is present
  • /boot is 60% used
  • reboots successfully
2 Likes

Hi guys, I have just registered here. I had “stable” update channel selected and I have upgraded to 167 yesterday around 11PM CET on a PI4B 4GB revision 1.2

I hve selected simple reboot without the file check. I don’t have a screen attached to it so I can guess only that i have the same issue as anyone else.

I have access to another microsd with Raspbian (i have also have remote configured) on it so I can access the IPFire microsd with a reader, but looking through all the bug reports and other topics, I have no idea what I am supposed to do.

Do I need to run this:

cd /boot && mkimage -A arm64 -T ramdisk -C lzma -d initramfs-5.15.35-ipfire.img uInit-5.15.35-ipfire

but aiming on the boot partition of the ipfire? How do i do that, is there a guide to follow for us non linux guys ?
Sorry

I doubt that there is a simple guide to cover this procedure, which I have not tried, plus I am not a Raspbian user.

You would need some additional commands to identify and mount the ipfire uSD and will need to use full pathnames. Do:

lsblk
mount /dev/mmcblk1p1 /mnt (but lsblk might have idicated that ipfire boot partition is /dev/mmcblk0p1 or /dev/sda1)

cd /mnt

First be certain that all files 5.15.23 in /mnt are deleted, because failure to do that is likely to result in /mnt filling, in which case there won’t be space for uInit-5.15.35-ipfire. Then do:

mkimage -A arm64 -T ramdisk -C lzma -d initramfs-5.15.35-ipfire.img uInit-5.15.35-ipfire

Be certain to poweroff Raspbian cleanly.

As a fall-back, copy /var/ipfire/backup/*.ipf & /var/ipfire/backup/addons to your client PC and do a fresh install of core 167.

3 Likes

Hi Rodney,

Thanks for the post.

I have managed to do it, in my case it was sda1 with a total size of 112M.

The only thing i would add to your guide, that i needed to install mkimage first before running this command: mkimage -A arm64 -T ramdisk -C lzma -d initramfs-5.15.35-ipfire.img uInit-5.15.35-ipfire

I have installed it with the following command: sudo apt-get install u-boot-tools

After running mkimage command i got back something and it has booted up correctly. I also did not have any 5.15.23 version files, only 5.15.35

Hi all,

first, apologies for the late reply.

On May 2nd, Arne pushed the aforementioned fix to the stable tree (see this commit). Therefore, any installation upgraded to Core Update 167 after May 3rd, 2022, should come with the fix and reboot fine without any additional steps being required.

For the records: This issue was tracked as bug #12859. Apologies again for the inconveniences.

Thanks, and best regards,
Peter MĂĽller

2 Likes

Hi @pmueller

Now works correctly. Thanks for yours hard work. :ok_hand:

Bye.

1 Like