Problem upgrading kernel

MNT Reform
1

I’m using a V3 system image, and ran apt upgrade this morning. I got a couple of errors, and now the system doesn’t seem to boot (no output on screen). The hardware works, I can boot plan9 off a different sdcard.

Here are some of the error messages I saw:

Processing triggers for initramfs-tools (0.142) ...
update-initramfs: Generating /boot/initrd.img-6.4.0-3-reform2-arm64
E: unsupported machine: MNT Reform 2 HDMI        
E: /usr/share/initramfs-tools/hooks/reform failed with return 1.
update-initramfs: failed for /boot/initrd.img-6.4.0-3-reform2-arm64 with 1.
dpkg: error processing package initramfs-tools (--configure):
 installed initramfs-tools package post-installation script subprocess returned error exit status 1

dpkg: dependency problems prevent configuration of linux-image-arm64:    
 linux-image-arm64 depends on linux-image-6.5.0-1-reform2-arm64 (= 6.5.3-1+reform20230920T210951Z1); however:                                     
  Package linux-image-6.5.0-1-reform2-arm64 is not configured yet.       
                                                                                                                                                  
dpkg: error processing package linux-image-arm64 (--configure):          
 dependency problems - leaving unconfigured

I want to burn a clean image to a new card and see if I can rescue the old one.

Which image should I use?

2

The most current. I think we are on v4 now.

I don’t think your system is completely hosed though. It seems like something is missing in terms of a dependency. If you can boot to a cli, you could probably fix it. Someone like minute or josch would be able to speak to this though.

3

I burnt a new sdcard with the V3 imx8mq image from https://source.mnt.re/reform/reform-system-image/-/jobs/artifacts/main/browse?job=build

After some fiddling with the sdcard, copying the kernels and dtbs into the nvme, I was able to boot my old system.

I’m typing on it now.

Looks like the problem is the machine MNT Reform 2 HDMI is not recognized anymore. If you run reform-display-config dual, it fails to build the initrd:

$ sudo reform-display-config dual
update-initramfs: Generating /boot/initrd.img-6.5.0-0-reform2-arm64
E: unsupported machine: MNT Reform 2 HDMI
E: /usr/share/initramfs-tools/hooks/reform failed with return 1.
update-initramfs: failed for /boot/initrd.img-6.5.0-0-reform2-arm64 with 1.

Switching it to single works.

1 Like
4

I’m so sorry, this is my fault. I introduced this problem in a recent change in reform-tools.

The problem will be fixed with reform-tools 1.28 should should appear in the mirror in ~2 hours.

Sorry again and thank you for reporting the problem!

1 Like
5

I also had some problems with system start after upgrading reform-tools. Currently flash-kernel ignores settings from ‘/etc/default/flash-kernel’.

Looking at both flash-kernel and reform-tools, it looks like they moved configuration files from /etc to /usr/share/flash-kernel, including 00reform2_ubootenv (from /etc/flash-kernel/ubootenv.d to /usr/share/flash-kernel/ubootenv.d/) and flash-kernel (from /etc/default to /usr/share/flash-kernel/default/). I can see two problems with this change:

  1. It ignores any potential changes done in files in /etc. It was problem for me: I added parameter setting initial btrfs subvolume, which was ignored when generating boot.scr.
  2. As files are now in /usr (so not configuration files), any changes in them are overwritten during package upgrade. When files were in /etc, dpkg was asking about replacement - now no more.

I’m not sure if this change was the result of recent discussion on debian-devel related to moving everything to /usr, or not.

Currently, to avoid nasty surprises, I pinned reform-tools at version 1.29.

Technical description of how boot.scr file is generated follows.

Description of machines are held in /usr/share/flash-kernel/db/all.db. It’s text file with descriptions of machines, which is parsed by function get_machine_field in file /usr/share/flash-kernel/functions.

File boot.scr is generated by function mkimage_script, called in line 1023. Function begins in line 467. It requires template, prepared in lines 1019-1022 from file /etc/flash-kernel/bootscript/bootscr.uboot-generic. Function mkimage_script injects files found in /etc/flash-kernel/ubootenv.d and in /usr/share/flash-kernel/ubootenv.d into template (using function gen_ubootenv - variable @@UBOOT_ENV_EXTRA@@); the same for files in /etc/flash-kernel/preboot.d and /usr/share/flash-kernel/preboot.d - function gen_preboot and variable @@UBOOT_PREBOOT_EXTRA@@.

The rest is adding kernel version, command line arguments, and few other
values. What is interesting: kernel command line arguments are read from
/etc/default/flash-kernel! But following code, taken from /usr/share/flash-kernel/ubootenv.d/00reform2_ubootenv, overwrites those values.

After preparing full file function mkimage_script calls program mkimage:

mkimage -A arm64 -O linux -T script -C none -a "" -e "" -n "boot script" -d /tmp/boot.in /boot/boot.scr

Warning! boot.scr contains checksum, so editing it directly will make boot to fail. mkimage creates correct structure.

Using those steps I was able to bring system back to booting.

6

Thank you for giving another case for not ignoring ${bootargs} as set by u-boot and for not ignoring what has been set in /etc/default/flash-kernel. I’ve made similar arguments a few hours ago in the Reform IRC channel:

https://mntre.com/reform-irc-logs/2023-10-02.log.html#t16:55:52

Your analysis is correct and I agree it should be changed. Would you be willing to test my changes here:

In my arguments I made on IRC I didn’t have anything as strong as your situation right now. If btrfs subvolumes indeed cannot work without kernel args, then ignoring ${bootargs} breaks your setup for no good reason. In my opinion, users should be able to use /etc to overwrite the defaults in /usr.

No, this had nothing to do with the usr-merge stuff.

1 Like