Guix System iso too big for cdrom again

  • Done
  • quality assurance status badge
Details
4 participants
  • Maxime Devos
  • Tobias Geerinckx-Rice
  • pelzflorian (Florian Pelz)
  • Csepp
Owner
unassigned
Submitted by
pelzflorian (Florian Pelz)
Severity
normal
P
P
pelzflorian (Florian Pelz) wrote on 24 Oct 2022 18:08
(address . bug-guix@gnu.org)(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
87tu3tjjbc.fsf@pelzflorian.de
Hello Guix,

thanks to commit

commit 26c1bd9dfafb5a954d2174b7a000304cd7ae6345
Author: Tobias Geerinckx-Rice <me@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
Attachment: install-image-du-commit-e427593
Attachment: install-image-du-commit-3734857f
Attachment: install-image-du-comparison
C
C
Csepp wrote on 24 Oct 2022 19:51
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)
87y1t5154g.fsf@riseup.net
"pelzflorian (Florian Pelz)" <pelzflorian@pelzflorian.de> writes:

Toggle quote (34 lines)
> Hello Guix,
>
> thanks to commit
>
> commit 26c1bd9dfafb5a954d2174b7a000304cd7ae6345
> Author: Tobias Geerinckx-Rice <me@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?
M
M
Maxime Devos wrote on 24 Oct 2022 20:14
(name . Tobias Geerinckx-Rice)(address . me@tobias.gr)
39bcf518-580e-9f62-a175-a799d5c10b54@telenet.be
On 24-10-2022 18:08, pelzflorian (Florian Pelz) wrote:
Toggle quote (8 lines)
> 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.
Attachment: OpenPGP_0x49E3EE22191725EE.asc
Attachment: OpenPGP_signature
T
T
Tobias Geerinckx-Rice wrote on 24 Oct 2022 20:17
Re: Guix System iso too big for cdrom again
(name . pelzflorian (Florian Pelz))(address . pelzflorian@pelzflorian.de)(address . bug-guix@gnu.org)
87r0yxkrf7.fsf@nckx
Heyo,

pelzflorian (Florian Pelz) ???
Toggle quote (5 lines)
> 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
-----BEGIN PGP SIGNATURE-----

iIMEARYKACsWIQT12iAyS4c9C3o4dnINsP+IT1VteQUCY1bZLA0cbWVAdG9iaWFz
LmdyAAoJEA2w/4hPVW15ZHQBAI+nccnuJ4hFRG4Gmpaj/3GJ1dBptGVivk6BRGn7
JwOnAP9yk02pJJ7GcX1XeWlEhDkmvOVolYsuUCh7qz1ZLyNNCg==
=zFNo
-----END PGP SIGNATURE-----

P
P
pelzflorian (Florian Pelz) wrote on 2 Nov 2022 16:27
Re: bug#58760: Guix System iso too big for cdrom again
(address . 58760@debbugs.gnu.org)(address . control@debbugs.gnu.org)
8735b1xtpz.fsf@pelzflorian.de
close 58760
thanks

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

Tobias writes:
Toggle quote (4 lines)
> 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:
Toggle quote (2 lines)
> 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:
Toggle quote (2 lines)
> 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
?
Your comment

This issue is archived.

To comment on this conversation send an email to 58760@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 58760
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch