This Week in Spectrum, 2025-W44

[Alyssa Ross <hi@alyssa.is>]

[-- Attachment #1: Type: text/plain, Size: 5010 bytes --]

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-401c1be2a11b@gmail.com
[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=e0f5aad7901d150b1abe381ffd99d554e65e758b


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=1d666582892fbdf812662b4490caf7821078eaf9
[5]: https://spectrum-os.org/lists/archives/spectrum-devel/20251103-udev-v5-0-5c432ef1ddf8@gmail.com


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.com/
[7]: https://spectrum-os.org/git/spectrum/commit/?id=9a03e3ea12a40e03735132ed2ed97777fdfbd1ed


What a pace, right!?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]