Open chips023 opened 2 years ago
Looks like your system is not getting an IP address assigned via Ethernet
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 3
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 18
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
It seems that everything is normal~but the system is not accessible and the device does not respond
yes because it does not get an IP address assigned. You could try to use STATIC IP instead of DHCP.
But I access the device through a serial connection, not through the network Use a serial connection to gain access to the console
Now the serial console also crashes, and there is no response~
Normally, even if there is no network card or the network card is not started, the serial console access will not be affected
Normally, even if there is no network card or the network card is not started, the serial console access will not be affected
Thank you very much for your reply, but I still haven't found the problem... Maybe I'm too stupid...: (
Is it possible that the CPU frequency setting problem caused the system to crash when entering the system?
I have repeatedly tested for 3 times by referring to the build link. Unfortunately, the compiled system cannot enter and crash each time...: (
Which SBC is it, actually? There are some (Amlogic especially) having boot issues with recent Armbian kernel upgrade. Please also try this on the Armbian image before applying the Debian installer, to assure it is not an Armbian issue:
apt update
apt full-upgrade
reboot
Is it possible that the CPU frequency setting problem caused the system to crash when entering the system?
Rare but possible. Try to change it from schedutil
to ondemand
in /boot/dietpi.txt
right after you applied the installer and before reboot.
Now the serial console also crashes, and there is no response~
Which serial console device does it use (like /dev/ttyS0
)? And which baud rate does it use (can be usually seen in /boot/boot.cmd
)?
The sbc is customized by us.
On the Armbian image(Armbian 22.08 Bullseye), everything is normal. It can be started normally and enter the system interface
it use /dev/ttyS0
The sbc is customized by us.
Which Armbian image do you use then, or which target platform, if you used the Armbian image builder?
Please also go through the other points mentioned above.
Armbian Espressobin It is a reference platform for us We use this for reference to build our target platform is mvebu64
The sbc is customized by us.
Which Armbian image do you use then, or which target platform, if you used the Armbian image builder?
Please also go through the other points mentioned above.
Thank you for all your help. I really like the dietpi system~
Every time I missed the last step of success,,
So sad :(
─────────────────────────────────────────────────────
DietPi v8.11.2 : 20:32 - Thu 11/24/22
─────────────────────────────────────────────────────
- LAN IP : fe80::251:82ff:fe11:2200 (eth0)
Default Login:
Username = root
Password = dietpi (or custom dietpi.txt entry)
Please hit <return> to login
。。。。。。。。。。。。
Then there is endless waiting.... No reaction
looks like you don't have a valid IP address. At least it seems to be a link local IPv6 address only
But I access the device through a serial connection, not through the network Use a serial connection to gain access to the console
Now the serial console also crashes, and there is no response~
But I access the device through a serial connection, not through the network Use a serial connection to gain access to the console
Now the serial console also crashes, and there is no response~
It seems that everything is normal, no error message is output... Output information of reboot:
Welcome to Debian GNU/Linux 11 (bullseye)!
[ OK ] Created slice system-getty.slice.
[ OK ] Created slice system-modprobe.slice.
[ OK ] Created slice system-serial\x2dgetty.slice.
[ OK ] Started Dispatch Password …ts to Console Directory Watch.
[ OK ] Started Forward Password R…uests to Wall Directory Watch.
[ OK ] Set up automount Arbitrary…s File System Automount Point.
[ OK ] Reached target Local Encrypted Volumes.
[ OK ] Reached target Paths.
[ OK ] Reached target Remote File Systems.
[ OK ] Reached target Slices.
[ OK ] Reached target Swap.
[ OK ] Listening on fsck to fsckd communication Socket.
[ OK ] Listening on initctl Compatibility Named Pipe.
[ OK ] Listening on Journal Audit Socket.
[ OK ] Listening on Journal Socket (/dev/log).
[ OK ] Listening on Journal Socket.
[ OK ] Listening on udev Control Socket.
[ OK ] Listening on udev Kernel Socket.
[ OK ] Reached target Sockets.
Mounting Huge Pages File System...
Mounting POSIX Message Queue File System...
Mounting Kernel Debug File System...
Starting Restore / save the current clock...
Starting Set the console keyboard layout...
Starting Create list of st…odes for the current kernel...
Starting Load Kernel Module configfs...
Starting Load Kernel Module fuse...
Starting Journal Service...
Starting Load Kernel Modules...
Starting Remount Root and Kernel File Systems...
Starting Coldplug All udev Devices...
[ OK ] Mounted Huge Pages File System.
[ OK ] Mounted POSIX Message Queue File System.
[ OK ] Mounted Kernel Debug File System.
[ OK ] Finished Restore / save the current clock.
[ OK ] Finished Create list of st… nodes for the current kernel.
[ OK ] Finished Load Kernel Module configfs.
[ OK ] Finished Load Kernel Module fuse.
[ OK ] Finished Load Kernel Modules.
[ OK ] Finished Remount Root and Kernel File Systems.
Mounting FUSE Control File System...
Mounting Kernel Configuration File System...
Starting Load/Save Random Seed...
Starting Apply Kernel Variables...
Starting Create System Users...
[ OK ] Mounted FUSE Control File System.
[ OK ] Mounted Kernel Configuration File System.
[ OK ] Finished Apply Kernel Variables.
[ OK ] Finished Create System Users.
Starting Create Static Device Nodes in /dev...
[ OK ] Started Journal Service.
[ OK ] Finished Create Static Device Nodes in /dev.
Starting Rule-based Manage…for Device Events and Files...
[ OK ] Finished Set the console keyboard layout.
[ OK ] Finished Coldplug All udev Devices.
[ OK ] Reached target Local File Systems (Pre).
Mounting /tmp...
Mounting /var/log...
Starting Helper to synchronize boot up for ifupdown...
[ OK ] Mounted /tmp.
[ OK ] Started Rule-based Manager for Device Events and Files.
[ OK ] Mounted /var/log.
[ OK ] Reached target Local File Systems.
Starting Set console font and keymap...
Starting Flush Journal to Persistent Storage...
[ OK ] Finished Set console font and keymap.
[ OK ] Finished Flush Journal to Persistent Storage.
Starting Create Volatile Files and Directories...
[ OK ] Finished Create Volatile Files and Directories.
[ OK ] Started Entropy Daemon based on the HAVEGE algorithm.
Starting Network Time Synchronization...
Starting Update UTMP about System Boot/Shutdown...
[ OK ] Finished Update UTMP about System Boot/Shutdown.
[ OK ] Finished Load/Save Random Seed.
[ OK ] Started Network Time Synchronization.
[ OK ] Reached target System Initialization.
[ OK ] Started Daily Cleanup of Temporary Directories.
[ OK ] Reached target Basic System.
[ OK ] Reached target System Time Set.
[ OK ] Reached target System Time Synchronized.
[ OK ] Started Discard unused blocks once a week.
[ OK ] Reached target Timers.
Starting DietPi-RAMlog...
Starting LSB: Lightweight SSH server...
[ OK ] Found device /dev/ttyS3.
[ OK ] Found device /dev/ttyS0.
[ OK ] Found device /dev/ttyS1.
[ OK ] Finished DietPi-RAMlog.
[ OK ] Found device /dev/ttyS2.
Starting DietPi-PreBoot...
[ OK ] Started LSB: Lightweight SSH server.
[ 6.404305] DietPi-PreBoot[360]: DietPi-CPU_set | CPU governors are not available on this system. This is probably a virtual machine. Aborting...
[ OK ] Finished DietPi-PreBoot.
[ OK ] Reached target Network (Pre).
[ OK ] Found device /sys/subsystem/net/devices/eth0.
Starting ifup for eth0...
[ OK ] Finished Helper to synchronize boot up for ifupdown.
Starting Raise network interfaces...
[ OK ] Finished Raise network interfaces.
[ OK ] Finished ifup for eth0.
[ OK ] Reached target Network.
[ OK ] Reached target Network is Online.
[ OK ] Started DietPi-PostBoot.
Starting Permit User Sessions...
[ OK ] Finished Permit User Sessions.
[ OK ] Started Getty on tty1.
[ OK ] Started Serial Getty on ttyS0.
[ OK ] Started Serial Getty on ttyS1.
[ OK ] Started Serial Getty on ttyS2.
[ OK ] Started Serial Getty on ttyS3.
[ OK ] Reached target Login Prompts.
[ OK ] Reached target Multi-User System.
[ OK ] Reached target Graphical Interface.
Starting Update UTMP about System Runlevel Changes...
[ OK ] Finished Update UTMP about System Runlevel Changes.
─────────────────────────────────────────────────────
DietPi v8.11.2 : 20:32 - Thu 11/24/22
─────────────────────────────────────────────────────
- LAN IP : fe80::251:82ff:fe11:2200 (eth0)
Default Login:
Username = root
Password = dietpi (or custom dietpi.txt entry)
Please hit <return> to login
Did you actually hit return
key as stated in the pre-login banner?
Sure, but the keyboard has no response. I'm sure it's down and the dietpi host can't be found on the router.
I just see that it failed to set CPU governor settings, which alone is strange on a physical system as well 🤔. However, this rules out that schedutil
is the issue.
getty on tty1
and ttyS0
are both started, so there should be a login prompt on both. The UART works with default baud rate 115200 or there is an override in /etc/systemd/system/serial-getty@ttyS0.service.d
? However, this isn't touched on generic devices by the installer.
Not sure. If you used a fully functional Armbian image as basis, the installer shouldn't break it since kernel, bootloader, boot config, firmware and all such are not touched, or the Espressobin image is composed very differently, e.g. ships with other essential packages.
The UART works with rate 115200 then I mount the sd card on the ubuntu, and then see /etc/systemd/system/ :
root@wu-Ub:/etc/systemd/system# ls
bluetooth.target.wants
cloud-final.service.wants
dbus-fi.w1.wpa_supplicant1.service
dbus-org.bluez.service
dbus-org.freedesktop.Avahi.service
dbus-org.freedesktop.ModemManager1.service
dbus-org.freedesktop.nm-dispatcher.service
dbus-org.freedesktop.oom1.service
dbus-org.freedesktop.resolve1.service
dbus-org.freedesktop.thermald.service
dbus-org.freedesktop.timesync1.service
default.target.wants
display-manager.service
display-manager.service.wants
emergency.target.wants
final.target.wants
getty.target.wants
graphical.target.wants
multi-user.target.wants
network-online.target.wants
nfs-client.target.wants
oem-config.service.wants
paths.target.wants
printer.target.wants
prltoolsd.service
prltools-reconfig.service
remote-fs.target.wants
rescue.target.wants
sleep.target.wants
snap-bare-5.mount
snap-core20-1587.mount
snap-core20-1695.mount
snap-firefox-1635.mount
snap-firefox-2088.mount
'snap-gnome\x2d3\x2d38\x2d2004-112.mount'
'snap-gnome\x2d3\x2d38\x2d2004-119.mount'
'snap-gtk\x2dcommon\x2dthemes-1535.mount'
snap-snapd-16292.mount
snap-snapd-17576.mount
'snap-snapd\x2ddesktop\x2dintegration-14.mount'
'snap-snap\x2dstore-582.mount'
'snap-snap\x2dstore-599.mount'
sockets.target.wants
sudo.service
sysinit.target.wants
syslog.service
timers.target.wants
'var-snap-firefox-common-host\x2dhunspell.mount'
root@wu-Ub:/etc/systemd/system#
I was reading through the notes of Armbian on the image: https://www.armbian.com/espressobin/
There seem to be different models with different (stable) CPU frequency and it states that flashing a matching U-Boot to SPI flash is mandatory. Our installer runs the command to reflash U-Boot, although the one to flash to the image, not to the SPI flash. Not sure what it does exactly on this system where booting without SPI seems to be not possible? I'll check that when I'm home.
Thank you. Look forward to your good news
Cheers!
hi MichaIng: is the any news?
thank u @MichaIng
I just checked the script, and as long it is not a specific board variant, flashing U-Boot is a no-op, so the dietpi-installer
does not change anything that end:
DIR=/usr/lib/linux-u-boot-current-espressobin_22.11.1_arm64
write_uboot_platform ()
{
if [[ $BOARD = macchiatobin-doubleshot ]]; then
dd if=$1/flash-image.bin of=$2 bs=512 seek=1 status=noxfer > /dev/null 2>&1;
else
/bin/true;
fi
}
However, I think I found it. Is the serial console device you access with on Armbian ttyMV0
? This serial device name pattern is not part of the serial devices, enabled in dietpi-installer
. You can check the used console device via:
tty
hi~
root@wu:~# tty /dev/ttyMV0
Yes, I think the information I gave back was wrong. I used ttyMV0 instead of ttyS0 So Sorry I wonder if this issue can be fixed in dietpi-installer? I want to try dietpi~ Thank you
Seems so. Just to assure this really is the issue. After dietpi-installer
has completed, run:
systemctl enable serial-getty@ttyMV0
and see whether you can now login as expected. If so, I'll add this serial device naming scheme to our scripts.
Yes, so I can enter the system. Thank you, please add this serial device naming scheme to scripts.
systemctl unmask serial-getty@ttyMV0 && systemctl enable serial-getty@ttyMV0
─────────────────────────────────────────────────────
DietPi v8.11.2 : Reboot required
─────────────────────────────────────────────────────
- LAN IP : fe80::f2ad:4eff:fe08:0 (eth0)
Default Login:
Username = root
Password = dietpi (or custom dietpi.txt entry)
Please hit <return> to login
Debian GNU/Linux 11 DietPi ttyMV0
DietPi login:
cheers
The next problem is the network link. It seems that the IP address can not be obtained correctly
After the system is installed and reboot, the network cannot be recognized
Each reboot stays here for a long time, and I think this problem has something to do with not getting the network address
PS: There is no such problem in armbian,Otherwise, the installation dietpi-installer
script cannot be executed...
Starting ifup for eth0...
[ OK ] Finished Helper to synchronize boot up for ifupdown.
Starting Raise network interfaces...
[ OK ] Finished Raise network interfaces.
[* ] A start job is running for ifup for eth0 (49s / 5min)
When I restart the network, the following message appears... Of course, I think it has something to do with not getting the IPv4 address correctly.
[ INFO ] DietPi-Config | Dropping network connections, please wait...
[ INFO ] DietPi-Config | Restarting network connections, please wait...
[ OK ] DietPi-Config | Checking IPv4 network connectivity
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/f0:ad:4e:08:00:00
Sending on LPF/eth0/f0:ad:4e:08:00:00
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 7
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 11
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 19
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
Indeed, no DHCP offer has been received on the eth0
interface. Can you show the output of:
ip a
Indeed, no DHCP offer has been received on the
eth0
interface. Can you show the output of:ip a
root@DietPi:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1024
link/ether f0:ad:4e:08:00:00 brd ff:ff:ff:ff:ff:ff
@MichaIng
Does it work to apply a static IP? And I see you have IPv6 disabled, right? Does it change something when you enable it?
Weird is this output:
[ OK ] DietPi-Config | Checking IPv4 network connectivity
This is not supposed to be printed by this script, especially not at this place. Here is the related code:
# Restart network
G_DIETPI-NOTIFY 2 'Restarting network connections, please wait...'
G_EXEC systemctl daemon-reload
So you should instead see:
[ OK ] DietPi-Config | systemctl daemon-reload
And of course the IPv4 connection check (which is a dietpi-globals
function, called by dietpi-update
and dietpi-software
, but not by dietpi-config
) shouldn't succeed as long as no IPv4 address has been assigned.
Can you also check carrier/link status, please:
cat /sys/class/net/eth0/carrier
ethtool eth0
hi~ @MichaIng
Does not work to apply a static IP, yes,i have IPv6 disabled, But nothing works
root@DietPi:~# cat /sys/class/net/eth0/carrier
1
root@DietPi:~# ethtool eth0
Settings for eth0:
Supported ports: [ MII ]
Supported link modes: 1000baseT/Full
Supported pause frame use: Symmetric Receive-only
Supports auto-negotiation: Yes
Supported FEC modes: Not reported
Advertised link modes: 1000baseT/Full
Advertised pause frame use: Symmetric
Advertised auto-negotiation: Yes
Advertised FEC modes: Not reported
Link partner advertised link modes: 1000baseT/Full
Link partner advertised pause frame use: No
Link partner advertised auto-negotiation: No
Link partner advertised FEC modes: Not reported
Speed: 1000Mb/s
Duplex: Full
Auto-negotiation: on
Port: MII
PHYAD: 0
Transceiver: internal
Supports Wake-on: d
Wake-on: d
Link detected: yes
Hmm, I'm a little out-questioned then. The dietpi-installer
keeps the Armbian kernel and firmware installed, otherwise does really nothing special about the network interfaces. AFAIK Armbian uses NetworkManager by default, but ifupdown
and isc-dhcp-server
are the Debian default (lower level) network tools which should just work the same way. The Ethernet link/carrier signal are there, it's just that the SBC does not receive an answer from the router on its DHCP requests.
Are there any kernel errors shown?
dmesg -l emerg,alert,crit,err
Ah, and just to rule out an issue with the recent kernel release, can you test to upgrade everything on the Armbian image and see whether Ethernet still works?
apt update
apt full-upgrade
reboot
hi~ MichaIng,There is no error message: root@DietPi:~# dmesg -l emerg,alert,crit,err
I tested it right away on Armbian. Please give me a few minutes and come back soon...
@MichaIng When I upgrade, the network does not start automatically, I need to execute: ifconfig eth0 up dhclient wan
After execution, I can get the LAN IP, but I can't resolve the domain name, and then I add dns to /etc/resolv.conf to resolve the domain name normally
It looks like there is something wrong with the latest kernel or firmware, and I've posted information on the armbian forum asking for help...
As a temporary solution,How does dietpi's system manually boot the NIC?
The Armbian Forum confirmed the existence of the problem by: systemctl unmask systemd-networkd; systemctl start systemd-networkd
But I executed the above code on the dietpi system, and the reboot system still did not run normally...
root@DietPi:~# systemctl status networking.service
● networking.service - Raise network interfaces
Loaded: loaded (/lib/systemd/system/networking.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2022-12-03 17:55:40 GMT; 1min 21s ago
Docs: man:interfaces(5)
Process: 779 ExecStart=/sbin/ifup -a --read-environment (code=exited, status=1/FAILURE)
Main PID: 779 (code=exited, status=1/FAILURE)
CPU: 6ms
Dec 03 17:55:40 DietPi systemd[1]: Starting Raise network interfaces...
Dec 03 17:55:40 DietPi ifup[779]: ifup: /etc/network/interfaces:11: option with empty value
Dec 03 17:55:40 DietPi ifup[779]: ifup: couldn't read interfaces file "/etc/network/interfaces"
Dec 03 17:55:40 DietPi systemd[1]: networking.service: Main process exited, code=exited, status=1/FAILURE
Dec 03 17:55:40 DietPi systemd[1]: networking.service: Failed with result 'exit-code'.
Dec 03 17:55:40 DietPi systemd[1]: Failed to start Raise network interfaces.
Armbian's configuration information is as follows:
root@wu:~# cat /etc/network/interfaces
source /etc/network/interfaces.d/*
# Network is managed by Network manager
auto lo
iface lo inet loopback
There are a few things mixed up. First of all there are different network stacks used:
systemctl status NetworkManager
Since it has an own config files, it is expected that /etc/network/interfaces
is basically empty and the networking.service
is disabled, respectively, when starting, does nothing or cannot succeed.systemd-networkd
is a different network stack/tool, which implies DHCP as well: systemctl status systemd-networkd
It uses own config files below /etc/systemd/network
, hence similarly /etc/network/interfaces
is unused and networking.service
does nothing.ifupdown
in combination with isc-dhcp-server
/dhclient
. Here you run ifup eth0
to bring everything up, and it uses /etc/network/interfaces
. It however does not use networking.service
for bringing up anything else than the loopback interface. For actual interfaces, since they are added via allow-hotplug eth0
to /etc/network/interfaces
, they are started via ifup@eth0.service
as fast as the adapter is detected by the kernel, so nothing fails if e.g. a USB adapter is not attached.And generally ifconfig
is a legacy tools, not pre-installed on DietPi anymore. Nowadays one uses ip
instead:
ip l set dev eth0 up
If iface eth0 inet dhcp
is defined in /etc/network/interfaces
, this is done together with proper dhclient
startup via:
ifup eth0
hi~ MichaIng:
Looks to use
ifup eth0
It also failed to succeed
root@DietPi:~# ifup eth0
ifup: /etc/network/interfaces:11: option with empty value
ifup: couldn't read interfaces file "/etc/network/interfaces"
root@DietPi:~# cat /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 dhcp
address
netmask
#gateway .1
#dns-nameservers 9.9.9.9
# WiFi
#allow-hotplug wlan0
iface wlan0 inet dhcp
address
netmask
#gateway .1
#dns-nameservers 9.9.9.9
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
I modified the interfaces with dietpi-config before, which seems to have led to confusion
Now I find the default initial settings:
# 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 dhcp
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
#dns-nameservers 9.9.9.9 149.112.112.112
# WiFi
#allow-hotplug wlan0
iface wlan0 inet dhcp
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
#dns-nameservers 9.9.9.9 149.112.112.112
wireless-power off
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
Then the result of the execution:
root@DietPi:~# ifup eth0
ifup: interface eth0 already configured
Then it seems to be back to the beginning:
─────────────────────────────────────────────────────
DietPi v8.11.2 : Reboot required
─────────────────────────────────────────────────────
- LAN IP : Use dietpi-config to setup a connection (eth0)
Default Login:
Username = root
Password = dietpi (or custom dietpi.txt entry)
Please hit <return> to login
Debian GNU/Linux 11 DietPi ttyMV0
DietPi login: root
Password:
Linux DietPi 5.15.63-mvebu64 #22.08.1 SMP PREEMPT Tue Aug 30 06:59:12 UTC 2022 a arch64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
─────────────────────────────────────────────────────
DietPi v8.11.2 : Reboot required
─────────────────────────────────────────────────────
- LAN IP : Use dietpi-config to setup a connection (eth0)
DietPi-Update
─────────────────────────────────────────────────────
Phase: Checking for available DietPi update
[FAILED] DietPi-Update | Checking IPv4 network connectivity
- Command: ping -4nc 1 -W 10 9.9.9.9
Generic Device (aarch64)───────┤ DietPi-Update ├───────────────────────────────┐
│ Checking IPv4 network connectivity │
│ - Command: ping -4nc 1 -W 10 9.9.9.9 │
│ - Exit code: 2 │
│ - DietPi version: v8.11.2 (MichaIng/master) | HW_MODEL: 22 | HW_ARCH: 3 | │
│ DISTRO: 6 │
│ - Image creator: wu │
│ - Pre-image: Armbian │
│ - Error log: │
│ ping: connect: Network is unreachable │
│ │
│ Retry : Re-run the last command that failed │
│ Double timeout : Retry with doubled timeout for ping to wait for a reply │
│ Network settings : Enter dietpi-config network options │
│ DietPi-Config : Edit network, APT/NTP mirror settings etc │
│ Open subshell : Open a subshell to investigate or solve the issue │
│ Send report : Uploads bugreport containing system info to DietPi │
│ ●─ Devs only ───────────────────────────────────────────● │
│ Change command : Adjust and rerun the command │
│ │
│ │
│ <Ok> <Exit> │
│ │
┘
Generic Device (aarch64)
┌──────────────────────────────┤ DietPi-Config ├───────────────────────────────┐
│ Hardware : Generic Device (aarch64) │
│ │
│ 1 : Display Options │
│ 2 : Audio Options │
│ 3 : Performance Options │
│ 4 : Advanced Options │
│ 5 : Language/Regional Options │
│ 6 : Security Options │
│ 7 : Network Options: Adapters │
│ 8 : Network Options: Misc │
│ 9 : AutoStart Options │
│ 10 : Tools │
│ │
│ │
│ <Ok> <Exit> │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
Generic Device (aarch64)
┌──────────────────────────────┤ DietPi-Config ├───────────────────────────────┐
│ Please select an option to change: │
│ │
│ ●─ Adapter Options ──────────────● │
│ Ethernet : Available | [Off] | Disconnected │
│ WiFi : Not Found | [Off] | Disconnected │
│ ●─ Additional Options ───────────● │
│ IPv6 : [Off] │
│ Proxy : [Off] │
│ Test : Run internet connection test │
│ │
│ │
│ <Ok> <Back> │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
Generic Device (aarch64)
┌──────────────────────────────┤ DietPi-Config ├───────────────────────────────┐
│ │
│ Ethernet must be enabled before settings can be changed. │
│ │
│ Would you like to enable Ethernet now? │
│ - (NOTICE) Connections may drop! │
│ │
│ <Ok> <Cancel> │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 0 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 1 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 2 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 3 with SSID ""
[ INFO ] DietPi-WiFiDB | Applied WiFi DB slot 4 with SSID ""
[ SUB2 ] DietPi-Services > stop
[ INFO ] DietPi-Services | skip : cron (due to mask)
[ SUB2 ] DietPi-Set_hardware > wifimodules (disable)
[ OK ] wifimodules disable | Completed
Generic Device (aarch64)
┌──────────────────────────────┤ DietPi-Config ├───────────────────────────────┐
│ │
│ Would you like to purge all WiFi related APT packages? │
│ │
│ This will free up space, but an internet-capable Ethernet connection is │
│ required to re-enable WiFi functionality. │
│ │
│ Affected packages: iw wireless-tools crda wireless-regdb wpasupplicant │
│ │
│ <Ok> <Skip> │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
[ INFO ] DietPi-Config | APT purge for: iw wireless-tools crda wireless-regdb wp asupplicant, please wait...
[ INFO ] DietPi-Config | None of the requested packages are currently installed. Aborting...
[ OK ] DietPi-Config | APT purge for: iw wireless-tools crda wireless-regdb wp asupplicant
[ INFO ] DietPi-Config | Dropping network connections, please wait...
[ INFO ] DietPi-Config | Restarting network connections, please wait...
[ OK ] DietPi-Config | systemctl daemon-reload
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/
Listening on LPF/eth0/f0:ad:4e:08:00:00
Sending on LPF/eth0/f0:ad:4e:08:00:00
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 16
No DHCPOFFERS received.
No working leases in persistent database - sleeping.
[ SUB2 ] DietPi-Services > start
[ INFO ] DietPi-Services | skip : cron (due to mask)
[ INFO ] DietPi-Config | Reloading networking data, please wait...
[ OK ] DietPi-Config | Network restarted
Generic Device (aarch64)
┌──────────────────────────────┤ DietPi-Config ├───────────────────────────────┐
│ Ethernet Details: │
│ Usage : Sent = 0 MiB | Recieved = N/A │
│ Address : IP = 0.0.0.0 | Mask = 0.0.0.0 | Gateway = 0.0.0.0 | DNS = 9.9.9.9 │
│ │
│ ●─ DHCP/STATIC IP ──────────────────────● │
│ Change Mode : [DHCP] │
│ ●─ Additional Options ──────────────────● │
│ Link Speed : [auto (default)] │
│ Disable : Disable Ethernet adapter │
│ ●─ Apply ───────────────────────────────● │
│ Apply : Save all changes and restart networking │
│ │
│ │
│ <Ok> <Back> │
│ │
└──────────────────────────────────────────────────────────────────────────────┘
If the Ethernet port shall be configured automatically at boot, the #allow-hotplug eth0
line needs to be uncommended allow-hotplug eth0
. However, the issue is the same, no answer on DHCP requests.
But just to be sure, regarding Armbian, since I couldn't find any recent topic on their forum for Espressobin or mvebu64, this broke Ethernet on Armbian as well?
apt update
apt full-upgrade
reboot
Because then we don't need to continue debugging, because it's a kernel bug then.
EDIT: Btw, serial console naming scheme added: https://github.com/MichaIng/DietPi/commit/77c63d2
ok thanks
Did you solve the network issue?
Did you solve the network issue?
No, I really can't find a solution...
On the armbian, I can use systemctl unmask systemd networked&&systemctl enable systemd networked&&systemctl start systemd networked
to enable the network and run normally,This is confirmed by armbian,‘Network problem is known’
But I don't know how to operate on dietpi...
As said, DietPi does not ship with a systemd-networkd
config, but ifupdown and /etc/network/interfaces
instead. However, it could be tested. For this, disable Ethernet via dietpi-config
, then:
echo -e '[Match]\nName=eth0\n\n[Network]\nDHCP=ipv4' > /etc/systemd/network/eth0.network
systemctl enable --now systemd-networkd
@MichaIng It seems that there is still a problem with the network..
root@DietPi:~# cat /etc/systemd/network/eth0.network
[Match]
Name=eth0
[Network]
DHCP=ipv4
root@DietPi:~# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1024
link/ether f0:ad:4e:08:00:00 brd ff:ff:ff:ff:ff:ff
inet6 fe80::f2ad:4eff:fe08:0/64 scope link
valid_lft forever preferred_lft forever
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether a6:57:0c:2e:18:ce brd ff:ff:ff:ff:ff:ff
inet6 fe80::a457:cff:fe2e:18ce/64 scope link
valid_lft forever preferred_lft forever
root@DietPi:~# cat /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 dhcp
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
#dns-nameservers 9.9.9.9
# WiFi
#allow-hotplug wlan0
iface wlan0 inet dhcp
address 192.168.0.100
netmask 255.255.255.0
gateway 192.168.0.1
#dns-nameservers 9.9.9.9
wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf
Is this bridge there intentionally?
What does the service say?
journalctl -u systemd-networkd
root@DietPi:~# journalctl -u systemd-networkd -- Journal begins at Sat 2022-12-03 20:05:23 GMT, ends at Sat 2022-12-03 20:14:26 GMT. -- Dec 03 20:07:26 DietPi systemd[1]: Stopping Network Service... Dec 03 20:07:26 DietPi systemd-networkd[682]: eth0: DHCPv6 lease lost Dec 03 20:07:26 DietPi systemd-networkd[682]: br0: DHCPv6 lease lost Dec 03 20:07:26 DietPi systemd[1]: systemd-networkd.service: Succeeded. Dec 03 20:07:26 DietPi systemd[1]: Stopped Network Service. Dec 03 20:07:26 DietPi systemd[1]: Starting Network Service... Dec 03 20:07:26 DietPi systemd-networkd[24572]: br0: netdev ready Dec 03 20:07:26 DietPi systemd-networkd[24572]: br0: Gained IPv6LL Dec 03 20:07:26 DietPi systemd-networkd[24572]: eth0: Gained IPv6LL Dec 03 20:07:26 DietPi systemd-networkd[24572]: Enumeration completed Dec 03 20:07:26 DietPi systemd[1]: Started Network Service. Dec 03 20:07:26 DietPi systemd-networkd[24572]: br0: netdev exists, using existing without changing its parameters
bullseye with Armbian Linux SBC device | Generic Device (aarch64) Power supply used | 5V 2A RAVpower SDcard used | SanDisk ultra)
when compiling the arm64 image device use #make-your-own-distribution https://dietpi.com/docs/hardware/#make-your-own-distribution
After I successfully compiled step by step, I pretended to be dead when I entered the system interface after restarting. There was no response. The computer could not be found on the network. I could not enter the system in any way. There was no response!
Output information of reboot:
One year ago, I compiled with reference to the old build link and started to enter the system normally~