You are not logged in.
Hi folks, I've searched but come up blank on this one...
I've just migrated fully to systemd and all's working well apart from my boot hanging for around 16 seconds on fsck. Disabling the checks via the final column of fstab reduces my boot to under 9 seconds, which is roughly what it was with initscripts. Boot drive's an SSD, all other partitions on 2 SATA HDDs.
Here are the relevant parts of fstab
# /dev/sda3 - Backup
# ========= ------
UUID=7e23c7f4-acf6-477c-9705-15ae8870181e /media/Backup ext4 defaults 0 2
#
# /dev/sdb2 - ROOT (+/home)
# ========= ------------
UUID=ee99e089-a642-41c8-b1f4-5dc80307d438 / ext4 defaults,noatime,discard 0 1
#
# /dev/sdc1 - Data
# ========= ----
UUID=66c7a8dd-8d92-4353-a4eb-1da425449322 /media/Data ext4 defaults 0 2
#
# /dev/sdc2 - Scratch
# ========= -------
UUID=a8ca4753-ccca-4360-b702-8c12004bf8f8 /media/Scratch ext4 defaults,noatime 0 2
#
# /dev/sdc4 - bootISOs
# ========= --------
UUID=eea21a23-b3fa-479d-8a62-2502f4f9edfc /media/bootISOs ext4 defaults,noatime 0 2
I do have /var on the "Data" partition and a few other relocations...
/media/Data/var /var none bind 0 0
/media/Data/logs /home/paul/.logs none bind 0 0
tmpfs /home/paul/.thumbnails tmpfs nodev,nosuid,noatime 0 0
tmpfs /home/paul/.Skype/Logs tmpfs nodev,nosuid,noatime 0 0
tmpfs /media/Data/wine/drive_c/windows/temp tmpfs nodev,nosuid,noatime 0 0
Without fsck
$ systemd-analyze
Startup finished in 1280ms (kernel) + 2220ms (initramfs) + 5112ms (userspace) = 8614ms
With fsck (typical)
$ systemd-analyze
Startup finished in 1276ms (kernel) + 3224ms (initramfs) + 20327ms (userspace) = 24829ms
Any ideas as to the slowdown or is this to be expected with this many partitions?
Thanks.
Last edited by fabertawe (2012-09-06 17:48:57)
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
I'd say that initscripts ignore the sixth field (I've always had 0 there in my fstabs; both with initscripts and systemd my filesystems are checked when fsck is forced, they haven't been unmounted cleanly or days or mounts reach a set number, in case of ext). Perhaps those 1s and 2s make systemd run a forced fsck. You should see in journalctl if fsck is checking the filesystems or just reporting them as clean. You can also look at https://wiki.archlinux.org/index.php/Systemd#Automount
-edit-
Actually, my main filesystems have 1 in fstab. Well, see what you see in journalctl.
Last edited by lucke (2012-09-05 18:11:26)
Offline
Thanks for the feedback. I read somewhere that systemd honours the fstab but I just assumed it was in regards to fscking as normal or not at all.
As for journalctl, all I'm seeing are entries like this - "systemd-fsck[239]: Data: clean, 51550/17694720 files, 13102073/70778880 blocks". From what I've gathered elsewhere systemd-fsck has no progress indicator so I don't know what should be logged for a full check anyway. Someone please correct me if that's wrong though.
I'll force a fsck tomorrow when I've got more time and see what's reported.
Cheers.
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
Exactly the same problem here, systemd is running fsck on every boot, but reporting it as clean - xfs
Offline
systemd-fsck on ext4 reports "clean" when fsck didn't check the filesystem, and shows the fragmentation ("X% non-contiguous") when it did.
Offline
systemd-fsck on ext4 reports "clean" when fsck didn't check the filesystem, and shows the fragmentation ("X% non-contiguous") when it did.
Well, that it's certainly interesting that it spends around 3sec. on fsck on my system.
Offline
Well... 'tune2fs -l | grep "ount count"' was showing all my partitions bar the boot drive had a maximum mount count of -1, therefore disabling fsck presumably. I reset all these to values under the actual mount counts and all the partitions were fscked on a reboot. There IS a progress indicator and it's recorded in the journal to this effect - "systemd-fsck[234]: Data has been mounted 59 times without being checked, check forced".
So back to my original (and still current) problem, that the boot sequence is stalling for around 16 seconds on the fsck check when no actual check is being carried out. Will keep investigating.
Edit: btw, all my partitions are ext4
Last edited by fabertawe (2012-09-06 08:34:01)
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
You can try to mask "systemd-fsck-root.service" . Then your root shouldn't be checked...
This is not a very good thing, but may be it can help you.
Offline
Root being checked isn't the problem, it's the other partitions that cause the delay. I'm still wondering if it's something to do with having /var on the "Data" partition.
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline
You can add "noauto,x-systemd.automount" to the options of non-essential partitions. That may speed up your boot time.
Sakura:-
Mobo: MSI MAG X570S TORPEDO MAX // Processor: AMD Ryzen 9 5950X @4.9GHz // GFX: AMD Radeon RX 5700 XT // RAM: 32GB (4x 8GB) Corsair DDR4 (@ 3000MHz) // Storage: 1x 3TB HDD, 6x 1TB SSD, 2x 120GB SSD, 1x 275GB M2 SSD
Making lemonade from lemons since 2015.
Offline
You can add "noauto,x-systemd.automount" to the options of non-essential partitions. That may speed up your boot time.
Sorry, I should have mentioned I already tried this with the "Data" partition and just got a permanent hang in the boot sequence.
Edit: I've had 2 boots where it's not had the delay but I've no idea why, nothing was changed.
Edit2: Seems I was too quick to dismiss "noauto,x-systemd.automount"... I've applied it to all partitions except "Data" (and root, obviously) and now I'm consistently getting boot times under 9 seconds. Marking this thread as solved. Thanks to all who contributed
Last edited by fabertawe (2012-09-06 17:45:48)
Ryzen 9 5950X, X570S Aorus Pro AX, RX 6600, Arch x86_64
Offline