Quoth pabs:
> On Fri, Jun 5, 2020 at 7:46 PM Philip Hands wrote:
>
> > Of course, Grml isn't a direct output of the Debian project, so perhaps
> > people might take issue with having that as the "Debian Recovery
> > Option", but it is closely based on Debian, and includes a couple of
> > ways of installing vanilla Debian, having booted into Grml.
>
> Debian used to publish a "recovery" variant of Debian Live, but that
> was dropped due to lack of maintenance at one point. I note there are
> several Debian derivatives producing rescue/recovery live media (Grml,
> rescatux, Finnix come to mind), I wonder if any of them would be
> interested in forming a new Debian rescue/recovery team to publish
> console and GUI recovery variants of Debian Live images.
As the developer of Finnix, I'm open to a few ideas and this will be a
bit of a ramble going off in a few directions. But first, a bit of an
introduction. Finnix is a utility Live CD, in production since 2000[0].
I recently released Finnix 120[1] after a 4+ year gap, but thanks to
the updated work of Debian's live-build by Lyndon Brown making it easier
to maintain a derivative[2], I've committed to regular releases again.
Finnix's goals are feed into one another:
- Text-based live distribution.
- Boot to root shell prompt as quickly as possible.
- As many system utilities as possible.
- Relatively small size.
Grml's goals are similar but we diverge on a couple of philosophies, but
that's perfectly fine. To that end, I think a first-party (to Debian)
utility live distribution would be fine as well.
Let's say Debian wants to do a utility live distribution, using Finnix's
goals as a model. So let's start with a package list, which is simple
to do based on Finnix's list[3], and could easily become e.g. a
live-task-utility metapackage to go along with the rest of the
live-task-* packages. I would be willing to maintain such a
metapackage, to keep it from going stale.
Now, pretty much the only other thing the Finnix build repository[4]
does is execute some hooks; everything else is wrapping live-build.
Those hooks are[5]:
- systemd: Defines finnix.target. Also disables as many services as
possible in the name of speed. For example lm-sensors.service since
lm-sensors is installed; the service does nothing in Finnix, but these
take a bit of time to do nothing and add up.
- bash-profile: Makes a stylized PS1, couple other aliases/tweaks.
- distro: Standard derivative distro info diversions.
- getty: One of the largest changes IMHO. Strips out the non-superuser
getty generator and puts in its own getty overrides to go straight to
root bash prompt.
- gpm: Sets up and enables a gpm service for useful console mouse access.
- live-config: Finnix-specific live-config defaults, and disables
openssh-server key generation (see below).
- remove-packages: Currently removes rsyslog in favor of having no
syslog (just systemd's journal).
- ssh: Overrides ssh.service so key generation is done if the user tries
to start ssh.service, as opposed to at boot time, saving seconds if the
user has no intention of starting an SSH server. Also sets up a
per-user shared SSH agent, to be shared by the multiple VTYs.
- s390-kernel: Heh. Currently a hack to get around s390x kernel + QEMU
currently being broken in sid[6], it manually downloads a vanilla-ish
kernel from Ubuntu.
- recompress: Something hacky that I'm quite proud of: it goes through
all .gz files in the chroot, decompresses them and recompresses them at
level 0 (gzip header + original data). It also needs to mess around
with the dpkg md5sums as a result. Why? mksquashfs xz produces better
compression than stacked gz + mksquashfs xz, so a larger looking
internal chroot results in a smaller overall ISO.
Which of those hook modifications would be needed for a Debian utility
live distribution? Arguably, none, as they all fall under 1) branding,
2) efficiency/speed, or 3) convenience. IMHO they are all useful to
Finnix, but some of the features would be nice to upstream to Debian,
such as the recompression logic, shared console SSH agents, etc. But I
imagine things such as an automatic root prompt would be a source of
contention for an official Debian image, so it would make more sense for
it to boot into the standard live user.
I would be willing to discuss a utility distribution with Debian Live.
One complication is the current live builds don't use live-build, but
instead live-wrapper which AIUI doesn't even use live-build at its core
anymore. I certainly haven't had a chance to look at it, nonetheless.
Currently the sid live-build is the only system I "know", and if I were
to step up to maintaining a Debian utility live distribution (for
anything beyond a dependency metapackage), I would need to learn the
current system.
[0] Making it the oldest Live CD still in production, and one of the
first few full stop, after DemoLinux and LinuxCare's BBC off the top of
my head. Maybe Yggdrasil's installer if you wa
