It has been a very busy week. System updates -------------- We finally got the first posting of Demi's work on system updates using systemd-sysupdate[1]! There are still quite a few issues to work through, but it's going ins a promising direction. The most significant of those issues is the following: our current installer, eos-installer[2], works by copying a whole disk image to the target disk. Our combined image allows either booting that image directly, or booting into a system that runs eos-installer with that image. For an updatable system, the partitions that we install need to have room for the system to grow in future, and we also need to have two copies of those partitions for A/B updates. Changing these things causes the image to become unreasonably large. eos-installer supports compressed disk images, but if we did that, we'd lose the ability to directly boot the image to try it out. Demi also points out that eos-installer's approach is incompatible with systems that have e.g. firmware partitions that need to be preserved for the system to boot. Really, then, we're going to need an installer that can work at the partition level rather than the disk image level, so minimally sized partition images can be copied into future-proof bigger partitions in the installed system, B partitions can be created empty without needing a template, and existing partitions on the system can be left alone. This will also mean we get natural dual boot support. I was disappointed to learn that an off the shelf installer that works in this way, analogous to eos-installer, doesn't seem to exist, though. I asked what GNOME OS does, because I knew they previously used eos-installer and must have encountered this problem, and what we were able to figure out on Matrix is that they're in the process of writing a new installer for themselves. I plan to reach out to them to find out about their plans and see if this is something that could also be shared between image-based distros. In the meantime, though, we'll probably just get rid of the combined image, and have one non-updatable live image for testing Spectrum, and an installer image that installs a compressed disk image using eos-installer. [1]: https://spectrum-os.org/lists/archives/spectrum-devel/20251029-updates-v1-0-... [2]: https://github.com/endlessm/eos-installer "Try Spectrum" test ------------------- The updates submission, which took the approach of compressing the images and breaking the "Try Spectrum" function of the combined live/installer image, made me realise that there was no test coverage for that, so I wrote an integration test for it[3]. This was shortly before we realised dropping the combined image for the time being is probably inevitable, but even so it led to lots of nice improvements to the integration test infrastructure that will still be useful going forward. [3]: https://spectrum-os.org/git/spectrum/commit/?id=e0f5aad7901d150b1abe381ffd99... udev ---- I changed the script that assigns network devices to VMs to be idempotent[4], which was the last thing that needed to happen before Demi's patches to switch the host system to use udev[5] can be applied, so that should happen very soon. [4]: https://spectrum-os.org/git/spectrum/commit/?id=1d666582892fbdf812662b4490ca... [5]: https://spectrum-os.org/lists/archives/spectrum-devel/20251103-udev-v5-0-5c4... nixpkgs updates --------------- I finished bisecting the kernel regression we encountered when trying to update Nixpkgs last week. A fix is on the way[6], and I was also able to identify a workaround that could let us keep up to date in the meantime[7]. With this, the update passed all tests and I committed it. A few days later though, it was reported to me that the installer no longer started. I'm bisecting this now, and once we've figured out how to fix it, I'll be able to use all those nice integration test framework improvements to write a regression test for this, too. I used to do more manual testing of Nixpkgs updates, but really to be able to deliver updates at the pace we want, we're going to have to rely a lot less on manual testing and a lot more on automated tests, so going forward I'm going to be trying to get Nixpkgs updated more frequently, with less manual testing, and a focus on adding automated regression tests when something goes wrong. This will likely mean more of this sort of issue in the short term while we build up our test coverage, but a more robust approach to updates in the long term when we've built up our test suite. Yureka has also been continuing to work on identifying Spectrum-related build regressions in Nixpkgs quickly, which will also be important to enable a more rapid pace of updates. [6]: https://lore.kernel.org/netdev/20251030144438.7582-1-minhquangbui99@gmail.co... [7]: https://spectrum-os.org/git/spectrum/commit/?id=9a03e3ea12a40e03735132ed2ed9... What a pace, right!?