You are not logged in.
I've been waiting for the release of an "official" 5.2.x kernel for a week to see if I did something wrong. I normally compile my own kernel when a new release comes out, but when 5.2 came out, one of my systems would not connect to the network. After some tinkering I found that I needed to issue a "ip link set enp0s18 up" to get my network up. I resorted to an @reboot cron task so I wouldn't lose contact after a restart.
Here is some (hopefully relevant) info:
# lspci
00:00.0 Host bridge: VIA Technologies, Inc. P4M266 Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
00:0a.0 Communication controller: LSI Corporation LT WinModem (rev 02)
00:10.0 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller (rev 80)
00:10.1 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller (rev 80)
00:10.2 USB controller: VIA Technologies, Inc. VT82xx/62xx UHCI USB 1.1 Controller (rev 80)
00:10.3 USB controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 50)
00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102/VT6103 [Rhine-II] (rev 74)
01:00.0 VGA compatible controller: S3 Graphics Ltd. VT8375 [ProSavage8 KM266/KL266]
# lsmod
Module Size Used by
snd_wavefront 40960 0
ppdev 24576 0
snd_cs4236 36864 0
snd_wss_lib 32768 2 snd_cs4236,snd_wavefront
snd_opl3_lib 20480 2 snd_cs4236,snd_wavefront
mousedev 20480 1
snd_via82xx 32768 0
snd_ac97_codec 114688 1 snd_via82xx
snd_hwdep 16384 2 snd_opl3_lib,snd_wavefront
savagefb 36864 0
ac97_bus 16384 1 snd_ac97_codec
pcspkr 16384 0
snd_pcm 102400 4 snd_via82xx,snd_cs4236,snd_ac97_codec,snd_wss_lib
input_leds 16384 0
via_rhine 32768 0
vgastate 20480 1 savagefb
i2c_algo_bit 16384 1 savagefb
via_agp 16384 1
i2c_viapro 20480 0
fb_ddc 16384 1 savagefb
snd_timer 32768 3 snd_opl3_lib,snd_wss_lib,snd_pcm
agpgart 36864 1 via_agp
mii 16384 1 via_rhine
snd_mpu401 16384 0
snd_mpu401_uart 16384 4 snd_mpu401,snd_via82xx,snd_cs4236,snd_wavefront
ns558 16384 0
snd_rawmidi 32768 2 snd_mpu401_uart,snd_wavefront
evdev 20480 4
snd_seq_device 16384 2 snd_opl3_lib,snd_rawmidi
parport_pc 36864 0
gameport 16384 3 ns558,snd_via82xx
snd 73728 13 snd_mpu401,snd_hwdep,snd_via82xx,snd_cs4236,snd_opl3_lib,snd_ac97_codec,snd_timer,snd_mpu401_uart,snd_rawmidi,snd_wss_lib,snd_seq_device,snd_wavefront,snd_pcm
parport 49152 2 parport_pc,ppdev
soundcore 16384 1 snd
mac_hid 16384 0
sg 32768 0
crypto_user 16384 0
ip_tables 24576 0
x_tables 32768 1 ip_tables
ext4 602112 1
crc32c_generic 16384 1
crc16 16384 1 ext4
mbcache 16384 1 ext4
jbd2 106496 1 ext4
hid_generic 16384 0
usbhid 53248 0
hid 110592 2 hid_generic,usbhid
sr_mod 24576 0
cdrom 61440 1 sr_mod
sd_mod 45056 3
ata_generic 16384 0
pata_acpi 16384 0
pata_via 16384 2
libata 221184 3 pata_via,ata_generic,pata_acpi
uhci_hcd 45056 0
scsi_mod 196608 4 sd_mod,libata,sr_mod,sg
ehci_pci 20480 0
ehci_hcd 73728 1 ehci_pci
floppy 61440 0
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s18: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
link/ether 00:e0:4c:ce:85:f6 brd ff:ff:ff:ff:ff:ff
# ip addr
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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s18: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 00:e0:4c:ce:85:f6 brd ff:ff:ff:ff:ff:ff
As you can see, the Ethernet state is DOWN.
After I issue the "ip link set enp0s18 up", everything seems to be back.
# ip link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: enp0s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN mode DEFAULT group default qlen 1000
link/ether 00:e0:4c:ce:85:f6 brd ff:ff:ff:ff:ff:ff
# ip addr
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
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp0s18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UNKNOWN group default qlen 1000
link/ether 00:e0:4c:ce:85:f6 brd ff:ff:ff:ff:ff:ff
inet 192.168.69.11/24 brd 192.168.69.255 scope global enp0s18
valid_lft forever preferred_lft forever
inet6 2600:1700:1260:5b80::11/64 scope global tentative
valid_lft forever preferred_lft forever
inet6 fe80::2e0:4cff:fece:85f6/64 scope link tentative
valid_lft forever preferred_lft forever
Any suggestions? I don't see anything unusual in the logs or in dmesg.
Last edited by rossboulet (2019-08-04 19:05:06)
Offline
Can reproduce this. Quite annoying. I don't know if this is a kernel, a systemd-networkd or whatever bug..
systemctl status systemd-networkd says:
ens3: Could not bring up interface: Invalid argument
Offline
I feel this is a regression in systemd-networkd as it was causing issues every now and then:
Offline
I can confirm that downgrading the kernel to 5.1.16 "fixes" the issue.
(abaumann wonders what kernels are supported and tested with systemd)
Offline
Can reproduce this. Quite annoying. I don't know if this is a kernel, a systemd-networkd or whatever bug..
systemctl status systemd-networkd says:
ens3: Could not bring up interface: Invalid argument
I see the "Invalid argument" in 5.1.16 too, but the interface still comes up.
Offline
At first I was thinking it had something to do with the specific NIC in my machine, but the comments about systemd took my research in a new direction. If I enable dhcpcd, the network comes up without my cron job having to do it. My machine has a static address, so I had no need for dhcpcd before. I do see that a newer version of systemd (242.32-3) is in staging. The current production version is 242.29-1. Perhaps there is a fix for this behavior in the newer systemd.
Offline
Hmm, my systemctl status systemd-networkd says:
● systemd-networkd.service - Network Service
Loaded: loaded (/usr/lib/systemd/system/systemd-networkd.service; disabled; v>
Active: inactive (dead)
Dunno why it says disabled. I only updated today fwiw, so I'm actually still running the old 5.1.x kernel at present. I also see nothing in journalctl under any sensible unit names I can guess at, and netctl status looks good although it does say my logs have been rotated today, so that might explain some of this oddness.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
This is a bad bug. Now I know why my remote Arch 32 box did not come back up after the update I did a couple of days ago. Can somebody please post here when the bug is fixed as I won't bother driving over to it until then.
Offline
This is a bad bug. Now I know why my remote Arch 32 box did not come back up after the update I did a couple of days ago. Can somebody please post here when the bug is fixed as I won't bother driving over to it until then.
Not a fix, but I do have two workarounds:
1) create a cron entry for root (assuming you're running cron) that has "@reboot ip link set enpxxxxx up" where enpxxxx is the name of your interface
or
2) Even though you probably have a static IP address, enable dhcpcd:
# systemctl enable dhcpcd
# systemctl start dhcpcd
Either of these will bring the interface up at boot time.
Offline
FWIW, my EeePC901 seems to have come back with full networking today on the 5.2.1 kernel just fine. But I'm having a hard time debugging anything going on here, so I'm at a loss to say what's different here, other than me using the testing repos on top of the standard ones.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
Has this issue been fixed yet?
Offline
Not a fix, but I switched my system from using systemd-networkd to netctl and it seems to work fine with netctl
Offline
Ah, that might explain why I've not hit this problem yet. I just stuck with netctl from the default install. Since 5.2.1 I have seen the machine drop off the network a little more frequently (perhaps at DHCP renegotiation, I'll have to check), but at boot it's always there for me.
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
The problem is not in the kernel 5.2, systemd-network has a problem opening connections on networks which come down per default from the kernel.
For kernel 5.2.x you need systemd 242.84.
systemd got stuck in a unresolved dependency on libip4tc.so.0/libip4tc.so.2, so I had to force rebuild iptables.
I pushed i686 and pentium4 packages accordingly.
The i486 got stuck in 5.1.x, dunno why. Most likely the few build slaves are still building unnecesary things, so the linux
kernel and systemd fell behind.
Offline
FWIW, I think it's a good idea for everyone to set their signature to signify what architecture they're using to identify differences in configuration like this more quickly in these discussions. It's why I set my signature as I have at least. Signatures are on the 'personality' tab of your profile, and the option to hide them if people start abusing them is on 'display', but thus far they're mostly unused here I've noticed. There's no need for more than 1 line of signature really. Anyone else agree?
Architecture: pentium4, Testing repos: Yes, Hardware: EeePC 901+2GB RAM+OS half on the SD card.
Offline
As to the signature, I have multiple systems, so having the specifics in the signature isn't practical. And I usually try to reproduce the problem on other machines including a virtual machine before I post about it.
Offline
So, also my signature would be:
i486/i686/pentium4 on 15 systems.
:-)
Offline
Just tested and agree the new version of systemd and systemd-networkd (242.84) fixed the issue. However, I thing I may stick with netctl on my future installs. Marked as solved.
Last edited by rossboulet (2019-08-04 19:05:46)
Offline