Till stretch release, live build did had a standard rescue package. It's not there anymore.
--sent from OnePlus device-- Check out newly released IIoT Gateway https://sourceforge.net/projects/iiot-gateway/files/20_may_2020/ On Fri, 12 Jun, 2020, 9:01 AM Ryan Finnie, <r...@finnie.org> wrote: > 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 > >
