Squashfs output support and stripping of files added content

[tlaurion]

Is your feature request related to a problem? Please describe.

As of today, only initrd output is supported.
One of the interesting feature of u-root is to pack additional files and directories and their dependencies (ld)

Describe the solution you'd like
One additional feature of u-root could be to pack u-root content as sqashfs content. Ideally, also by stripping binaries and libraries of their symbols of files added prior or creating the compressed squashfs file.

That way, a linuxboot enabled system could actually load additionally detached signed (or not) squasfsh file and apply it on top of initramfs prior of launching/continuing init.

Describe alternatives you've considered
Tinycore from exp/tcz, but as of now not really actually working since post-install steps are not applied and their tcz are not reproducible.

Additional context
u-root as of today is nondeterministic. edit: irrelevant to this issue.
Even if using one commit of u-root, dependencies could change.

While this hasworked on (pinning of dependencies) nix as an host to build u-root, nix pinned package source could be used to pack host's stripped binaries and libraries to create needed Recovery shell squashfs archive applied from download/cached archive.

[hugelgupf]

u-root as of today is nondeterministic.
Even if using one commit of u-root, dependencies could change.

What do you mean by this? u-root's dependencies are pinned, and our tests test that building the same initramfs twice at the same commit on the same machine comes out bit for bit reproducibly the same. Have we overlooked some cases?

[tlaurion]

@hugelgupf I do not see any pinning for random example https://github.com/u-root/u-root/blob/main/pkg/boot/kexec/kexec_load_linux.go#L12

I get that at a moment in time, if one builds the same initramfs twice it will pass the test. My point, irrelevant to subject of this ticket is if someone wants to rebuild same commit in 6 months it won't produce the same initramfs because dependencies might evolve as well since not pinned to dependencies commit, simply downloading latest available version at moment of building.

[hugelgupf]

@hugelgupf I do see any pinning for random example https://github.com/u-root/u-root/blob/main/pkg/boot/kexec/kexec_load_linux.go#L12

I get that at a moment in time, if one builds the same initramfs twice it will pass the test. My point, irrelevant to subject of this ticket is if someone wants to rebuild same commit in 6 months it won't produce the same initramfs because dependencies might evolve as well since not pinned to dependencies commit, simply downloading latest available version at moment of building.

I see what you mean -- though that's a Go problem with Minimal Version Selection in Go modules. I hadn't realized that Go lost that with the switch from vendoring to modules. (We still have the vendor directory, so theoretically u-root hasn't lost it if you build with modules disabled.)

[tlaurion]

@hugelgupf I added/corrected context of OP for clarity. Reproducibility should probably be tackled in another issue.

You see the added value of packing u-root as compressed squashfs like I do?

[tlaurion]

I see what you mean -- though that's a Go problem with Minimal Version Selection in Go modules. I hadn't realized that Go lost that with the switch from vendoring to modules. (We still have the vendor directory, so theoretically u-root hasn't lost it if you build with modules disabled.)

@hugelgupf how would one would do that?

squashfs

Initramfs are ok, squashfs images are better (overlay fs, can expend and overwrite ramfs/tmpfs content)