GNU bug report logs - #58760
Guix System iso too big for cdrom again

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 58760 in the body.
You can then email your comments to 58760 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: bug-guix <at> gnu.org
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: Guix System iso too big for cdrom again
Date: Mon, 24 Oct 2022 18:08:23 +0200

[Message part 1 (text/plain, inline)]

Hello Guix,

thanks to commit

commit 26c1bd9dfafb5a954d2174b7a000304cd7ae6345
Author: Tobias Geerinckx-Rice <me <at> tobias.gr>
Date:   Mon Apr 6 17:48:21 2020 +0200

    vm: Transparently compress iso9660 images.
    
    * gnu/build/vm.scm (make-iso9660-image): Use the ‘--zisofs’ xorriso
    filter at the highest compression settings for supported directories.

it was possible to burn the Guix System install image to a 700MB CD.
But it fits no more.  I compared using the du tool (comparison between
good old Guix version e427593 and bad new Guix version 3734857f (with
unmerged installer patches) is attached).  The result is that most
packages got slightly bigger and this broke the camel’s back.  From what
Tobias (Cc) wrote, he used the highest compression settings.

So it seems nothing can be done to make the install iso smaller than
700MB and support this antiquated storage medium, but I thought I’d open
a bug and ask, because my laptop doesn’t boot from USB, I have more
CD/Rs than DVD/Rs and I guess they are cheaper than DVD.

Regards,
Florian

[install-image-du-commit-e427593 (text/plain, attachment)]

[install-image-du-commit-3734857f (text/plain, attachment)]

[install-image-du-comparison (text/plain, attachment)]

Message #8 received at 58760 <at> debbugs.gnu.org (full text, mbox):

From: Csepp <raingloom <at> riseup.net>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>, bug-guix <at> gnu.org,
 58760 <at> debbugs.gnu.org
Subject: Re: bug#58760: Guix System iso too big for cdrom again
Date: Mon, 24 Oct 2022 19:51:01 +0200

"pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de> writes:

> Hello Guix,
>
> thanks to commit
>
> commit 26c1bd9dfafb5a954d2174b7a000304cd7ae6345
> Author: Tobias Geerinckx-Rice <me <at> tobias.gr>
> Date:   Mon Apr 6 17:48:21 2020 +0200
>
>     vm: Transparently compress iso9660 images.
>     
>     * gnu/build/vm.scm (make-iso9660-image): Use the ‘--zisofs’ xorriso
>     filter at the highest compression settings for supported directories.
>
> it was possible to burn the Guix System install image to a 700MB CD.
> But it fits no more.  I compared using the du tool (comparison between
> good old Guix version e427593 and bad new Guix version 3734857f (with
> unmerged installer patches) is attached).  The result is that most
> packages got slightly bigger and this broke the camel’s back.  From what
> Tobias (Cc) wrote, he used the highest compression settings.
>
> So it seems nothing can be done to make the install iso smaller than
> 700MB and support this antiquated storage medium, but I thought I’d open
> a bug and ask, because my laptop doesn’t boot from USB, I have more
> CD/Rs than DVD/Rs and I guess they are cheaper than DVD.
>
> Regards,
> Florian
>
> [2. text/plain; install-image-du-commit-e427593]...
>
> [3. text/plain; install-image-du-commit-3734857f]...
>
> [4. text/plain; install-image-du-comparison]...

Are there unnecessary dependencies that could be cut out?

Message #14 received at 58760 <at> debbugs.gnu.org (full text, mbox):

From: Maxime Devos <maximedevos <at> telenet.be>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>,
 58760 <at> debbugs.gnu.org
Cc: Tobias Geerinckx-Rice <me <at> tobias.gr>
Subject: Re: bug#58760: Guix System iso too big for cdrom again
Date: Mon, 24 Oct 2022 20:14:35 +0200

[Message part 1 (text/plain, inline)]

On 24-10-2022 18:08, pelzflorian (Florian Pelz) wrote:
> Hello Guix,
> 
> [...] The result is that most
> packages got slightly bigger and this broke the camel’s back.  From what
> Tobias (Cc) wrote, he used the highest compression settings.
> 
> So it seems nothing can be done to make the install iso smaller than
> 700MB and [...]

IIUC, (C) packages in Guix are often compiled with -O2 (and sometimes 
without optimisation, if upstream doesn't set any flags and Guix forgets 
to set some optimisation flags manually).  I think -Os would be worth 
investigating.

>477K	/gnu/store/2b3blhwbag1ial0dhxw7wh4zjxl0cqpk-pkg-config-0.29.2
>2.4M 
/gnu/store/3k1h2ifn12rs9a06arpvqzrz5k7bwqm1-linux-libre-headers-5.10.35

I don't think a reference should be kept to those. Maybe it can be 
eliminated.

>302K	/gnu/store/6ab3j98gcd02882d1jp9w6kv40fgyspf-wayland-1.20.0

Given that our installer is a TUI, this one looks surprising to me.
Likewise for cairo and opus.

Greetings,
Maxime.

[OpenPGP_0x49E3EE22191725EE.asc (application/pgp-keys, attachment)]

[OpenPGP_signature (application/pgp-signature, attachment)]

Message #17 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Tobias Geerinckx-Rice <me <at> tobias.gr>
To: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
Cc: bug-guix <at> gnu.org
Subject: Re: Guix System iso too big for cdrom again
Date: Mon, 24 Oct 2022 20:17:35 +0200

[Message part 1 (text/plain, inline)]

Heyo,

pelzflorian (Florian Pelz) 写道：
> From what Tobias (Cc) wrote, he used the highest
> compression settings.
>
> So it seems nothing can be done to make the install iso smaller

Well…  I used the highest compression setting *for zisofs*.

Zisofs is an ancient (and non-standard :-) little hack that Linux 
supports, and it just happened to be enabled on our kernels 
already.  Plus it's fully transparent to the operating system. 
That's why I wrote that quick little patch: it was an amusing—to 
me—way to shrink our ISO basically for free.

We're the only distro that I've ever seen use it.

But we can go deeper if we choose to, by dropping zisofs and going 
for something like squashfs, which achieves higher compression 
through higher block sizes and better algorithms like XZ.

This is what other distributions with a compressed root file 
system do.

However, it's marginally more work as you have to loop-mount the 
image early during boot, and it doesn't involve obscure kernel 
arcana (boo), and CDs are even more obsolete than they were when I 
wrote that patch (yay), so don't wait for me to do it.

Kind regards,

T G-R

[signature.asc (application/pgp-signature, inline)]

Message #20 received at 58760 <at> debbugs.gnu.org (full text, mbox):

From: "pelzflorian (Florian Pelz)" <pelzflorian <at> pelzflorian.de>
To: 58760 <at> debbugs.gnu.org
Cc: control <at> debbugs.gnu.org
Subject: Re: bug#58760: Guix System iso too big for cdrom again
Date: Wed, 02 Nov 2022 16:27:04 +0100

close 58760
thanks

Thank you all for your responses.  But I have closed the issue (without
really trying the methods) because

Tobias writes:
> But we can go deeper if we choose to, by dropping zisofs and going for
> something like squashfs, which achieves higher compression through
> higher block sizes and better algorithms like XZ.

Probably yes, though I don’t dare writing that and

Csepp writes:
> Are there unnecessary dependencies that could be cut out?

Kind of, but only by making variant packages without the dependencies
that Maxime listed in his response, just for the installer, but it would
not be enough to get below 700MB.

Maxime writes:
> I think -Os would be worth investigating.

Yes, that would be easiest, though looking at --tune, I guess making
variant base packages with -Os just for the installer is not worth the
complexity since cdroms are a niche use-case.

It would be possible, so maybe I shouldn’t have closed, but maybe I
shouldn’t have filed the issue in the first place.

Regards,
Florian

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.