Hello Community! With all the issues with apt upgrade recently, it was decided a new system image was in order. This moves Reform to Linux kernel 5.17rc1, which has better support for the platform baked in, and removes the need for patching. Please try this out and let us know here if you catch any bugs!
Some release notes:
NMTUI runs instead of Conman or gnome-control-center for network settings in sway.
GPU glitches/freezes can occasionally happen (due to a mesa/new kernel issue).
When first starting sway or another desktop as a new user, some font caching is done, which can take ~7 seconds.
There is now hardware h264 video decoding available with the mpv player when using sway (it doesn’t work yet in GNOME). Switch to fullscreen by pressing f for full performance.
There are now more display backlight brightness levels, esp. in the lower range, which is good for working at night.
Suspend-to-RAM is now integrated with systemd, so it works with systemctl suspend or by choosing suspend from the power menu in GNOME, and to wake up you can use Circle + Space or select the option in the keyboard’s OLED menu.
Fix for audio playback levels:
The finished image will incorporate boosted speaker levels but right now is not functioning properly. Run systemctl restart reform-hw-setup (as root / sudo) to apply the new default levels in alsamixer.
Have ported new kernel image, suspend and audio fixes to my Arch Linux setup. Works well! Btw does suspend currently only disables WiFi and keyboard backlight or it really suspends Reform as any other device?
Also do I understand correctly that in suspend mode Reform could discharge at extreme voltage values just like before LPC fw update?
Suspend does put CPU at S3 state, however it does not put all the periphery, neither it puts RAM at LP state. So it does consume less in suspend but not drastically (about twice less power). LPC still monitors the batteries and executes SoM_off when undervolted however it seems this off is not a full off so batteries are being drained faster in suspend->off state comparing to explicit off.
Were you using the eMMC to point to the NVMe? I found I had to turn the switch on the SoM off before I could get the SD to boot. I’m unsure if uboot can differentiate between internal eMMC or the SD card so it may fall back to the eMMC first if available.
You’re right, thanks. SoM switch helped.
New image looks good — more brightness levels makes the life much better, and suspend finally works fine. Will we be able to receive this updates via apt upgrade or the only way is to rsync to existing installation?
I’m getting a 404 here, and the build page says that the artifacts were removed 4 days ago. Is that intended? Can/should I use the artifacts from the newer job 583 instead?
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?
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.
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-locks flag to the luksOpen call 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)
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.
