Thanks for all the hard work! Just one suggestion, though: sorry if I’m sounding like a broken record, but I’d like to reinforce the importance of deploying a formal release once everything in the build is working and considered stable. This way, the build artifacts are archived so they don’t expire, release notes remain accurate, users don’t need to search through builds, and it allows you to permalink a working environment.
6 Likes
While I agree that there should be a formal release that is known to work, sysimage-v3 isn’t there yet. The two biggest problems are:
- it is based on Debian unstable – this means that any number of release critical bugs will be part of any image that is seemingly “working”. It only makes sense to provide a stable sysimage-v3 once the next Debian stable release happens which is still about a year away. This might seem like a long time but I think it’s an advantage for us because it gives us more time to reduce the patches needed to run Debian on the Reform.
- there is no upgrade path from the old sysimage to sysimage-v3
The sysimage-v3 is still considered experimental (by me) due to these two reasons. If you want a non-experimental “stable” image, then those are still provided here built from the “main” branch:
The software is a volunteer project and it lives and dies with people putting their free-time into it. I think what you want (ignoring that the sysimage-v3 is using Debian unstable and ignoring that there is no upgrade path) will require somebody to regularly build and test an image and then upload it somewhere publicly. I just built an image that worked for me [tm] and put it here:
https://mister-muffin.de/reform/reform-rescue-system.img
But I don’t have the time to do this regularly. Also remember, that sysimag-v3 is considered beta, so it’s aimed at advanced users. Those users are probably also able to build their own image and do not need to rely on the pre-build version. If you have problems building it, direct your bug-reports to me.
1 Like
Thanks for the response! You make a lot of good points, and it’s understandable that a beta image is inherently unstable and more suited to advanced users who may be inclined to build it themselves anyway.
With that said, my perspective of making formal versioned releases is more general and isn’t directed specifically at sysimage-v3 (although it may still be valuable to publish beta releases, represented by release candidates). I feel that there needs to be a standard, consistent URL where users can go to find release builds. Perhaps here. Publishing the release builds on GitLab would also alleviate the need for users to self-host image files and would be much more sustainable over time.
More information on GitLab releases can be found here.
I am happy to help out with system image testing. Perhaps we can collaborate to construct a test plan for reproducibility and I can dedicate some free time to contribute in this way.
It should be noted that the Operator’s Handbook directs the user to download a system image from the MNT Reform site, which hints that there should be a home for releases that is easy to navigate to.
As regards advanced users, I think that’s implied in owning the platform.
Lukas and the wider Reform community has probably and organically arrived (particularly @josch) at the realisation that this has in effect become a distro project in addition to hardware. All this stuff is basically the work of creating and maintaining what is essentially a bespoke Debian spin, and it is work.
I’m sure everyone will help to the best of their ability. We all seem to want the best for the Reform and its community.
1 Like
It is right now but the goal is, that this is temporary. The sysimage-v3 already abolished a lot of reform-specific stuff in favour of how things are done in stock Debian. As we manage to get more of our patches accepted in upstream projects, the diff will reduce further until at some point we don’t need to do our own thing at all anymore. For example here is a MR against u-boot which should allow running Debian installer:
For this to properly work, more pieces are needed of course (for example upstreaming our kernel patches) but it is one more step to the reform being just another laptop that you can install Debian on in the same way that you do on other hardware.
3 Likes
You’d have to ping @minute about that because I don’t have the necessary privileges on the reform-system-image repo to create releases.
Yep, I have “Release System Image V3” in my TODO list for several weeks now, but I’m waiting for the issues to be resolved so we can have a working build again.
@minute triggered another run of the pipeline which should have produced a working image again. Check it out here: reform2-imx8mq · Artifacts · build (#783) · Jobs · Reform / reform-system-image · GitLab
3 Likes
This boots fine for me now thanks so much!
Quick note: it appears that in the latest image, the brightness control keyboard shortcut in sway is broken. Seems like the slider works in gnome.
@bnys This must be an updated package, because mine stopped working after an apt upgrade. I have not done any troubleshooting, but brightnessctl still works so I guess the key assignment got borked somewhere.
Ah I see! I did run apt upgrade after getting the new image migrated to the NVMe drive.
I’m very impressed with gnome now! Slows down occasionally but otherwise animations work, settings app now seems to fully work (including networking), and overall it’s a fairly good experience.
1 Like
Okay, i don’t know what changed or when, but there is a Udev rule for brightnessctl; simply ensure your user is in the ‘video’ group and it’ll be back to normal on Sway.
2 Likes
@Sully_B Nice! Been wanting those shortcut keys back for ages. Looks like the same goes for audio output as well…
sudo usermod -a -G audio *username*
2 Likes
Awesome! Ran this for video and restarted…right as rain. Able to control brightness in sway yet again. Thanks!
1 Like
Hi, if there are issues with sysimage-v3, could somebody please either notify me here in the forum, or drop me a mail josch@debian.org or file an issue and @-mention me at source.mnt.re? It’s nice if problems get discovered but we should fix them at the source so that others can automatically benefit from the found solution without having to first search in the forum and then manually fix things.
I filed a MR with the fix here: fix ADD_EXTRA_GROUPS regex and set EXTRA_GROUPS to those used by d-i (!48) · Merge requests · Reform / reform-system-image · GitLab
1 Like
Hi @josch I do have an Issue with v3 with screen flickering in Xwayland.
I’m not sure if this is what was mentioned in the first post as “GPU glitches/freezes can occasionally happen (due to a mesa/new kernel issue)” tho.
You can reproduce with these steps:
- Start
reform-windowmanager - Start xterm
- Type some text in then start moving the mouse around over the screen.
- The new text will flicker like there are two video buffers and only one was updated.
This does not happen with v2.
Thanks for reading, let me know if there’s anything I can help with.
When trying to replicate your issue, I actually ran into another issue:
This looks like a mesa bug and I don’t know why the desktop doesn’t start at all and I only get graphics glitches. Once I killed it and tried running reform-windowmanager again I got to replicate your issue but I don’t think it’s a mesa issue because moving the mouse actually enters some text into the terminal. Can you confirm that observation?
Maybe start a new thread about this issue because I’m quite certain that this is not sysimage-v3 specific but if you had updated your kernel and mesa in v2 to their current versions you would run into the exact same issue.
1 Like
I confirm that I have the same issue with v2 and updated Mesa/Xwayland.
2 Likes