When doing a workstation install from the installation media, anaconda will only install dmraid and device-mapper-multipath if they are necessary for the installation. However when doing a livecd install, these are present on the livecd and their systemd services are enabled. These services both bring in the deprecated / legacy systemd-udev-settle.service. Together these slow-down the boot by about 4 seconds on my workstation (adding 4 seconds to what is normally a 14 second boot up time). So ideally anaconda would also do the reverse thing it does with normal installs (where it brings these in if necessary) and it would run a dnf remove in the chroot for these when not necessary. Alternatively anaconda could at least "systemd disable" them. Another alternative would be to make the services themselves smarter and make them be no-op's when they are not necessary: multipathd.service has: ConditionPathExists=/etc/multipath.conf But that does not stop systemd-udev-settle.service from getting dragged in, I guess the Wants are evaluated before the Conditions. An alternative solution to having anaconda disable (or dnf remove in the chroot) this would be to ask the systemd people if we can somehow fix this. dmraid is different though, that has no conditions and not only brings in the deprecated systemd-udev-settle.service but it also takes some time scanning the disks itself. I guess one solution there might be to have /lib/systemd/fedora-dmraid-activation write out a file when no dmraid sets are found and add something like: ConditionPathExists=!/var/lib/dmraid/no-dmraid-sets-found
p.s. See: https://ask.fedoraproject.org/t/disabling-plymouth-reduces-boot-time-by-50-percent/5160/9 for a list of services which gets run by systemd after a livecd install which do not get run on a regular install. This shows that 2 other services which should probably be disabled in the chroot are: livesys-late.service and livesys.service, these both show up in systemd-analyze as running (and delaying the boot) on the installed system.
Adding see also bugs for these units. I think Anaconda can start these units when it launches, but the vendor preset should be disabled. If users need them, they can enable them.
I thought dmraid was itself deprecated in favor of either mdadm or lvm based raid? Why support this? The LVM folks decided to go with md as their backend to implement all the recent raid support. Do Fedora installs ever use multipath? Sounds very RHEL. I'm fine with it being started by Anaconda, and the unit enabled by Anaconda if the installation calls for it. But it needs to be disabled by default. Also, the idea of finally just disabling these services isn't new. Services that use deprecated services should not be enabled by default on people's computers. https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/UFGNO5MTPCLEK5B5RCJGGZUFTZ7JTWI5/
(In reply to Chris Murphy from comment #2) > Adding see also bugs for these units. > > I think Anaconda can start these units when it launches, but the vendor > preset should be disabled. If users need them, they can enable them. That is an interesting angle (changing the preset to default). Note I do not agree with "the user sould start them" bit, but anaconda already has logic to install dmraid or multipathd when it is necessary, so anaconda could enable those when the system needs them. So I like the basic concept of changing the presets to disabled. But and this is a bug but, what if a user runs: "systemctl preset-all", which is IMHO not that crazy to do after say an upgrade. This would disable dmraid / multipathd which would make some or all storage unavailable which typically will end bad (e.g. panic on boot because the rootfs could not be found). So I'm not sure if this is a viable option.
(In reply to Chris Murphy from comment #3) > I thought dmraid was itself deprecated in favor of either mdadm or lvm based > raid? Why support this? The LVM folks decided to go with md as their backend > to implement all the recent raid support. In general there are 3 types of RAID: 1) Hardware RAID, where we have a controller which presents a bunch of disks as a set of storage devices/pools at the hardware-interface level 2) Firmware RAID, here we see separate disks, but they have metadata describing the storage pools on the disks which is managed by the Motherboard or controller BIOS, this allows e.g having the bootloader itself on a RAID 5 set (as with hw RAID) as the firmware itself knows about the set and knowns how to read/write it 3) Pure software RAID, where the firmware does not know about it and the bootloader needs to be on a regular (paert of) the disk. With 2. there are many vendor specific metadata formats and we (Linux) needs to be able to interpret these to configure its sw-raid to access the disks in the same way the firmware sees and accesses them. One example of this is the RAID features of Intel and AMD motherboards, e.g. Intel RST. Traditionally all these firmware RAID sets have always been handled by dmraid, which configures device-mapper RAID to do the right thing. Lately Intel firmware RAID has moved to using mdraid for this, but firmware RAID from other vendors still requires dmraid so we cannot just get rid of it. > Do Fedora installs ever use multipath? Sounds very RHEL. I'm fine with it > being started by Anaconda, and the unit enabled by Anaconda if the > installation calls for it. But it needs to be disabled by default. Ack, I think we can drop (or at minimum disable) multipath from the workstation livecds. dmraid is different though, I guess we could change its preset to disabled and have anaconda start it and enable it on the installed system if that is necessary. Downsides are: 1) This will make using a livecd as rescue disk a bit harder for systems with non Intel firmware RAID, users of non Intel firmware RAID now need to manually start dmraid in this case. 2) The "systemctl preset-all" issue I guess dmraid is rare enough that we could solve both with documentation.
Seems like the most central problem is these two units using long since (5+ years) deprecated udev-settle, and delaying everything else. That's arguably a violation of Fedora packaging guidelines related to the enabling of services by default. https://docs.fedoraproject.org/en-US/packaging-guidelines/DefaultServices/#_enabling_services_by_default "MUST NOT change the behavior of any other service" But even if dmraid-activation.service is fixed to no longer drag in udev-settle, I wonder whether dmraid-activation.service "is-enabled" being set to enabled/disabled is appropriate. Disabling things should be fail safe. Users shouldn't be able to disable a startup critical service and then end up abandoned on a deserted island. Should it be static and maybe have a generator conditionally trigger it instead? I have no idea how expensive it is to search for dmraid supported signatures. Does libblkid find these signatures just like any other file system, during early startup? If so a generator could act on libblkid discovering something relevant, and kicking off a static dmraid-activation.service. If this is expensive, then I wonder if it needs separate deep scan and quick scan services? Use the deep scan only on install media. And the quick scan requires a cheap hint, like a symlink or configuration file existing; or maybe an rd.XXX hint?
I believe it is probably best to discuss the dmraid details in the dmraid bug 1795014. I'll copy some of the relevant bits there.
So after doing some thinkout out loud in bug 1795014 I believe that the best solution might actually be to have the dmraid activation shell script which gets started by the dmraid-activation.service unit file do the following if no dmraid sets are found: systemctl disable dmraid-activation.service This avoids the udev-settle activation on the next boot and it will also re-disable the service if it gets re-enabled by a "systemctl preset-all" run.
This is being solved/worked around through the following Fedora 33 Changes: https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD So I believe this bug (solving this in anaconda) can be closed now, closing.
Installed f33 beta. For my installation systemd-udev-settle.service is done in ~11 secs. -- Reboot -- sep 28 20:20:28 dl5 systemd[1]: Starting Wait for udev To Complete Device Initialization... sep 28 20:20:29 dl5 udevadm[480]: systemd-udev-settle.service is deprecated. Please fix multipathd.service not to pull it in. sep 28 20:20:40 dl5 systemd[1]: Finished Wait for udev To Complete Device Initialization. $ systemd-analyze blame 11.679s systemd-udev-settle.service 6.283s NetworkManager-wait-online.service 4.298s plymouth-quit-wait.service 1.826s dracut-initqueue.service 965ms upower.service 884ms fwupd.service ...
(In reply to JMlich from comment #10) > Installed f33 beta. > For my installation systemd-udev-settle.service is done in ~11 secs. > > -- Reboot -- > sep 28 20:20:28 dl5 systemd[1]: Starting Wait for udev To Complete Device > Initialization... > sep 28 20:20:29 dl5 udevadm[480]: systemd-udev-settle.service is deprecated. > Please fix multipathd.service not to pull it in. > sep 28 20:20:40 dl5 systemd[1]: Finished Wait for udev To Complete Device > Initialization. > > $ systemd-analyze blame > 11.679s systemd-udev-settle.service > > 6.283s NetworkManager-wait-online.service > > 4.298s plymouth-quit-wait.service > > 1.826s dracut-initqueue.service > > 965ms upower.service > > 884ms fwupd.service > ... Hmm, with a fresh, new F33 workstation livecd install you should not have device-mapper-multipath installed. Can you do "rpm -q device-mapper-multipath" ? that should say: "package device-mapper-multipath is not installed". But it looks like it is installed in your case. How did you install F33 beta ? Or did you perhaps do an upgrade ?
Package device-mapper-multipath was installed in my case. After removed systemd-udev-settle.service problem is fixed for me. I needed fedora on new-old notebook, so f33 was new install of beta version. After installation as expected many packages updated so I've no idea if device-mapper-multipath presence dates to installation or got to box via some changed dependency.