No, that’s part of the image and should be there. You can check for yourself by opening the archive and image.
We only modify the file based on the settings you set in dietpi.txt. Are you sure you looked in the right place?
Hmm, I guess I wasn’t fully awake yet. 
Let’s take a look now.
cat cae41ead-51d2-4a01-8550-f80df6860d32/etc/network/interfaces
# Location: /etc/network/interfaces
# Please modify network settings via: dietpi-config
# Or create your own drop-ins in: /etc/network/interfaces.d/
# Drop-in configs
source interfaces.d/*
# Ethernet
allow-hotplug eth0
iface eth0 inet static
address 192.168.100.191
netmask 255.255.255.0
gateway 192.168.100.254
#dns-nameservers 9.9.9.9 149.112.112.112
It doesn’t look so bad, does it? ls cae41ead-51d2-4a01-8550-f80df6860d32/boot/firmware/ Why was debug.log not written? The script was executed, as shown by the interfaces.
It’s hard to believe. For days, the Pi1 wouldn’t let me in. Today, I started the computer without much expectation. And—oh miracle—within a short time, it appeared in the router and was accessible via ssh using the address configured as a fixed IP by the script. The only conclusion is that computers are just like people and therefore unpredictable. I’m just curious to see if it will be successful in its next attempts to start up.
Now we have to wait and see if the setup/configuration runs without errors.
Until then, thank you very much for your support.
2 Likes
FYI: I made fresh install with BalenaEtcher. The Pi wouldn’t start. Then I set
AUTO_SETUP_NET_ETH_FORCE_SPEED=100.
And just like that, it was on the network. The router shows neverthless Gbit/s.
Who knows, maybe yesterday’s lunar eclipse untangled a knot?
Jep that looks correct. debug.log is on the other/first partition (the FAT one), which is mounted to /boot/firmware.
At this point I would have guessed that DHCP was the issue, and the static IP fixed it, but …
to that one worked with DHCP then? Ah, and can you check whether the ethtool service is actually active? If boot went too far before you changed the setting, it would not have been applied anymore:
systemctl status ethtool_force_speed
But great that works! Still curious what exactly failed/was the culprit originally, DHCP, router assuming Gbit connection, a combination of both, or some other random issue? But also ethtool was hanging originally, hmm. Anyway, let us know if any such issue reappears.
First of all: Installing DietPi on the Pi1 is now only a matter of curiosity. If you don’t feel like doing it anymore, that’s fine and no problem.
What do we have?
Yesterday, a working installation. Then yesterday evening, I took another SD card, wrote the image to it with BalenaEtcher, didn’t configure anything else, and started the rpi. It didn’t boot again.
Today, I tried again with the SD card. No success. So I used another SD card – the Pi1 boots without any problems. Then I rewrote the SD card that it wouldn’t boot with – now it boots. Even with further attempts: rewritten image/other SD cards/changed dietpi.txt, it has been starting without any problems so far. The router assigns IPs via DHCP.
It remains a mystery.
Oh well, I haven’t had such problems with newer rpis so far.
Best regards!
Translated with DeepL.com (free version)
Hi, same here. I can confirm that the network installation in the DietPi_RPi1-ARMv6-Trixie.img.xz image is not working out of the box with a Pi1B. I got it running with a static address by editing the /etc/network/interfaces. The DNS 9.9.9.9 was commented out and I activated it manually.
(I wrote the image with the gnome-disk-utility to the card.)
DNS is not configured in /etc/network/interfaces. It is set in /etc/resolv.conf
Right, the line has any effect only if resolvconf is installed. We should probably not add it at all if that is not the case, to avoid confusion.
Network or DHCP issues can have various different reasons, not necessarily related to the hardware or the OS. Hence in case, please go through the debugging steps done here in this topic, and maybe open a new one with findings collected.