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

[Alyssa Ross <hi@alyssa.is>]

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

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.

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