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).
Unfortunately I cannot (yet) edit my own posts so here is an additional post with the solution to the /boot partition being too small:
Heads-up to anyone hoping to boot the newest system image from NVMe…the reform-migrate script appears to be broken so please keep it on an SD card for now.
To fix this, could you file a new issue on https://source.mnt.re or write me a mail with a detailed report to josch [at] debian [dot] org? I tested the reform-migrate script and I’m running it from NVMe without problems. So I’d like to figure out why it didn’t work for you.
- this fixed u-boot image
- the increased /boot partition size
mkimage.sh script pulls the latest u-boot image from the CI artifacts, so it will include the fixed u-boot.
@mntmn could you also tag the latest u-boot release? Then reform-system-image could use a specific version instead of just the “latest”.
Whether it will also include the fixed
/boot partition size depends on mkimage.sh: make partition sizes configurable and double boot partition size (!44) · Merge requests · Reform / reform-system-image · GitLab getting merged.
The artifact from the latest build works excellent!
Friends, the image worked for me brilliantly until I’d got around to set up suspend.
When I do
systemctl suspend it does suspend, but the keyboard remains lit. When I look at
reform-standby it appears that the keyboard backlight is supposed to turn off.
But more importantly it appears that my wifi driver is misbehaving,
dmesg is spammed by the following messages:
[ 4068.421963] ath: phy1: Chip reset failed [ 4068.425901] ath: phy1: Unable to reset channel, reset status -22 [ 4068.586867] ath: phy1: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff [ 4068.775497] ath: phy1: Chip reset failed [ 4068.779449] ath: phy1: Unable to reset channel, reset status -22 [ 4068.940153] ath: phy1: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff [ 4069.128810] ath: phy1: Chip reset failed [ 4069.132756] ath: phy1: Unable to reset channel, reset status -22 [ 4069.293370] ath: phy1: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff [ 4069.481992] ath: phy1: Chip reset failed [ 4069.485943] ath: phy1: Unable to reset channel, reset status -22 [ 4069.772636] ath: phy1: RX failed to go idle in 10 ms RXSM=0xffffffff [ 4069.805176] ath: phy1: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff [ 4074.011154] ath: phy1: Failed to wakeup in 500us [ 4074.296360] ath: phy1: RX failed to go idle in 10 ms RXSM=0xffffffff [ 4074.328922] ath: phy1: DMA failed to stop in 10 ms AR_CR=0xffffffff AR_DIAG_SW=0xffffffff DMADBG_7=0xffffffff
And of course the wifi is not operational afterwards (although
ifconfig does show the interface).
My network adapter is
0000:01:00.0 Network controller: Qualcomm Atheros AR5418 Wireless Network Adapter [AR5008E 802.11(a)bgn] (PCI-Express) (rev 01)
Has anybody experienced anything like this?
@friendofmegaman I have had systemctl suspend hang on wake but have not taken note of what the readout is so I don’t know if my condition is the same as yours.
Quick note: the latest pre-built version is here:
It will autodelete if you don’t grab it soon.
I know sway has been fantastic lately, but I was initially impressed with Gnome performance as well…until it suffered from some graphical issues where elements were no longer rendering on screen. Things like icons on the dock, items in the right-hand drop-down menu etc. stop appearing after a short while. It’s a pity since it seemed relatively snappy, with nice animations for snapping windows and searching for apps.
@bnys thank you for the response. I’m currently running the build from around a month ago, do you happen to know is the build you linked has any changes related to suspend? Cheers!
Unfortunately, I don’t think there are changes to suspend… @josch were there improvements to this functionality? It seems way more stable than before but still occasionally fails, making it unreliable.