I can no longer boot my system because there is apparently a process running which requires waiting and this goes on indefinitely. The issue I believe has been caused by network connection but I cannot look until I get past this endless loop.
Please could you help me identify and kill the process so the boot may continue.
I am working on my laptop pending a solution!
Budge.
Hi
You need to press esc key and take a photo of what it’s waiting for, then can boot into single user mode(init=/bin/bash), or try the recovery boot option. I suspect a disk, maybe swap?
Hi Malcolm,
Whilst waiting I did some reading and believe the issue is partly due to Network Manager (NM) as I have just changed back to NM from wicked which I changed to in the first place because of this problem! I now suspect there are two distinct problems, one with my setup, my fault, and the other with NM.
The boot process is stalling in an endless loop due to two failures elsewhere in my system. The first is due to me not having set up the time server correctly and the second due to a firewall issue which is blocking an NFS which used to work.
The NM issue is a problem which does not occur with my Debian with KDE desktop system and consider there is a bug on the openSUSE system.
When I left click on the NM applet icon in openSUSE I am presented with two networks. Both are shown as Wired connection 1. One is shown as (eno1) and the second (enp0s26f1u2). As far as I know all connections should be listed but only one selected.
Having only one connection listed makes it difficult to select the right one when using the System Settings Module because only one is shown and the only way to find out which is being set is to select it for connection first. One connection doesn’t actually connect although selected.
If I use the System Settings Module, General configuration tab, I can select the “connect automatically button on connection” which works and ensure it is not selected on the other, but after a reboot I always get the wrong connection and the selection is changed.
On my Debian system with identical machine I can see three wired connections numbered 1,2 and 3. These are for 2 nics and the USB device and I can select and edit the requirements accordingly and these remain after a reboot. In fact the USB device defaults to un-selected. Bottom line, there is a bug in NM which is why I went to wicked in the first place.
Now what?
As far as I know, a NetworkManager problem should not hold up boot indefinitely, unless you have something else (such as a network share) that depends on the network.
Hi and you are correct it is not indefinite, just seems like it for impatient folk waiting to use their computer! The default is 10 minutes.
I believe the issue is linked to the way in which chronyd is set up. There is a timing function which waits for the synchronization of the time from ntp. The default wait period is set at 600 seconds. The problem is that if the synchronization fails, the wait lasts 10 minutes. This is set by the chrony-wait.service.
In my case the synchronisation fails so the system waits the full 10 minutes. I am now changing the default to 2 seconds using the editor thus:-
sudo systemctl edit --full chrony-wait.service
This problem does not occur with wicked but I need NM for VPN.
I shall post a new thread asking help with setting up the time on all the machines on my lan because I understand only one machine should be synced with the wan time server and the rest should be synced by the “master” on the lan. I may be wrong but if not done correctly the sync fails if margins between machines is too great.
Budge
There’s already a bug report regarding chrony…
Hi and many thanks for the link to the bug. I reached it the hard way and am surprised it has not yet been fixed.
I chose to change the wait to 2 seconds but on reflection I think should be disabled. Meanwhile I am still sorting out the clocks on my network so will leave for now.
A little knowledge is a dangerous thing and I have very little indeed.
I read the bug thread and am even less wise.
I tried setting chrony-wait.service to 2 seconds and got Failed.
I disabled and still get Failure.
My system is trying to boot with no network connection because there is a different bug in the NM applet/yast which means that even if the chrony-wait.service was working it couldn’t connect and therefore couldn’t sync.
Bugged off!
Budge
I didn’t plough through the entire report, and I’m not particularly familiar with chrony…
… but from a linked duplicate bug ( https://bugzilla.opensuse.org/show_bug.cgi?id=1160519#c3 ) it seems for the moment the “solution” is to disable the chrony-wait.service
# systemctl disable chrony-wait.service
Hi Paul,
Many thanks for this. I believe you are correct, particularly as the default is supposed to be disabled and only set when required.
I did have a wobble and tried to enable using the command:-
systemctl enable chrony-wait.service
Might be the wrong command as symlink was created and lots I didn’t understand but have left it disabled.
I believe chronyd is running anyhow and sync seems to be working once I have a network connection.
You can check if it’s active by using:
systemctl status chronyd
paul@HP255G7:~> systemctl status chronyd
● chronyd.service - NTP client/server
Loaded: loaded (/usr/lib/systemd/system/chronyd.service; enabled; vendor preset: disabled)
Active: active (running) since Sat 2020-10-03 16:05:58 BST; 11min ago
Docs: man:chronyd(8)
man:chrony.conf(5)
Process: 1215 ExecStartPost=/usr/lib/chrony/helper update-daemon (code=exited, status=0/SUCCESS)
Process: 1200 ExecStart=/usr/sbin/chronyd $OPTIONS (code=exited, status=0/SUCCESS)
Main PID: 1213 (chronyd)
Tasks: 1
CGroup: /system.slice/chronyd.service
└─1213 /usr/sbin/chronyd
Oct 03 16:05:58 HP255G7 systemd[1]: Starting NTP client/server...
Oct 03 16:05:58 HP255G7 chronyd[1213]: chronyd version 3.2 starting (+CMDMON +NTP +REFCLOCK +RTC +PRIVDROP -SCFILTER +SECHASH -SIGND +ASYNCDNS +IPV6 -DEBUG)
Oct 03 16:05:58 HP255G7 chronyd[1213]: Frequency -6.285 +/- 5.707 ppm read from /var/lib/chrony/drift
Oct 03 16:05:58 HP255G7 systemd[1]: Started NTP client/server.
Oct 03 16:06:12 HP255G7 chronyd[1213]: Selected source 217.114.59.3
Oct 03 16:10:42 HP255G7 chronyd[1213]: Source 85.199.214.101 replaced with 45.66.39.122
paul@HP255G7:~>