Re: [PATCH 2/7] release/combined: Compress installation image

[Alyssa Ross <hi@alyssa.is>]

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

Alyssa Ross <hi@alyssa.is> writes:

> Demi Marie Obenour <demiobenour@gmail.com> writes:
>
>> On 11/1/25 18:15, Demi Marie Obenour wrote:
>>> On 10/29/25 12:51, Alyssa Ross wrote:
>>>> Alyssa Ross <hi@alyssa.is> writes:
>>>>
>>>>> Demi Marie Obenour <demiobenour@gmail.com> writes:
>>>>>
>>>>>> This will be needed once the B partitions are added.  Otherwise,
>>>>>> tar2ext4's size limit is exceeded.
>>>>>>
>>>>>> The timeout is increased to account for the very slow compression
>>>>>> process.
>>>>>>
>>>>>> Signed-off-by: Demi Marie Obenour <demiobenour@gmail.com>
>>>>>> ---
>>>>>>  release/checks/integration/meson.build |  2 +-
>>>>>>  release/combined/eosimages.nix         | 14 +++++++++-----
>>>>>>  2 files changed, 10 insertions(+), 6 deletions(-)
>>>>>
>>>>> I haven't built this yet, so maybe I'm wrong somehow, but doesn't this
>>>>> break "Try Spectrum"?  GRUB isn't going to be able to loopback mount a
>>>>> compressed image, I assume.  That's why I keep asking what GNOME OS
>>>>> does.  We currently produce an image that lets you install Spectrum, or
>>>>> try it out in a live image.  Do they do that too?  If so, how do they
>>>>> make it so that live image is bootable without being huge?  Does their
>>>>> installer resize partitions, perhaps?
>>>>>
>>>>> (I reviewed the rest of the patch anyway, but I think we're going to
>>>>> need a different approach here.)
>>>>
>>>> Okay, I've finally got the answers I wanted about the GNOME OS installer
>>>> on Matrix.  It sounds like it doesn't copy a whole disk image like
>>>> eos-installer does; rather it copies individual partition images using
>>>> systemd-repart.  This means they can distribute small partition images,
>>>> and install them into partitions with room to grow, which would solve
>>>> this problem.
>>>>
>>>> Reusing GNOME OS's installer sounds like it would be good then, but I
>>>> don't know how much work it would be, and don't want to block this work
>>>> on that, so I suggest we go ahead with uncompressed, small partitions
>>>> for now — either sized to content or slightly bigger than content — and
>>>> then later on we switch to GNOME OS's installer, and then increase the
>>>> sizes of the installed partitions.  Only at that point would we consider
>>>> Spectrum installs "stable".
>>> 
>>> I agree in the long term, but I found a short-term workaround: use
>>> erofs instead of ext4.  That compresses the giant runs of zeros down
>>> to almost nothing, and its mkfs tool doesn't have the same file size
>>> limitations.  The only difficulty is that if we should have dm-verity
>>> protection in the installer for ext4, we _really_ ought to have it
>>> for erofs.  That's a separate change, though.
>>
>> Actually, that doesn't work either.  The installer doesn't find the
>> erofs image.  I suspect this is a udisks bug but am not particularly
>> interested in fixing it, especially as this installer is going to
>> be replaced.
>>
>> Using small installation images also doesn't work.  Even with very
>> little room to grow, the image is too big for mkfs.ext4 and tar2ext4
>> to handle.
>
> You mean that adding the B partitions makes the image too big?
>
>> Given this, I think the best option is to drop the live image for now.
>> It can come back after switching to the GNOME OS installer.  Having a
>> live image isn't strictly necessary for users to use Spectrum,
>> whereas an updater is.

FYI: I've just pushed an integration test for the "Try Spectrum" feature
of the combined image, because I'd already written it yesterday before
your message came in.  If we do end up temporarily dropping the live
image, we can just drop that test for now as well.  (But I'd like to
discuss a little further before deciding to do that, in case we can
identify a solution.)

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