There are several hurdles with using minimal-live for PXE boot, primarily that it still requires media access to the ISO.

The "best" I've been able to do is to add rdinit=/bin/sh to the APPEND line in pxelinux.cfg/default so as to enter a console shell instead of running the "normal" initrd:/init (though after having loaded and mounted the initrd filesystem). There you can discover that even the network interface driver modules are missing from the initrd, so there is not much to do with it.

I had better luck using desktop-live as a basis, and then also serve it over nfs.

• on the server, I mounted the ISO at /netboot/boot/desktop-live

• and set up the NFS service to export that path

• then changed pxelinux.cfg/default to use the menu lines:
  KERNEL ::boot/desktop-live/live/vmlinuz
  APPEND vga=788 initrd=::boot/desktop-live/live/initrd.img boot=live root=/dev/nfs nfsroot=/netboot/boot/desktop-live init=/bin/bash

Due to the init=/bin/bash parameter, it will enter a shell instead of running the post-pivot /sbin/init, so it's still not perfect. But the root filesystem could be extracted at the server end (rather than mounted) and then be changed appropriately so as to allow a normal /sbin/init start.

Note that the root filesystem comes from the squashfs on the ISO, so any changes need unpacking and repacking of that (with any changes); all other files of the ISO copy should be left as is.

***
*** Yes, the 5 posts got lost due to a technical mishap; the sysadmin will be replaced as soon as possible.
*** Apologies.
***

You might need to run /sbin/fsck -y /dev/sda2 or /sbin/fsck.ext4 -y /dev/sda2 to mount it rw.

Yes, that one you can start into "rescue"; just make sure you stop before partitioning.

A Debian live should also work if you can operate that without the broken keys; if you get a root prompt in a terminal, you might be able to do

# mkdir /A
# mou<TAB> /dev/sda1 /A
# chroot /A $(which passwd)

and then reboot into that system.
If the mou<TAB> is ambiguous a double <TAB> will yield the options for you to copy and paste from.
Note that maybe your root file system is not on /dev/sda1 of course .. you'll find out.

To undo the resulting badness of double newlines in those files you may use:

sudo sed '/^$/d' -i /var/lib/dpkg/info/*.list

That will still leave the previously missing final newline in /var/lib/dpkg/info/console-setup.list

In addition, given the original issue, I would also

sudo apt-get install --reinstall console-setup

unless I knew that I had been hand-editing those files sometime earlier (and could thus imagine that I had removed a final newline from at least one of them). in fact, that re-installation would have been  my first point of call well before venturing into willy-nilly hand editing in the dpkg database.

That looks fine and leads to the question whether the dbus daemon(s?), which is supposed to be the server end of that socket, is running at the time during bootup when something is expecting it.

https://www.seagate.com/au/en/support/k … -220091en/

.. my longer story is something like the following.

Networking in chimaera is really the same as in all prior system versions; it's a kernel function to operate the interfaces that dynamically rely on their configurations, and there are some forms of user software available for the administration of those configurations.

The first and oldest unit of such software is nowadays called ifupdown in Devuan (Debian).

ifupdown implements an administration principle where the administrator documents their desired configurations using a special purpose scripting language written into one or more plain text files starting with /etc/network/interfaces. The software is modular with a core bit that offers the adminstration programs ifup, ifdown and ifstate as well as the hook-in to the boot process and the hotplug event handling. ifupdown also provides a well-documented API for extensions that allows for other software packages to be seamlessly incorporated into the networking operations as if belonging to ifupdown; e.g., handling DHCP, handling wireless connectivity, VPN setup and whatnot.

On the side of that we find a couple of network management software packages (package groups), where chimaera in particular includes the two named connman and network-manager. These implement their own ideas of the network configuration task, with a common aim to make networking configuration be administrated "more easily" than by using the special purpose scripting language and programs of ifupdown, and most importantly to provide a "security bypass" that empowers non-root users with network administration abilities.

A side effect of that is that the network management software "wants to rule the city". Then "traditional" administration via ifupdown might be in conflict with it, unless one knows enough about the management software to avoid such conflicts. The easiest way for a root administrator to avoid such conflicts  is to get rid of all and any such management software.

I think your apt knows best.

The -exec option variant for find that ends with ';' rather than + lets you use {} more freely, and then perhaps the following would work

find . -type f -name '[0-9][0-9] - *' \
    -exec sh -c "file-rename -v 's/^[0-9][0-9]\s-\s//' '{}'" ';'

or almost certainly (and with less python):

find . -type f -name '[0-9][0-9] - *' \
    -exec sh -c 'X="{}"; mv "{}" "${X#*- }"' ';'

EDIT: added the missing *

Works with $3 rather than $2.

Another way could be:

echo '. /etc/os-release ; echo $PRETTY_NAME' | sh

For Devuan packages, use https://pkginfo.devuan.org/cgi-bin/poli … =ferm.conf