@bnys there were no major improvements in recent months, just integrating of the workaround and adjustments that were already known. But as far as I know, no major breakthrough was achieved in the past months and suspend is still not 100% reliable.
@bnys@josch thank you for the information folks. After banging my head against the wall for some time I realised that I had disabled reform-sleep service at some point so that explains the bizarre behaviour.
After enabling it I still have issues with wifi. Namely, my wifi card doesn’t show up in lspci output and the wifi interface is absent from ifconfig.
This time there were no issues with the deriver, in fact dmesg says this:
I Had a bit of a carry-on with my new reform; I ran an apt-update after setup (habit) and it failed, and then it wouldn’t boot. Of course I didn’t have a backed up System Image, and I found this thread, but I don’t have a working V3 SD image; I am using V2 as I write this.
V3 just doesn’t boot; I read the suggestion from up-thread to DD an updated U-boot to the SD image, but this link is now dead too. I would like to try that, does somebody have a working link to the U-boot copy?
You were better prepared then me. I should have made a copy of the SD card. I’ve been running trouble free for 2 days now. I’d like to try the latest image, but I also don’t mind waiting for the official release.
I chatted briefly in IRC to @josch who helped regarding my difficulty with V3, and how I’d tried to buiid it with mkimage.sh without success (I was using the incorrect branch) and actually this knowledge worked for me. I ran the script with the correct branch and I got a working image. I’m now typing this on V3, so thanks for the help.
You cannot go from one CI build number to another via “apt upgrade”. The reform-system-image CI artifacts are snapshots of what is published on Index of /reform-debian-repo/ and since the CI pipeline is only run weekly, there may be package uploads that never make it into a CI build of reform-system-image.
If a kernel upgrade broke your system, you could probably revive it by booting your reform from a SD-card, connecting to the internet and then running:
mount /dev/mmcblk0p2 /mnt # assuming your system is on eMMC
mount /dev/mmcblk0p1 /mnt/boot # assuming you boot from eMMC
mount -o bind /dev /mnt/dev
mount -t proc proc /mnt/proc
mount -t sysfs sysfs /mnt/sys
cat /etc/resolv.conf > /mnt/etc/resolv.conf
chroot /mnt apt update
chroot /mnt apt upgrade
umount /mnt/sys /mnt/proc /mnt/dev /mnt/boot /mnt
Ah, I now see what you guys mean. Yes, the latest image as published by the reform-system-image CI pipeline does something that it should not: it boots from eMMC instead of the SD-Card and if you don’t have a sysimage-v3 on your eMMC, then your system doesn’t boot. This is why I didn’t see any problems a few messages earlier because my system booted just fine but I didn’t notice that what booted was my eMMC system and not the system I flashed on the SD-Card.
Since an image that I build locally boots from SD-Card just fine, maybe @minute can quickly re-trigger the reform-system-image pipeline for the sysimage-v3 branch? If that build works then all good and if not, then there is a more fundamental problem in how images are created on the CI pipeline.
EDIT: I now know why the image produced by the latest pipeline run doesn’t boot: it’s missing a boot.scr on the first partition. I don’t yet know why this is, especially because an image created locally contains a boot.scr just fine. But this explains why the current image boots from eMMC: u-boot on the latest CI image will first try reading boot.scr from SD-Card and cannot find it. It tries eMMC next and will boot that if the first partition on eMMC contains boot.scr. If your eMMC doesn’t contain a sysimage-v3 then it will just not boot.
Maybe just re-running the pipeline will fix the problem. There was a recent upload of flash-kernel (which is responsible for creating boot.scr) to Debian which integrated MNT Reform support. And maybe the image built at a time when the Debian mirror used by the CI didn’t have a flash-kernel version that was new enough yet.
The new problem is, that a new version of dcmtk was uploaded to Debian which causes unrelated breakage. This has to be fixed first but could take a bit longer because we also have to fix all its reverse dependencies. If you want you can keep track of the progress in the bug I filed here: https://bugs.debian.org/1010536
