I have just upgraded to Sylvia (18.3). And I have started experiencing extremely slow boot times : >5min. I have tried searching and google-ing, however yet without success.
I see the problem -I think- but have not been able to find a solution. I have followed some earlier instructions:
[ 24.874637] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[ 24.874640] Bluetooth: BNEP filters: protocol multicast
[ 24.874644] Bluetooth: BNEP socket layer initialized
[ 29.107223] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 29.110389] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 327.777242] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 335.816325] ACPI Warning: \_SB_.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20150930/nsarguments-95)
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason:Topic automatically closed 6 months after creation. New replies are no longer allowed.
The networking services takes 5 min and 8 seconds.
I have made a workaround, however I do not think this is a proper solution.
I have set in /lib/systemd/system/networking.service
The TimeOut from 5 min to: TimeoutStartSec=10sec.
In contrast I do not experience any networking(wifi or eth) problems.
...if NetworkManager-wait-online.service is the culprit taking ages (according to systemd-analyze blame), you could try masking it's service...and usually this doesn't have any ill side-effects... sudo systemctl mask NetworkManager-wait-online.service
...also, from the snippet that you posted above, if the problem somehow is due to IPv6, you could try disabling such for your connection under NetworkManager...
Or else, in a more drastic manner, gksudo xed /etc/default/grub....change as: GRUB_CMDLINE_LINUX_DEFAULT="ipv6.disable=1 quiet splash"...save, then sudo update-grub, and IPv6 will be completely disabled...
Unfortunately, none of the mentioned solutions helped the booting process. I played around with it. And whatever the Timeout period it always waits for that then continues.
Just a thought. If you have a swap partition, is it being mounted at boot? Sometimes a slow boot can be due to unmatched UUID for the actual swap partition on disk and the one specified in /etc/fstab. In order to exclude this possibility you could run a check:
I have a swap partition. I am fairly new to linux so I can not really answer the question with confidence if that is mounted @boot. Now I did the recommended check and there seems to be an error, I show the results: device fs_type label mount point UUID
----------------------------------------------------------------------------------
/dev/sda1 ntfs System Reserved (not mounted) DA2AD5452AD51F77
/dev/sda2 ntfs (not mounted) 8C3221E93221D94A
/dev/sda3 ntfs Data (not mounted) 04DC39D4DC39C0AA
/dev/sda5 ext4 / 38c0c22d-0468-43fa-a1c9-9ed7d780470c
/dev/sda6 swap [SWAP] 921a5b2f-b8fe-4170-aa4f-4d48a3b25935
and in /etc/fstab:
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/sda5 during installation
UUID=38c0c22d-0468-43fa-a1c9-9ed7d780470c / ext4 errors=remount-ro 0 1
# swap was on /dev/sda6 during installation
UUID=921a5b2f-b8fe-4170-aa4f-4d48a3b25935 none swap sw 0 0
Thanks for posting the outputs.
They look ok. If I am not mistaken, errors=remount-ro , means basically that if there are any errors when mounting the root partition it will be mounted "read-only" and not "read-write". We can very well rule out the possibility of a "misplaced" swap.
