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 want to count that as a live disc. I'm dating myself, aren't I? [1] https://www.finnix.org/Finnix_120_release_notes [2] Finnix was previously a Debian derivative, but used a completely bespoke kernel/initrd/early boot system. I wrote a bit more about this at https://blog.finnix.org/2020/05/19/behind-the-scenes-of-finnix-120/ . [3] https://github.com/finnix/finnix-live-build/blob/master/lists/finnix.list.chroot [4] https://github.com/finnix/finnix-live-build [5] https://github.com/finnix/finnix-live-build/tree/master/hooks [6] https://bugs.debian.org/961838
Attachment:
signature.asc
Description: OpenPGP digital signature