The programs egrep and fgrep belong to the grep package.
Possibly you have them as /bin/grep and /bin/egrep where they have been residing since yonks. Now everything is supposed to reside in /usr/bin due to a reconfiguration of the root filesystem where all pathnames /bin, /sbin and /lib* are replaced with links to same-named directories under usr.

You may have heard about it as "usrmerge".

Most likely you have updated checking tools that expects/requires those silly-links.

Note that UEFI bios is 32-bit software so booting may have difficulties with an EFI partition beyond 4G byte address. The general advice is always to have that partition first on the disk (i.e. starting at a 1M = 2048 sectors offset).

Don't use connman

Good.

Development like that would happen in git.devuan.org/devuan/documentation with normal fork+change+merge activity.

Thus, 1) register there; 2) fork the project, 3) start a branch.. perhaps named wip/excalibur (but naming could well be discussed); 4) edit; 5) make merge requests to the source project.

dd

Does the user that starts Xorg have due access to /dev/dri/card0 ?

A next option if indeed the "59" package does provide the required ABI could be to use equivs and set up a dummy "58" package so as to make apt happy (believing the "58" package is installed).

Your equivs package, which takes a small amount of effort, would be void of content and only have the meta information declaring it to provide libavformat58 and depend on libavformat59.

In that way you would implement that claim that your "59" package provides whatever is required from the "58" package.

Thanks for your concern. Let us now and henceforth round up the nonsense and only post things likely to be of more general interest.

Possibly i you get the initial grub splash screen, you might try using E, C or ESC to enter grub command line and ther type "exit" and ENTER.

Please use "code" block around code and log files.

@alexkemp; late evening perhaps
Please check /etc/default/dbus again (which indeed is different from  /etc/init.d/dbus).

You might want to use the following setup variant:
First, create or edit  /etc/wpa_supplicant/wpa_supplicant.conf to have 2 initial lines like this:

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1

Secondly, change /etc/network/interfaces for wlan0 to read like this

auto wlan0
iface wlan0 inet manual
    wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf
iface default inet dhcp

Thirdly, add the user to the group netdev.

Then that user can operate the wlan0 connection with wpagui (which you might need to install), and all details for networks that they connect to gets saved in /etc/wpa_supplicant/wpa_supplicant.conf, to be autimatically re-used upon roaming... (it's also possble for you to enter that beforehand with a text editor, but the file is also updated by wpa_supplicant. See man wpa_action for details).

EDIT: Note that there are two iface blocks for wireless in this setup. Firstly the wlan0 block that registers it to wpa_supplicant via the wpa_roam setting, telling the name of the connection database file to use. Secondly a default block that wpa_action uses for configuring the interface. Note that "default" is the name of that block.

EDIT 2: Technically this solves the issue of running a dhcp attempt too early to the wrong network by  the wireless setup being broken up into two phases. The first phase happens on boot, where the interface is brought up to link level. That enables wpa_supplicant to scan for available networks. The interface is thereafter raised to ip level when wpa_supplicant discovers a network it has connection details for, and then dhcp is used (as configured by the default iface block) with the approrpiate link encryption for aquiring the network address(s) etc.

This setup also allows for static (rather than dhcp) network configurations to be made for individual networks. You do that by other specially named iface blocks to identify the concerned connections. See the man page if you need that.