I think the artifacts expire after a time, so I’d say unless @mntmn has any reservations, that’s the newest image.
Thank you so much for updating the system image and making maintenance easier in the long-term!
I’d be happy to test the changes in daily usage. Just wondering, is there an easy way to upgrade for anyone having installed the system on nvme already? i.e. is there any way around having to turn the switch on the SoM and booting from the SD first?
Are the updates also available in the debian repository? I would just need to switch to the new kernel but that’s fine.
I installed the V3 system image. It still has some packages that
apt cannot upgrade. After installing
xfce4, I no longer get the login prompt. I can bring up the login by pressing MNT+F1 and after logging in, everything works fine. I installed
xfce4 on the V2 system image and did not have this issue.
These were the steps I took to install the new system image. I am running without SD card, using NVMe for the system and eMMC for the boot loader and kernel.
Wrote the new system image to SD card
sudo su dd if=reform-system.img of=/dev/mmcblk1
Wrote the rescue system image to the eMMC
echo 0 > /sys/class/block/mmcblk0boot0/force_ro dd if=reform-rescue-system.img of=/dev/mmcblk0
Rebooted to rescue system and reformatted NVMe
# Format only if your data is backed up or on a separate partition mkfs.ext4 -v -L SSD /dev/nvme0n1p1
Mounted NVMe and SD card
mount /dev/nvme0n1p1 /mnt/ mkdir /sdcard mount /dev/mmcblk1p1 /sdcard/
Copied SD card to NVMe
# Trailing slash on source /sdcard/ is required rsync -axHAWXS --numeric-ids --info=progress2 /sdcard/ /mnt/
Set NVMe as boot device and rebooted
echo nvme > /reform-boot-medium
I noticed that job #583 has no warnings, unlike the ones at the bottom of the build logs for #639 and #642. To the casual observer, it’s unclear how severe they are or if it would adversely affect the integrity of the build. It may be good practice to either mark successful/releasable builds such as #583 for permanent retention/archival before they expire or to deploy them as formal releases.
After a couple of days, I figured out how to get the latest v3 commit compiling and working with my eMMC+encrypted NVMe setup. In short:
- Replaced all “mmcblk1” with “mmcblk0” in mkuserland.sh, and added “init=/usr/sbin/reform-init rdinit=/usr/bin/reform-init” to the kernel args.
- Compiled the latest uboot from Reform / reform-boundary-uboot · GitLab and then changed mkimage.sh to copy flash.bin from the build directory instead of downloading it from GitLab.
- Flashed the resulting images, then booted into the rescue image on the eMMC and changed /usr/sbin/reform-init to use
/sbin/cryptsetup isLuks --disable-locks "$BOOTPART"instead of grepping the output of blkid. Added the
--disable-locksflag to the
luksOpencall as well.
- Edited /etc/fstab on the NVMe to remove the “/boot” mount (upgrading rendered my machine unbootable again earlier, I suspect because kernel command line args there got overwritten somehow) and to mount /dev/mapper/cryptroot at / instead of /dev/mmcblk1p2.
Edit: Looks like regulatory.db isn’t getting loaded because cfg80211 is built-in, and so tries looking for the file before the root filesystem is loaded. Noticeably slower wifi, probably because my regulatory domain is now set to “world.” Can’t seem to change it, probably because regulatory.db isn’t loading.
[ 6.481327] platform regulatory.0: Direct firmware load for regulatory.db failed with error -2 [ 6.481337] cfg80211: failed to load regulatory.db
I managed to break my rescue system on this step. If I boot with the SD card (using the new image v3) it works as expected, but if I try to boot without the SD card the display stays blank and doesn’t boot. Any ideas how to fix/debug?
I found a copy of the v2 image and decided to use that for the rescue system and that worked as expected.
Looking at the image partitions and contents, I see quite a difference, and I’m wondering if this is the way it’s supposed to be. Mainly, I don’t see the “Image” file which is supposed to be read by eMMC (if I understand correctly how it works)
V2 image partitions
V2 image contents
V3 image partitions
V3 Image contents
I used this build, which was the latest passing job when I posted the instructions. build (#583) · Jobs · Reform / reform-system-image · GitLab
Perhaps something is broken now? I have not tried the latest jobs. There have been some changes made since then such as moving the kernel build to
reform-debian-packages repo instead of
reform-system-image and changing to the debian fork of the kernel. There were a bunch of changes made to the build scripts to support this and maybe there’s a bug.
Weirdly enough, none of the most recent images have worked for me at all no matter how I flash them to an SD card. I’ve tried to build from source and it won’t complete…I also think there might be a bug.
What is the latest working image that is currently accessible?
My usual setup is booting from SD-Card and then use the encrypted rootfs on NVMe.
I downloaded the latest “OK” build artifact from Pipelines · Reform / reform-system-image · GitLab (called #530).
But when booting this image from the SD-Card I can not see any information on the built-in display but this uboot failure on the HDMI output:
Any idea what went wrong?
I also had the exact same problem with the latest builds. See attached. Seems like a pattern is emerging!!
Hm, this “Loading Environment from MMC… OK” looks suspicious. Maybe the author (Johannes) has a different setup of Uboot and the eMMC/SD-Card content. I did not use the onboard eMMC for booting so far.
And this (loaded) environment probably does not fit to the classic SD-Card/NVMe boot process?!?
With @mntmn and Josch’s help, we’ve come up with a temporary solution, at least until the fix is mainlined.
Grab this u-boot flash.bin file: Artifacts · build (#707) · Jobs · Reform / reform-boundary-uboot · GitLab
Write it to your SD card of the latest system image like so:
dd if=./flash.bin of=/dev/your-sd-card-device conv=notrunc bs=1k seek=33
Oh, great … it is booting again!
Will try to make a new install of the NVMe from this new image now.
I’ve now also created myself an account on this board. If you have problems with the sysimage-v3, feel free to ping me here, write me an email directly at josch [at] debian [dot] org or file an issue here: Issues · Reform / reform-system-image · GitLab
Hi Josch! Nice that you joined the board!
I directly ran into a new issue when working with this “dd-patched” SD-Card image with the alternative uboot:
apt update and
apt upgrade the upgrade process first tried to upgrade
linux-image-5.17.0-rc5-arm64 which lead to full(!)
/boot partition filesystem when running
So I removed some backup files from
/boot (from a second console) while
update-initramfs was running. But in the end the disfunctional uboot-image was re-installed and so I started over again.
apt-mark hold flash-kernel linux-image-5.17.0-rc4-arm64 linux-image-arm64 u-boot-tools the upgrade process succeeded. But I think the size of the
/boot partition definitely has to be increased …
yes, I already experienced the same problem as you did. The underlying problem is, that flash-kernel keeps copies of uImage and initrd in /boot that are bit-by-bit identical but obviously take up again that much space. I have this fixed locally by just increasing the size of /boot but am waiting for the gitlab CI to be fixed again. Currently the CI at source.mnt.re still fails with “No space left on device.”, see build (#713) · Jobs · Reform / reform-debian-packages · GitLab
Thanks that you are working on this topic! So I will just wait some more time until starting to go for the next steps (installing the encrypted rootfs on the NVMe and hopefully get the eMMC running as boot device).