Thank you very much, that was the solution!

Greetings, FM_81

Which bootorder ist defined in the EEPROM of the raspberry?
If USB is at position 2 or 3, it would be enough simply to remove the SD-card.
Otherwise you need to change it first.

Best regards, FM_81

I'm not sure? Why should such a crappy stuff be enabled by default? It's a nearly blank installation, only minimal changes was made?
And of course nothing related to "DHCP MAC Randomization" ...
Sorry, I forgot to say, that I was speaking about the ethernet interface, wlan isn't involved at all! 

The DHCP-server is a machine running DNSMASQ - it never shows the behaviour to pick "allways the next IP" before - in every other case it has always picked a random address from the reserved pool, if it sees a new MAC-address.

Best regards, FM_81

May be, the card has reached "end of life"? At this point the internal controller (inside the card) goes to "read-only" (this has nothing to do with any kind of mechanical switch on side of the card) and may be, he gives no information back about doing so. So the underlying operation-system oder any kind of software (like GParted) thinks, everything is fine and you'll get no errors here.

Best Regards, FM_81

Good Morning!

It looks like you've made NO MISTAKE, but some network-stuff (modules) inside the "initramfs" seems missing? I had also no success on two different machines ...

Best Regards, FM_81

PS: The last line of your log isn't clear to me? Or have you terminated 'dnsmasq' manually?
On other side: the most important part of output was seen on the clients monitor, not on the server, at least for me?

Of course you are correct! My fault, I was in thoughts about a devuan-raspberry-image during writing this (which isn't the case here). Sorry ...

Greetings, FM_81

Type su and ENTER.
You will be asked for the root-password. Type toor and ENTER again. (No screen-output here.)
Now you are 'root' and there is no need to put anything in front. You can test "who you are" by

whoami

My answer was was not related to the power-supply-USB-problem; it was for seeing whats inside '/proc/config.gz' !

Regards, FM_81

First unpack it. You'll get a file like 2020-02-13-raspbian-buster-lite.img (name may differ, if it is an older version)
Then login as ROOT, another linux machine is needed!
Find out, which is the next free loopdevice:

losetup -f

You'll get an answer like /dev/loop2 (number at the end may differ again)
Now mount the second partition of the Raspbian-file

losetup -P /dev/loop2 /path/to/somewhere/2020-02-13-raspbian-buster-lite.img
mount /dev/loop2p2 /mnt/any_mountpoint_name

You may now look inside the image, you'll found the whole system in /mnt/any_mountpoint_name. (/boot is the first partition, but we do not need this here) You can now copy everything you want from the Raspbian-root-partition without the need of a extra SD-card.
Don't forget after all to do:

umount /mnt/any_mountpoint_name
losetup -d /dev/loop2

Greetings, FM_81

Think you mean 'balena-Etcher"?
But from my point of view I would not trust this piece of software anymore: https://github.com/balena-io/etcher/issues/2977
The combination of "secretly spies" and pure root-access to raw-devices sounds not good in my ears, no matter under wich operating system?!
Not sure, what they will do in future versions, if nobody would care about ...

Best regards, FM_81

Based on the raspi3-image (same root-password 'toor'), but for model 4:
https://www.file-upload.net/download-13 … mg.gz.html
I replaced/added files from the following debs:

firmware-brcm80211_20190114-1+rpt4_all.deb
libraspberrypi0_1.20190925-2_armhf.deb
libraspberrypi-bin_1.20190925-2_armhf.deb
libraspberrypi-dev_1.20190925-2_armhf.deb
raspberrypi-bootloader_1.20190925-2_armhf.deb
raspberrypi-kernel_1.20190925-2_armhf.deb

from the raspbian downlod-site.

Tested  with SSH and composite-video out, not with HDMI yet, but it should probably work too?
I'm sure, there is a lot of work undone, but as basic image it works and it survived an

apt-get update
apt-get upgrade

but updates are not included in the image ...
MD5-checksum should be

4b38c49972103a4c452212726de01159 *./devuan_ascii_2.0.0_arm64_raspi4.img.gz

Best Regards, FM_81

Hello all together!

I've downloaded the files, you've described (from the same link) today. The checksum of the bin-file still matches, but this one from the txt-file doesn't? (This makes me a little bit wondering, as they are dated from February 15th?) And of course, if they where copied to the described place, my pi-zero has no WLAN-interface? Some questions remain:

- Can someone provide a working version of the txt-file?
- Is it possible, that something else was going wrong?

The image I've used was devuan_ascii_2.0.0_armel_raspi1.img.xz from the download-zone-site.

Greetings, FM_81