You are not logged in.
Perhaps the MAC is changed by firmware? In that story the first would be hardware (PROM) MAC while the latter would be a firmware derivative. Guesswork.
When you say "no network manager at all" you actually mean "just using ifupdown". That is the traditional network management which is configured by means of a text editor to edit its configuration files... It is indeed the simplest and easiest way with maximal flexibility.
Up to the right there is the WM selector, for choosing fluxbox rather than xfce4 ?
Given that your /etc/resolv.conf is a link it suggests you also have the package resolvconf installed, and that would provide an additional depth to the confusion.
But in any case, DNS setting is part of the DHCP protocol; you know, when your machine contacts the router so as to get an IP address. At that time your machine is also told the IP address of the outbound gateway and the address of the DNS server(s). Those are suggestions by the DHCP server (your router) which get digested by the DHCP client running on your machine. The IP address is assigned to the network interface (via a kernel system call); the gateway IP is assigned to the routing table (via another kernel system call), and the DNS IP address(es) is registered in the file /etc/resolv.conf.
All that happens regardless of which networking software you use; whether it's plain ifupdown, wicd, network-manager or connman.. or whatever.
With resolvconf, you (unbeknowingly?) have opted for a local control of /etc/resolv.conf which is at odds with most networking software unless it also is configured to avoid messing with /etc/resolv.conf. Your first step towards bliss would be to purge resolvconf and reinstate /etc/resolv.conf as a text file.
Nothing stopping another developer (to be?) to stand up and be counted.
As wicd is forked by Devuan, the process could be to 1) get an account at git.devuan.org, 2) fork the devuan/wicd project for updating to working form (on branch suites/unstable), and then 3) issue a merge-request... all while concurrently getting a dialogue with Andreas going.
It would then be useful to also clone hanaguro's project as an additional "remote" for the workspace, so as to easily be able to match up their changes against Devuan's history. Doing so would have the additional advantage of getting that code away from Microsoft's (github) control.
Yes apt-get update does that. The downloaded "packages" files are kept in /var/lib/apt/lists
@Micronaut: yes. Google leaves its repository hook-in (i.e. a file) in /etc/apt/sources.list.d/ and you have to remove it by hand. man sources.list has more details.
EDIT: Google might also have left a PGP key (i.e. another file) in /etc/apt/trusted.gpg.d/ and you might want to remove that as well. man apt-get is a fairly good starting point about that.
It was FUD whether you accept it or not. Sometimes a couple of thoughts before typing can do wonders.
Note that /proc is a virtual filesystem tree giving insight into the running kernel. Not to be played with by hand.
Yes, wicd did/does provide a good and fairly distinct GUI for configuring the network devices and before it was abandoned due to the python2 -> python3 change it was still only in the beginning of its path to enshittification, so quite a good option if one feels a need for a GUI.
Well, not that wicd plays any role whatsoever in the transmission; it's all wpa_supplicant for link level encryption/decryption and the handling the connection logic via its wpa_action.
The best however is to not use any of those configuration scramblers, but to settle for the original ifupdown system together with wpagui. With those you are seated with maximal flexibility, simple configuration basis by editing text file(s) and a fantastic opportunity catering for any custom networking landscaping.
All it takes is a bit of knowledge which is acquired by means of reading -- reading man pages, starting with man interfaces. Knowledge is power. When you give knowledge away for an idea of convenience, then you lose.
To be clear: when/if interesting discussions emerge I would be keen to assist with improved platform software.
When/if interesting discussions emerge I would be keen to assist with improved platform software.
I set up a package mirror recently, and after a month++ it's sailing with these metrics
Network bandwith: 60GB/month (est)
Disk usage: 23 G
CPU load (avg/peak): 2% / 4% (at 4 traffic peak times per day)
Admin time (est): averaging to <10 min/day
As you say, it only holds Devuan packages and it redirect to deb.debian.org for all Debian packages (as per the standard mirroring instructions).
The mirror is a Single-CPU VPS (qemu) with 1G RAM allotment by a "Tier 3" company.
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).
I use ifupdown on its own.
But, yes, connman apparently includes DNS caching with built-in assumption that the network world is unchanging. Not that I know much about it; for me it turned up as a debian hack when wicd was abandoned, but there may well be more history to it than that.
The easiest and best (I say) is to just use traditional network configuration with ifupdown together with wpa_supplicant and possibly its wpagui gui tool,
EDIT: start with man interfaces
Don't use connman
how about using
sudo reboot ; exitGood.
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.
There is no magic involved.
Installers that are fully contained within their initrd will be fully loaded by ventoy from their ISO files, and "work" provided that they don't require access to their media.
Installers that require access to their media will not have that access, because the media is not available as partitions with ventoy.
If such an an installer is made to look for a ventoy partition, to mount that filesystem, to search for their ISO among the collection of ISO image files, then it may well also work.
Good. I suppose that error code "-19" means something particular but I don't really know how to find out what. You might want to drop in to the #devuan IRC channel on lilbera.chat where you're likely to find people that knows about graphics.