Long boot time on f32

im having an issue where fedora 32 is taking a long time to boot. here is some data:

[mike@fedora ~]$ systemd-analyze
Startup finished in 23.518s (firmware) + 2.630s (loader) + 1.108s (kernel) + 1min 6.741s (initrd) + 12.135s (userspace) = 1min 46.135s
graphical.target reached after 12.116s in userspace

[mike@fedora ~]$ systemd-analyze blame | head
1min 5.915s dracut-initqueue.service
7.557s dkms.service
6.415s NetworkManager-wait-online.service
3.752s lvm2-monitor.service
1.081s akmods.service
852ms firewalld.service
772ms udisks2.service
478ms initrd-switch-root.service
470ms systemd-homed.service
444ms systemd-machined.service

[mike@fedora ~]$ systemd-analyze critical-chain
The time when unit became active or started is printed after the “@” character.
The time the unit took to start is printed after the “+” character.

graphical.target @12.116s
└─multi-user.target @12.116s
└─dkms.service @4.558s +7.557s
└─basic.target @4.551s
└─dbus-broker.service @4.596s +172ms
└─dbus.socket @4.546s
└─sysinit.target @4.540s
└─systemd-update-utmp.service @4.492s +47ms
└─auditd.service @4.448s +43ms
└─systemd-tmpfiles-setup.service @4.325s +119ms
└─import-state.service @4.291s +33ms
└─local-fs.target @4.288s
└─home.mount @4.246s +42ms
└─systemd-fsck@dev-disk-by\x2duuid-9c71f78e\x2d3a55\x2d4469\x2d934e\x2de7af47b7fd9>
└─local-fs-pre.target @4.119s
└─lvm2-monitor.service @366ms +3.752s
└─dm-event.socket @360ms
└─system.slice
└─-.slice

i have tried systemctl mask systemd-udev-settle and oleastre’s systemd patch to no avail. any tips on how to troubleshoot and solve this issue?

1 Like

[root@victory simmon]# systemd-analyze
Startup finished in 3.618s (kernel) + 5.265s (initrd) + 12.327s (userspace) = 21.212s
graphical.target reached after 12.290s in userspace

If unnecessary services and daemons are provided, it can be configured to boot faster. I think the f32 boot has good responsiveness even on older devices.

That’s definitely not OK, everything else looks normal. Seems likely that this is the same issue as in the bug you referenced. Did you get the patched systemd via the COPR repo?

1 Like

yes, ive tried that copr systemd patch and systemctl mask systemd-udev-settle to fix the dracut issue but nothing made any difference. is there anything else to try or should i just follow that bug report? i have separate / and /home partitions so a reformat wont be that bad, just would like to avoid if possible

Please, collect diagnostic data:

sudo vgs; sudo pvs; sudo lvs
lsblk -o NAME,SIZE,RO,TYPE,FSTYPE,MOUNTPOINT,UUID
grep -v -e ^# -e ^$ /etc/fstab
cat /etc/default/grub
systemctl --failed

Please don’t hijack somebody else’s thread, @tachi. Instead, search the board for the many other threads on this subject and see if you can get help from them. If not, open a new thread of your own.

Excuse me??? I just pointed out to a thread with a similar, if not same problem.
You can choose to benefit from it, or to ignore it!

Most of your post was asking for help with your machine, which is considered to be hijacking. If you need help with your box, you’re much more likely to get it if you start your own thread.

https://pastebin.com/7PQ1HsZK

1 Like

It seems you have no LVM, however it is still enabled via the default preset.

You can disable those units and try to use the factory defaults:

sudo mkdir -p /etc/systemd/system-preset
sudo tee /etc/systemd/system-preset/00-custom.preset << EOF
disable lvm2-monitor.*
disable lvm2-lvmetad.*
disable lvm2-lvmpolld.*
EOF
sudo systemctl preset-all

so i dont know how these are related, but disk sdc is a debian sid installation. when these packages were updated, the boot time became normal:

intel-media-va-driver:amd64; intel-media-va-driver:i386

is there any way to proceed from here re:fedora bug reports or is it safe to say that the sid installation will throw these errors from time to time? if the entire disk is removed, the error doesnt occur. but since those intel packages were upgraded, it went away even with the disks connected. can i submit anything for the fedora community here or just call it a random occurrence and move along?

I’ve got the exact same problem.
I’ve added a SSD to my computer and I’ve installed Fedora 32. But I find that the boot time is almost longer than the one of Fedora 30 on my HDD.
I’ve already masked plymouth-quit-wait.service, NetworkManager-wait-online.service and systemd-udev-settle.service.
My main problem comes from dracut-initqueue.service:

[fedoski@fixe ~]$ systemd-analyze blame 
32.254s dracut-initqueue.service                           
 2.230s udisks2.service                                    
 1.954s lvm2-pvscan@8:36.service                           
  885ms upower.service                                     
  602ms dmraid-activation.service                          
  594ms systemd-logind.service                             
  490ms initrd-switch-root.service                         
  435ms firewalld.service                                  
  419ms systemd-journal-flush.service                      
  368ms akmods.service                                     
  309ms user@1000.service                                  
  277ms systemd-userdbd.service                            
  266ms fwupd.service                                      
  257ms systemd-udevd.service                              
  247ms systemd-homed.service                              
  229ms systemd-machined.service                           
  217ms sssd.service               
...

I’ve got 2 HDDs and one SSD. My root, boot and swap partitions are on the SSD. My home partitions is on a HDD. And I’m also using parts of my old home that is on a LVM on the second HDD.
I’ve tried removing the LVM parts of fstab and masking lvm2-monitor.service but it didn’t changed anything.
Is it safe to use the copr patch?

Edit:
I’ve tried the version of systemd suggested and it was exactly the same.

Edit:
I’ve also tried the system-preset solution but it did not changed anything either.

Edit:
And for the intel-media-va-driver update, I’m using an amd processor (Ryzen 3600) with a Nvidia card (GTX 960). So i’s not the cause of the problem.

I’ve found the problem. It was due to my DVD drive. There was a pause during the boot:

juil. 22 12:20:33 localhost.localdomain kernel: r8169 0000:22:00.0 eth0: RTL8168h/8111h, 2c:f0:5d:26:e7:c5, XID 541, IRQ 69
juil. 22 12:20:33 localhost.localdomain kernel: r8169 0000:22:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
juil. 22 12:20:33 localhost.localdomain kernel: r8169 0000:22:00.0 enp34s0: renamed from eth0
juil. 22 12:20:33 localhost.localdomain systemd-udevd[549]: Using default interface naming scheme 'v240'.
juil. 22 12:21:04 localhost.localdomain kernel: ata15: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
juil. 22 12:21:05 localhost.localdomain kernel: ata15.00: configured for PIO4
juil. 22 12:21:06 localhost.localdomain dracut-initqueue[535]: Scanning devices sdc4  for LVM logical volumes linux/volfedora2 linux/volswap
juil. 22 12:21:06 localhost.localdomain dracut-initqueue[535]: inactive '/dev/linux/volhome' [<1.50 TiB] inherit

And when I checked:

[fedoski@fixe ~]$ journalctl -b | grep ata15
juil. 24 18:49:46 fixe kernel: ata15: SATA max UDMA/133 abar m2048@0xf7700000 port 0xf7700380 irq 48
juil. 24 18:49:46 fixe kernel: ata15: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
juil. 24 18:49:46 fixe kernel: ata15.00: ATAPI: TSSTcorp CDDVDW SH-S223C, SB06, max MWDMA2
juil. 24 18:49:46 fixe kernel: ata15.00: configured for PIO4
juil. 24 18:50:17 fixe kernel: ata15: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
juil. 24 18:50:18 fixe kernel: ata15.00: configured for PIO4
juil. 24 16:50:53 fixe kernel: ata15: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
juil. 24 16:50:54 fixe kernel: ata15.00: configured for PIO4

I found that it was linked to my DVD drive. I’ve unplugged it and I got this:

[fedoski@fixe ~]$ systemd-analyze 
Startup finished in 19.210s (firmware) + 3.184s (loader) + 2.441s (kernel) + 1.177s (initrd) + 12.931s (userspace) = 38.944s 
graphical.target reached after 12.780s in userspace

[fedoski@fixe ~]$ systemd-analyze blame
6.456s NetworkManager-wait-online.service                 
3.790s systemd-udev-settle.service                        
3.514s lvm2-monitor.service                               
1.674s lvm2-pvscan@8:36.service                           
1.336s udisks2.service                                    
1.322s smartd.service                                     
 822ms upower.service                                     
 653ms systemd-journal-flush.service                      
 547ms home-fedoski-nfs.mount                             
 493ms initrd-switch-root.service                         
 472ms systemd-logind.service                             
 466ms firewalld.service                                  
 458ms dracut-initqueue.service                    

I think that the time lost is because I’m using a NFS HDD and it takes some time to answer.
Anyway, my problem is solved.

Has anybody else with this issue been able to attribute it to F32? I’ve been on Fedora since release 17 or 18 and this is the first time this issue occurred.

Try to press Esc during the boot to find out which unit is delaying the progress.

I know which unit is delaying the boot process, and I’ve already removed Plymouth. It all happens at this point:

[    3.104375] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01)
[    3.123628] libphy: r8169: probed
[    3.124892] r8169 0000:22:00.0 eth0: RTL8168h/8111h, 2c:f0:5d:26:e7:c5, XID 541, IRQ 69
[    3.125881] r8169 0000:22:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]
[    3.134186] ccp 0000:28:00.1: enabling device (0000 -> 0002)
[    3.135269] ccp 0000:28:00.1: ccp: unable to access the device: you might be running a broken BIOS.
[    3.157940] r8169 0000:22:00.0 enp34s0: renamed from eth0
[   33.725560] ata15: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
[   34.529167] ata15.00: configured for PIO4
[   35.355335] audit: type=1130 audit(1595597093.247:6): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=dracut-initqueue comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   35.380033] audit: type=1130 audit(1595597093.272:7): pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=systemd-fsck-root comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[   35.386696] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)

And the ata15 corresponds to my dvd drive. I I unplug it, the pause during the boot process disappears.
I think that the systems tries to “discover” each sata drive, the DVD drive does not respond and there is a timeout:

juil. 24 18:45:17 fixe kernel: ata15: SATA max UDMA/133 abar m2048@0xf7700000 port 0xf7700380 irq 48
juil. 24 18:45:17 fixe kernel: ata15: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
juil. 24 18:45:17 fixe kernel: ata15.00: ATAPI: TSSTcorp CDDVDW SH-S223C, SB06, max MWDMA2
juil. 24 18:45:17 fixe kernel: ata15.00: configured for PIO4
juil. 24 18:45:48 fixe kernel: ata15: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
juil. 24 18:45:49 fixe kernel: ata15.00: configured for PIO4
juil. 24 16:46:24 fixe kernel: ata15: SATA link up 1.5 Gbps (SStatus 113 SControl 300)
juil. 24 16:46:25 fixe kernel: ata15.00: configured for PIO4

We can see that there is a 30 second gap during the process. If I compare it with one of my HDD, we can see that there is no gap:

juil. 24 18:45:17 fixe kernel: ata1: SATA max UDMA/133 abar m131072@0xf7680000 port 0xf7680100 irq 39
juil. 24 18:45:17 fixe kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
juil. 24 18:45:17 fixe kernel: ata1.00: ATA-8: TOSHIBA HDWD130, MX6OACF0, max UDMA/133
juil. 24 18:45:17 fixe kernel: ata1.00: 5860533168 sectors, multi 16: LBA48 NCQ (depth 32), AA
juil. 24 18:45:17 fixe kernel: ata1.00: configured for UDMA/133

It’s strange that the last 2 lines are repeated 3 times for the DVD drive, each time with 30s between each.

And I’ve checked, I had the same thing with Fedora 30, so it’s not a new problem.

sudo dracut -f --regenerate-all

Did you run this?

I already did this. And my problem was already in Fedora 30. The problem is not due to dracut, but more about the way my dvd drive is reponding (or not) to the messages sent during boot. I just need to find how to decrease this timeout duration, or to tell the initrd not to care about the dvd drive.