On 2016-05-19 20:30, David C. Rankin wrote:
All,
A friend had a leap laptop that was stuck trying to boot and couldn't figure out why. Just 3-dots in a chevron toggling back and forth endlessly. He said it used to work and he liked the interface, but couldn't figure out why.
Cancelling the login graphics (not something the 1st time user was aware of) disclosed the problem
-- activating NFS (34m 58 sec no-limit)
WTF? 'no-limit'???
This poor guy had been trying to boot his laptop for the past day and a half. He said he had to pull the batter out to shut it down because he couldn't reboot and when he would try to boot again it would just get stuck....
I'm sure there was an easier way to fix the issue, but I just edited the grub2 kernel boot line to boot to run-level 1 equivalent, chrooted the system under /mnt, disabled NFS with systemctl and rebooted.
This time the laptop hung at the same spot with:
-- activating NFS_B (31 sec 1:36)
which thankfully timed out at 1:36 and completed the boot.
Obviously what happened is the guy had previously connected to a NAS box via NFS and the boot was attempting to reconnect, but what caused the timeout of 'no-limit' to be set for NFS, and why did disabling NFS in systemd cause NFS_B to attempt connection?? Is the 'no-limit' something that must be user set, or is this some default in leap?
Let me know your thoughts and whether this should be filed as a bug (it probably should), I can't think of any situation where you should have an indefinite timeout on a service activated during boot???
I suspect it's a systemd issue but I know next to nothing so I won't go any further than venturing that suggestion. Hopefully somebody else knows more. In the meantime if your friend wants to be able to boot, then add 'nofail' to the attributes in the fstab entry for NFS filesystems. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org