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

Thanks for spotting and reporting the spurious "bewoulf".

I think you would also reenter the boot menu with the command menu.

That "grub_verify_string" issue needs some further exploration. Thanks.

Fortunately I haven't had your problem, but also therefore I haven't had reason to dig into it, and now I stand without distinct knowledge. You may well be right to focus on the screen and display side of things, then the X configuration for the input devices, and then the device adapters themselves... but I'd do the opposite order.

As I understood it, the display shows up fine but the mouse and keyboard play up. That suggests to me that the suspend/resume implementation of the Desktop Environment that you are using doesn't juggle all the device handling modules enough; something that "used to" be handled by pm-utils ("power management utilities").  In other words, that the device adapters modules that interact with the input hardware (not the display) don't get reset properly upon resume.

If you'd know which modules, you'd then go to the suspend/resume implementation used by your desktop environment and make those modules reset/reload upon resume (assuming that implementation of the suspend/resume function provides the required hooks).

There is no harm in installing xrandr and synclient as ways of getting more insight; xrandr is the command used for inspecting and controlling the display setup for X, and synclient is the command for inspecting and configuring the touchpad handling for X (which also partly concerns the mouse). Both of those interact with the X server.

At the module level, I think it concerns the hid (human interface device) modules and the hcd (host controller driver) modules; namely that one or some of those lose their configuration upon suspend+resume. I remember for example that the xhci_hcd module at some time had difficulty with suspend+resume which typically got resolved by reloading.

But not all computers are the same, so it might be a different module for your problem, and of course, maybe the problem sits elsewhere.

.. and then you can remove the "supervisor password" with the machine still having disabled SecureBoot ?

Is there anything spectacular in /var/log/syslog or /var/log/Xorg.0.log ? or perhaps som /var/log/pm-* log file?

Generally the issue is likely to be that some module fails to reset/restart properly on resume. if that is the case and you can isolate which one, adding that module to the SUSPEND_MODULES list (see man pm-suspend) for unloading and re-loading might solve the issue.

"live installer" is a good choice; I'm not sure whether it's strictly better or not but it has the "advantage" of try-before-buy

I don't know about runit. Perhaps the best is start a new thread on that topic as there's for sure people with experience from that around here.

1) firmware-iwlwifi is on the ISO somewhere in its pool/ directory tree.
You might try to find and install that. there is also rfkill which you might need if the wifi is "turned off".
(The firmware should have been installed "automatically" during the installation; not sure why that didn't happen)

2) what's the output of:

# pgrep -a Xorg
# echo $DISPLAY

3) well the failures of installing mate and lxqt would have been during the installation so it's moot now, otherwise the installer has its /var/log/syslog that you can tail the end portion of to see what the error messages are.