Boot stalls at "A start job is running for Network Name Resolution"

nightfury · 2024-05-23 07:47:17

Some of the time when i boot my arch it the boot seems to stall at A start job is running for Network Name Resolution, and it was stuck there for more than 15 min and time kept increasing. This has happened for quite a few times now, but as soon as i boot into linux fallback i am able to boot into my system and after that i can boot to again normally after a reboot. But after i shutdown my pc and turn it on again it randomly stalls the boot again. I don't know what's stopping it, i am not able to get hold of the problem overall can somebody help me as i don't know about it all and can't get enough information about it over the web. Thank You
Also i am not sure of whether to post it in Network, Server and Protection or not so if i posted it in wrong place do correct me.

yoshi314 · 2024-05-24 04:45:35

just confirming that i am hitting the very same problem.

yoshi314 · 2024-05-24 06:48:51

FYI boting with "recovery" parameter seems to work every time. And it doesn't drop into recovery shell.

evil.genius · 2024-05-24 07:21:54

I have the same problem.

Musheer360 · 2024-05-24 11:50:59

I am having the same problem after the kernel update.

seth · 2024-05-24 15:29:05

If any of you uses the r8168 package, it got dropped into the AUR therefore not updated, so you end up w/ a dated r8168 package that blacklists the r8169 driver.

Otherwise we'll need to see a journal of a boot into the rescue target (and ideally attempting to start the network from there)

bioxz · 2024-05-25 09:40:20

I ran into the same issues. It is not 100% reproducible for me, sometimes it boots, most times it gets stuck with that name resolution service not starting. Only way is a hard reboot (e.g. reboot button), as a soft reboot (Ctrl + Alt + Del) still waits for that service to start indefinitely. If the system goes past that point, it boots without issues, thus my current workaround is to press the reboot button on my case until the boot goes through.

bioxz@funi ~ % lsmod|grep r81                          
r8169                 147456  0
mdio_devres            12288  1 r8169
libphy                253952  3 r8169,mdio_devres,realtek

@seth: What kind of journal would help? I have a systemd journal for a failed boot and one for the following successful boot. Sadly the log of the failed boot does not even include the "Starting Network Name Resolution..." part, it already stops earlier.

This is the failed boot (journalctl --boot -1): https://pastebin.com/XNPMpiRV
This is the successful, current boot (journalctl --boot 0): https://pastebin.com/LfzSkg6j (cut off after Reached target Basic System., let me know if anything later is needed)

EndUserOnly · 2024-05-25 13:01:44

Same here, after kernel update. No idea where it is hung at, I just reloaded a backup. After reloading the backup I updated AUR, but not regular system. My system actually hung while in use, after the updates. I rebooted and it hung on startup.

I have not used r8168 in ages. Not since I switched to Toshiba Satellite. I remember using it a long time ago on Debian/HP.
Not using dual boot either.

Last edited by EndUserOnly (2024-05-26 13:05:29)

seth · 2024-05-25 15:06:53

@bioxz, there's some bogus USB device on an alcor hub

Mai 25 10:51:14 funi kernel: usb 9-1.2.4: new full-speed USB device number 5 using xhci_hcd
Mai 25 10:51:14 funi kernel: usb 9-1.2.4: New USB device found, idVendor=058f, idProduct=9254, bcdDevice= 3.12
Mai 25 10:51:14 funi kernel: usb 9-1.2.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Mai 25 10:51:14 funi kernel: usb 9-1.2.4: Product: Generic USB Hub
Mai 25 10:51:14 funi kernel: usb 9-1.2.4: Manufacturer: ALCOR
Mai 25 10:51:14 funi kernel: hub 9-1.2.4:1.0: USB hub found
Mai 25 10:51:14 funi kernel: hub 9-1.2.4:1.0: 4 ports detected
Mai 25 10:51:14 funi kernel: usb 9-1.2.4.2: new full-speed USB device number 7 using xhci_hcd
Mai 25 10:51:14 funi kernel: usb 9-1.2.4.2: device descriptor read/64, error -32
Mai 25 10:51:14 funi kernel: usb 9-1.2.4.2: device descriptor read/64, error -32
Mai 25 10:51:14 funi kernel: usb 9-1.2.4.2: new full-speed USB device number 8 using xhci_hcd
Mai 25 10:51:14 funi kernel: usb 9-1.2.4.2: device descriptor read/64, error -32
Mai 25 10:51:14 funi kernel: usb 9-1.2.4.2: device descriptor read/64, error -32
Mai 25 10:51:14 funi kernel: usb 9-1.2.4-port2: attempt power cycle
Mai 25 10:51:14 funi kernel: usb 9-1.2.4.2: new full-speed USB device number 9 using xhci_hcd
Mai 25 10:51:14 funi kernel: usb 9-1.2.4.2: Device not responding to setup address.
Mai 25 10:51:14 funi kernel: usb 9-1.2.4.2: Device not responding to setup address.

Looks like it's

Mai 25 10:52:00 funi kernel: usb 9-1.2.4.2: Product: SteelSeries Arctis 9
Mai 25 10:52:00 funi kernel: usb 9-1.2.4.2: Manufacturer: SteelSeries

The journal doesn't extend much past the root switch, did you reboot w/ the power button?
Does https://wiki.archlinux.org/title/Keyboa … el_(SysRq) work (nb. that you have to actively enable that w/ eg. the kernel parameter!)

EndUserOnly wrote:

Same here, after kernel update.

seth wrote:

…r8168…?

libertepourmoi · 2024-05-25 16:15:59

I am having the same issue.

Startup only reliably works right now if I boot my fallback initrd. After a successful boot up using this, I can once start using the normal one, but subsequently it will stall again, with "A start job is running...", like for OP.

Here is the log of a stalled boot that I interrupted with REISUB: http://0x0.st/XZ32.txt

And here is a successful on one: http://0x0.st/XZ3L.txt

And this is from booting fallback initrd, which I have always set to just boot into multi-user.target: http://0x0.st/XZ3f.txt

The system is up to date. I am not using r8168, never have, but maybe I could, not sure. My system uses r8169, as you can see in the log.

seth · 2024-05-25 16:37:54

Different chip from #7 but the common pattern is that systemd-networkd doesn't get an r8169 driven NIC up.
For both the r8169 module load late, what if you add it to the initramfs?

libertepourmoi · 2024-05-25 16:46:31

seth wrote:

For both the r8169 module load late, what if you add it to the initramfs?

Good call, that works for me. Thanks Seth!

That's an acceptable workaround for me but I am still curious what causes this. It's a regression for, the exact same setup has been working for a few years now.

seth · 2024-05-25 16:51:45

There's a loing standing, somewhat similar situation around https://wiki.archlinux.org/title/Kernel … _KMS_start because systemd just starts the graphical.target regardless of whether the hardware is actually setup.

If/since you're using a wired chip, what if you replace systemd-networkd w/ dhcpcd?

Edit: sanity check - is anyone here dual booting windows?

Last edited by seth (2024-05-25 16:55:59)

libertepourmoi · 2024-05-25 17:34:21

seth wrote:

Edit: sanity check - is anyone here dual booting windows?

Not me, Arch only here. But that's why I was a bit surprised to see such a pattern where the previous boot would play a role in whether or not normal booting up would work.

Also, replacing systemd-networkd with dhcpcd (and yes, I moved the r8169 module back out of initramfs for this) does work as well. That seems to point at systemd-networkd as the problem here.

When writing this now I remember how the issue appeared some days ago, but in fact it did coincide with updating the system and that included an update of systemd. And the symptoms started with the first boot after that.

Gosi · 2024-05-25 20:15:39

If it only happens rarely, you can also try this workaround:

Hit <Ctrl><Alt><Del> 7 times within 2s to trigger a forced reboot.
Now systemd will wait for the reboot watchdog to expire.

You have to set RebootWatchdogSec in /etc/systemd/system.conf to something sensible (default is 10min) .

EndUserOnly · 2024-05-26 13:16:02

Not using r8168/9. Not using dual boot.

seth · 2024-05-26 13:32:22

But systemd-networkd?
Tried to replace that w/ dhcpcd or move the NIC driver into the initramfs (as for libertepourmoi it's clearly a race condition in systemd-networkd)

EndUserOnly · 2024-05-26 16:58:04

My problem is apparently of a different nature. I duplicated problem to collect the debug data. I get 2 steps: 1)Loading Linux Hardened 2) Loading initial ramdisk. Step one completes. Step two hangs. It has to be before everything because I cannot boot into single-user mode, either. Definitely a result of the upgrades because reloading a backup works every time. Feels like that virus from a while back. Fortunately, I have a backup.

Last edited by EndUserOnly (2024-05-26 16:59:50)

loqs · 2024-05-26 17:17:38

@EndUserOnly is your issue limited to the hardened kernel?

EndUserOnly · 2024-05-26 18:14:10

Good question, my bad. I checked both kernels. Same result.

I should also mention that I had a dependency problem that killed the upgrade entirely. To bypass, and get the upgrade to prompt me to continue, I had to place the package 'icu' on hold.

Last edited by EndUserOnly (2024-05-26 18:40:33)

seth · 2024-05-26 21:15:06

To bypass, and get the upgrade to prompt me to continue, I had to place the package 'icu' on hold.

https://bbs.archlinux.org/viewtopic.php?id=296001
That's a really bad idea and almost guaranteed to break higher boot levels (most graphical targets for sure and I'd not hope for the multi-user.target either)

You're also running into issues w/ stale electron versions?

EndUserOnly · 2024-05-26 21:43:21

Okay, well that fixes my problem because until somebody fixes the dependency break I get no updates. What do you see as a solution to a broken dependency? I typically wait until somebody fixes it. Lately that has been taking weeks, not days. I do not like, not updating my system as a solution.

seth · 2024-05-26 21:47:42

What *is* the "dependency break" specifically?
Because most likely it's in the AUR and the options are
1) drop the dependent package if you don't actually need it
2) rebuild it (which for electron is gonna take some time and CPU)

EndUserOnly · 2024-05-26 21:57:52

AUR is updating just fine. I use (paru -Sua) it only updates AUR. Aur is not broken. In the past several weeks I have had several broken dependency's. They clear-up on their own. We do not need to continue this. I do not have to worry about my system hanging because I will get no updates until somebody fixes icu. Last week the broken dependency was different. I will work it from a different angle. Thanks.

loqs · 2024-05-26 22:00:29

EndUserOnly wrote:

I do not have to worry about my system hanging because I will get no updates until somebody fixes icu.

Which package in the official repositories is not using the current icu package?
Edit:

sogrep all libicudata.so.74
sogrep all libicui18n.so.74
sogrep all libicuio.so.74
sogrep all libicutest.so.74
sogrep all libicutu.so.74
sogrep all libicuuc.so.74

Returns no matches.

Last edited by loqs (2024-05-26 22:06:00)

Arch Linux

#1 2024-05-23 07:47:17

Boot stalls at "A start job is running for Network Name Resolution"

#2 2024-05-24 04:45:35

Re: Boot stalls at "A start job is running for Network Name Resolution"

#3 2024-05-24 06:48:51

Re: Boot stalls at "A start job is running for Network Name Resolution"

#4 2024-05-24 07:21:54

Re: Boot stalls at "A start job is running for Network Name Resolution"

#5 2024-05-24 11:50:59

Re: Boot stalls at "A start job is running for Network Name Resolution"

#6 2024-05-24 15:29:05

Re: Boot stalls at "A start job is running for Network Name Resolution"

#7 2024-05-25 09:40:20

Re: Boot stalls at "A start job is running for Network Name Resolution"

#8 2024-05-25 13:01:44

Re: Boot stalls at "A start job is running for Network Name Resolution"

#9 2024-05-25 15:06:53

Re: Boot stalls at "A start job is running for Network Name Resolution"

#10 2024-05-25 16:15:59

Re: Boot stalls at "A start job is running for Network Name Resolution"

#11 2024-05-25 16:37:54

Re: Boot stalls at "A start job is running for Network Name Resolution"

#12 2024-05-25 16:46:31

Re: Boot stalls at "A start job is running for Network Name Resolution"

#13 2024-05-25 16:51:45

Re: Boot stalls at "A start job is running for Network Name Resolution"

#14 2024-05-25 17:34:21

Re: Boot stalls at "A start job is running for Network Name Resolution"

#15 2024-05-25 20:15:39

Re: Boot stalls at "A start job is running for Network Name Resolution"

#16 2024-05-26 13:16:02

Re: Boot stalls at "A start job is running for Network Name Resolution"

#17 2024-05-26 13:32:22

Re: Boot stalls at "A start job is running for Network Name Resolution"

#18 2024-05-26 16:58:04

Re: Boot stalls at "A start job is running for Network Name Resolution"

#19 2024-05-26 17:17:38

Re: Boot stalls at "A start job is running for Network Name Resolution"

#20 2024-05-26 18:14:10

Re: Boot stalls at "A start job is running for Network Name Resolution"

#21 2024-05-26 21:15:06

Re: Boot stalls at "A start job is running for Network Name Resolution"

#22 2024-05-26 21:43:21

Re: Boot stalls at "A start job is running for Network Name Resolution"

#23 2024-05-26 21:47:42

Re: Boot stalls at "A start job is running for Network Name Resolution"

#24 2024-05-26 21:57:52

Re: Boot stalls at "A start job is running for Network Name Resolution"

#25 2024-05-26 22:00:29

Re: Boot stalls at "A start job is running for Network Name Resolution"

Board footer