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.

That will need a slight revision to your ifupdown setup.

Firstly you may want to install hostapd and bridge-utils.

hostapd provides the software needed for running an access point. bridge-utils provides the software for combining interfaces (eth1 and wlan0) into a common network through a virtual "bridge" interface.

Note that hostapd gets "deployed" when installed, and like for dnsmasq, you'll need to disable that:

# service hostapd stop
# update-rc.d hostapd disable

The previous setup is now split up such that DHCP is provided on the bridge which is configured with eth1 and wlan0 as its ports. The new setup in /etc/network/interfaces.d/downlink.conf might be as follows:

# Virtual bridge interface with DHCP service
iface subnet inet static
    address 192.168.200.1/24
    bridge_ports none
    up /usr/sbin/dnsmasq -i subnet -a 192.168.200.1 -I lo -I wlan0 -I eth0 -I eth1 \
       -p 0 -K -D -N -b --dhcp-sequential-ip \
       --dhcp-option=3,192.168.200.1 \
       --dhcp-option=6,$DNSHOST \
       -F 192.168.200.2,192.168.200.254,255.255.255.0,192.168.200.255 \
       --dhcp-hostsfile=/var/run/subnet.dhcphosts
    down pkill -f 'dnsmasq -i subnet'

# The cable interface
iface eth1 inet manual
    up brctl addif subnet $IFACE

# The wireless interface
iface wlan0 inet manual
    hostapd /etc/hostapd/mywifi.conf
    up brctl addif subnet $IFACE

Then you need to configure your access point in /etc/hostapd/mywifi.conf perhaps as follows:

interface=wlan0
country_code=AU
hw_mode=g
channel=5
macaddr_acl=0
auth_algs=1
ignore_broadcast_ssid=0
ssid=mywifi
wpa=2
wpa_passphrase=abadaba001133557799
wpa_key_mgmt=WPA-PSK WPA-PSK-SHA256

There are "millions" of options that may be set and varied; especially you will want to confirm or change ssid and wpa_passphrase. Look at /usr/share/doc/hostapd/examples/hostapd.conf for inspiration.

When it works, you bring it up with subnet first, then eth0 and then wlan0.

# ifup subnet
# ifup eth1
# ifup wlan0

Note that some people prefer to name the bridge as br0 whereas I like the more intentional naming

Also, note that the bridge interface, subnet, will use the MAC address of one of its ports. If that port interface is taken down, then that bridge will change its MAC address to that of the remaining port. This is a feature of bridge interfaces which sometimes causes confusion.

EDIT: corrected the subnet configuration which had bad copy-paste remnants that mentioned eth1 wrongly.

Setup for ipv4

1. Enable forwarding for the kernel:

   # sysctl net.ipv4.ip_forward=1

2. Add a masquerading rule to the kernel's networking:

   # iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

3. Set up ifupdown configuration for eth1 using dnsmasq for DHCP.
    

   1. This involves the initial step of disabling its default deployment that you get when installing it, and then just use it for downlink DHCP service. Something like the folllowing:

      # sed 's/ENABLED=1/ENABLED=0/' -i /etc/dnsmasq/default
      # update-rc.d dnsmasq stop
      # update-rc.d dnsmasq disable

   2. Write a file /etc/network/interfaces.d/downlink.conf with the following, where you replace $DNSHOST with the ip address of your DNS server:

      iface eth1 inet static
      address 192.168.200.1/24
          up /usr/sbin/dnsmasq -i eth1 -a 192.168.200.1 -I lo -I wlan0 -I eth0 \
             -p 0 -K -D -N -b --dhcp-sequential-ip \
             --dhcp-option=3,192.168.200.1 \
             --dhcp-option=6,$DNSHOST \
             -F 192.168.200.2,192.168.200.254,255.255.255.0,192.168.200.255 \
             --dhcp-hostsfile=/var/run/eth1.dhcphosts
          down pkill -f 'dnsmasq -i eth1'

       

4. Make sure your /etc/network/interfaces includes that configuration with e.g. a line:

   source /etc/network/interfaces.d/downlink.conf

   (or with the wildcard statement source /etc/network/interfaces.d/* that is a debian default)

5. Bring up eth1 with that configuration

   # ifup eth1

   This will also start dnsmasq for serving IP addresses via DHCP on eth1, and it will also store the allocations in the file /var/run/eth1.dhcphosts. dnsmasq is killed when eth1 is deconfigured with ifdown or ifdown --force.

I think that would be all, but I do forget things now and then.

@Élisabeth it appears you are using "Expert install" method and are skipping the "load components" step. (Otherwise you would have an ext4 formatting option).

May advice on that would be: Don't.

The plain "install" method works fine for the overwhelming majority of cases and it's only if you really insist on some special peculiarity during the installation procedure that you would use "Expert install". I know that some people feel good about running an "Expert install" even though their need for that is nil, but if you do, you will need to explicitly take all the steps that are needed (which presupposes knowing which they are).

Obviously I might be wrong in my guesswork and in that case you should just ignore me.

No, according to the log there is a serial link set up (over USB) on /dev/ttyUSB0, so the next is to point the software to that.

First, of course, you need to make sure that the software (user) has permission to read and write /dev/ttyUSB0.
The "professional" way for that would be to make sure the user is in the special user group for operating that device, while the "hobbyist" approach is to simply chmod a+rw /dev/ttyUSB0 and let any user (on that computer) do anything to it.

Hmm. I'm not sure how then to verify.
Maybe, after doing dd, eject the USB and put it back in, while still in windows.
It should then contain two partitions; the first of some unknown format (format zero) and the second a FAT12 partition. If you mount that, it should have a folder named EFI.

Possibly you can use the diskpart command, then select the USB disk and use the sub command list partition.
https://docs.microsoft.com/en-us/window … s/diskpart

sorry about editing your post.. must be tired...

Ok. so AnyBurn is no good, then. Possibly dd-windows? but you must make sure to select The Whole usb stick and not any of its partitions.. except that possibly dd-windows uses the name "partition0" for the whole disk (again I've picked that idea from my web searching)

@Élisabeth, the ISO file is supposed to be put onto a USB memory stick to reside from the physical block 0 and up on the USB. Copying onto a partition is not the right way.

To achieve that on windows seems unduly complicated but it should be possible, and in particular I believe dd-windows may be used for it. The important point is that the USB becomes an exact copy of the ISO from its block 0 up to whatever size the ISO is, and then the USB stick can have whatever on the blocks after that. (Somewhere I saw the suggestion that "the disk as a whole" is Partition0 with dd-windows)

The first partition on a disk starts some few blocks in and the first few blocks contain the partition table. The ISO file starts at block 0 and includes a partition table for its partition layout, which includes an EFI partition and a CDROM partition. All that must be put onto the USB memory stick from its block 0.

Note that when you "format the USB as FAT32" you actually create a single first partition on that USB, and then copy&paste just copies the ISO file to be a file on that partition. Doing that is not the right way. Again, just to have it repeated three times: you'll need to copy the ISO onto the USB stick as a whole to become the exact memory image of the USB stick from block 0 and up.

Ralph.