Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Dne 01. 07. 20 v 10:29 Zbigniew Jędrzejewski-Szmek napsal(a): On Tue, Jun 30, 2020 at 11:04:26AM +0200, Zdenek Kabelac wrote: Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): On 29.06.2020 22:04, Ben Cotton wrote: Fedora only support these RAID sets when they are already configured in the BIOS at installation time. So we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run. We also shouldn't be lightly recommending masking or uninstalling of packages because unexperienced users see such recommendations and may follow them without fully understanding what the effect is. Instead, services should be smart enough to exit quickly if they have nothing to manage (which lvm2-monitor already does). And ideally, storage services should only be started in response to hotplug events that detect given hardware type to exist (which apparently could be improved a bit, but as long as the noop cost is small, this is not a such a big issue). Hi And this is exactly what is our lvm2 service doing - it exits when it's being idle for some tens of seconds. Yep I also believe 'default' should just work in most configuration - even when it's not always the top most optimal way to handle things. Then skilled admins should be capable to set more optimal setups. But I also believe making the lvm2 installation more 'optional' would be good thing in making i.e. VM/container images actually smaller - as those often do not need to have these tools & service installed at all - they just got a single storage device to be on. But since currently lot of package now get transient dependecy chains - lvm2 is often sucked-in even when there is clearly no use for it at all. So that's why having better 'package dependency' design matter - and the size and efficiency still is important for some of us Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tue, Jun 30, 2020 at 11:04:26AM +0200, Zdenek Kabelac wrote: > Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): > >On 29.06.2020 22:04, Ben Cotton wrote: > >>Fedora only support these RAID sets when they are already configured in > >>the BIOS at installation time. So we can solve the problem of > >>dmraid.service still depending on the obsolete udev-settle service by > >>making dmraid.service disable itself if no supported RAID sets are found > >>on its first run. > > > >+1 for this change. > > > >Also the LVM monitor can be disabled too if LVM is not used in current > >Fedora installation. > > > >LVM monitor: -2.01 seconds. > >RAID: -2.41 seconds. > > If the user does not need lvm2, then the package should not be installed/ > However when lvm2 is installed - lvm2 monitoring service is supposed to > be there and enabled - it should not impact load time all that much... [The details have been discussed in some newer messages in the thread, so I'm making just a general comment here:] I don't think uninstalling packages or disabling services is the way to go. Ideally, we should have packages for all frequently used storage stacks installed by default, and all services required to support such stacks also enabled by default when installed. Having things "just work" by default makes the user experience vastly better. We also shouldn't be lightly recommending masking or uninstalling of packages because unexperienced users see such recommendations and may follow them without fully understanding what the effect is. Instead, services should be smart enough to exit quickly if they have nothing to manage (which lvm2-monitor already does). And ideally, storage services should only be started in response to hotplug events that detect given hardware type to exist (which apparently could be improved a bit, but as long as the noop cost is small, this is not a such a big issue). Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 30.06.2020 12:16, Zdenek Kabelac wrote: > The right plan is to fix all packaged dependencies and allow > installation of packages without lvm2. +1. This will be the best solution, I think. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Dne 30. 06. 20 v 11:53 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:42, Zdenek Kabelac wrote: Default for unskilled users who may use lvm2 - should remain enabled. If LVM was not used during installation => Anakonda can automatically disable it. Hmm - I don't think this is a good plan - it would be then different how the package is installed. The right plan is to fix all packaged dependencies and allow installation of packages without lvm2. If lvm2 is installed on system - it should have one 'default' installed configation. What you are proposing is - when user would deploy lvm2 DURING anaconda time - it would behave the way A), but if user would just attach lvm2 storage later one - it would behave in a way B). So personally - the only way is to have fixed inter-package deps - and when user does not want to have lvm2 on his system - he simply should not be installing it - that's IMHO the correct solution here. Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 30.06.2020 11:42, Zdenek Kabelac wrote: > Default for unskilled users who may use lvm2 - should remain enabled. If LVM was not used during installation => Anakonda can automatically disable it. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Dne 30. 06. 20 v 11:34 Vitaly Zaitsev via devel napsal(a): On 30.06.2020 11:23, Igor Raits wrote: Sadly you can't have lvm2 not installed: Yes, but it can be disabled. Of course, you can disable this yourself if you are skilled admin and you do not need it or use it (you can mask it which is even better). Default for unskilled users who may use lvm2 - should remain enabled. Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 30.06.2020 11:23, Igor Raits wrote: > Sadly you can't have lvm2 not installed: Yes, but it can be disabled. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Tue, 2020-06-30 at 11:04 +0200, Zdenek Kabelac wrote: > Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): > > On 29.06.2020 22:04, Ben Cotton wrote: > > > Fedora only support these RAID sets when they are already > > > configured in > > > the BIOS at installation time. So we can solve the problem of > > > dmraid.service still depending on the obsolete udev-settle > > > service by > > > making dmraid.service disable itself if no supported RAID sets > > > are found > > > on its first run. > > > > +1 for this change. > > > > Also the LVM monitor can be disabled too if LVM is not used in > > current > > Fedora installation. > > > > LVM monitor: -2.01 seconds. > > RAID: -2.41 seconds. > > If the user does not need lvm2, then the package should not be > installed/ > However when lvm2 is installed - lvm2 monitoring service is supposed > to > be there and enabled - it should not impact load time all that > much... ❯ systemd-analyze blame | grep lvm 4.103s lvm2-monitor.service Sadly you can't have lvm2 not installed: lvm2 is needed by (installed) libvirt-daemon-driver-storage- logical-6.4.0-1.fc33.x86_64 that is required by other libvirt stuff which ends up with gnome-boxes. > > Zdenek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl77BK0ACgkQEV1auJxc Hh4V8hAApS1m1x4gqE66qQZuf81bcHPU3wTYYgLvzqVr69eq25hzu1pIQDT1oXJH WgHuucYKCQjr2JO9dv2Amil0hNlnrRP6AONJ28f22xUnUHoM93vYi7Y6Ba5sbGh6 31DRf5FEgfcBODXmB4XVGm2vXxlWeMYVnR9ujKHvnl/8ODrI6jLrvIDl02rFq3eT Gym144modLy6cKVaUBRO8q6n26A8wHXKQ+9Gj7h95c5vHZzZd3QReITxsim+Lxee 3iVPI7sRPI6VYZFvtsG+sLJgQlUvrcD1pjkCUJDwIPQG8cnvmfUk8L1TtDOfeRZK Uzn/NQgx8WNAcpOJtE3PrqDLRQl7jVHwulwXP+181RYSAeuX5z69qXZZ+7kq2lVh OtTRKQbfed2VYdrd0emOizZH92zGNR8gtJ4PkCu3ThWEaYnH3eJ5r8FM/znoFOI1 P+rkllVce8AJ0+V+ZJOR3/hLQSN8bcOREm9shxWz7TixUPbkzsRUh4EAWamznyKL ZUHQbv9MZZ5HEvw2+7Ukb8tULsXNBWm1mSMVMhE92XueTaavAkY6E1iPmWaZ1R7y Tvmh1Gmq6Hk/DNb6qQtBPESKHGT9Y4T+8wbKDm8YilotwEZpQ0B1T7W/oTS+ZHKu 0woM7DnULdbtGaPcH1DM+3Q9XTkDWTbxVF3kG90f6oKezSpmntg= =hlFt -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 30.06.2020 11:04, Zdenek Kabelac wrote: > If the user does not need lvm2, then the package should not be installed/ > However when lvm2 is installed - lvm2 monitoring service is supposed to > be there and enabled - it should not impact load time all that much... I use classic partitions, but lvm2-monitor.service is still enabled: 2.129s lvm2-monitor.service -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mo, 29.06.20 16:04, Ben Cotton (bcot...@redhat.com) wrote: > https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun > > == Summary == > The Fedora workstation livecd is the default Fedora variant getfedora.org > advices people to download. > As such most Fedora workstation installs will be done from the livecd. This > means that any package which is part of the livecd will be part of the > default install for most users. > > Dmraid is 1 of only 2 packages in the default install which still Requires > the long obsoleted systemd-udev-settle.service, which waits for all > device-detection to be done + some extra waiting just to be sure. This > significantly slows down booting on various systems. Oh yes, please remove this. It's a shame that dmraid still requires this, it's broken since 10 years to do this, and the maintainers know it. The dmraid people had ample time to fix their code. It's really time this has to go. Lennart -- Lennart Poettering, Berlin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tue, Jun 30, 2020 at 10:30 AM José Abílio Matos wrote: > > IIRC this is probably related with the dependencies of anaconda: Is there an easy suggestion we can make to our users other than play with "rpm -e" or nuking dnf's database? There's a bunch of threads over at askfedora where people are killing services left and right, without knowing what they do, in order to shave off a few milliseconds. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Dne 30. 06. 20 v 10:57 Vitaly Zaitsev via devel napsal(a): On 29.06.2020 22:04, Ben Cotton wrote: Fedora only support these RAID sets when they are already configured in the BIOS at installation time. So we can solve the problem of dmraid.service still depending on the obsolete udev-settle service by making dmraid.service disable itself if no supported RAID sets are found on its first run. +1 for this change. Also the LVM monitor can be disabled too if LVM is not used in current Fedora installation. LVM monitor: -2.01 seconds. RAID: -2.41 seconds. If the user does not need lvm2, then the package should not be installed/ However when lvm2 is installed - lvm2 monitoring service is supposed to be there and enabled - it should not impact load time all that much... Zdenek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 29.06.2020 22:04, Ben Cotton wrote: > Fedora only support these RAID sets when they are already configured in > the BIOS at installation time. So we can solve the problem of > dmraid.service still depending on the obsolete udev-settle service by > making dmraid.service disable itself if no supported RAID sets are found > on its first run. +1 for this change. Also the LVM monitor can be disabled too if LVM is not used in current Fedora installation. LVM monitor: -2.01 seconds. RAID: -2.41 seconds. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Hi, On 6/30/20 12:59 AM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb wrote: But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. Well notably: plymouth-quit-wait.service. Surely plymouth keeps running until everything else has finished, right? plymouth-quit-wait.service is special. On gdm startup the following happens: 1. gdm tells plymouth to deactivate, at this point it release its drm-master ownership of /dev/dri/card0, but does keep it open because otherwise the kernel will automatically free the framebuffer installed by plymouth and that would cause a flicker 2. gdm starts the greeter session 3. the greeter session lets gdm know that it has fully started, this means that gdm now knows that either Xorg or mutter(Wayland) has /dev/dri/card0 open and has installed its own framebuffer 4. gdm tells plymouth it is ok to quit know (and thus close /dev/dri/card0) Step 2 / reaching step 3. is what can take a long time here. This should normally not be dependent on NetworkManager-wait-online.service though. I guess the two just overlap. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tuesday, 30 June 2020 00.56.23 WEST Alexander Ploumistos wrote: > I just tested it on F32 Workstation and for me it does. Have you > cleaned dnf's databases by any chance? I think either that or having > the packages as dependencies of something that was installed by the > user would prevent them from going away with dmraid. IIRC this is probably related with the dependencies of anaconda: # repoquery --whatrequires 'dmraid' --recursive Last metadata expiration check: 0:14:34 ago on Tue 30 Jun 2020 09:14:30 AM WEST. anaconda-0:32.24.5-1.fc32.x86_64 anaconda-0:32.24.7-1.fc32.x86_64 anaconda-0:32.24.7-2.fc32.x86_64 anaconda-install-env-deps-0:32.24.5-1.fc32.x86_64 anaconda-install-env-deps-0:32.24.7-1.fc32.x86_64 anaconda-install-env-deps-0:32.24.7-2.fc32.x86_64 anaconda-realmd-0:0.2-12.fc32.noarch dmraid-0:1.0.0.rc16-44.fc32.i686 dmraid-0:1.0.0.rc16-44.fc32.x86_64 dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64 dmraid-events-0:1.0.0.rc16-44.fc32.x86_64 dmraid-events-logwatch-0:1.0.0.rc16-44.fc32.x86_64 kdump-anaconda-addon-0:005-8.20200220git80aab11.fc32.noarch libblockdev-dm-0:2.23-2.fc32.i686 libblockdev-dm-0:2.23-2.fc32.x86_64 libblockdev-dm-0:2.24-1.fc32.i686 libblockdev-dm-0:2.24-1.fc32.x86_64 libblockdev-dm-devel-0:2.23-2.fc32.i686 libblockdev-dm-devel-0:2.23-2.fc32.x86_64 libblockdev-dm-devel-0:2.24-1.fc32.i686 libblockdev-dm-devel-0:2.24-1.fc32.x86_64 libblockdev-plugins-all-0:2.23-2.fc32.x86_64 libblockdev-plugins-all-0:2.24-1.fc32.x86_64 oscap-anaconda-addon-0:1.0-6.fc32.noarch -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tuesday, 30 June 2020 00.56.23 WEST Alexander Ploumistos wrote: > I just tested it on F32 Workstation and for me it does. Have you > cleaned dnf's databases by any chance? I think either that or having > the packages as dependencies of something that was installed by the > user would prevent them from going away with dmraid. I tried a reverse stance, notice that I have all the package that you mentioned installed: [root@myth ~]# dnf install gdb dbus-x11 python3-pwquality tigervnc-server-minimal tmux Last metadata expiration check: 0:03:44 ago on Tue 30 Jun 2020 09:14:30 AM WEST. Package gdb-9.1-5.fc32.x86_64 is already installed. Package dbus-x11-1:1.12.18-1.fc32.x86_64 is already installed. Package python3-pwquality-1.4.2-2.fc32.x86_64 is already installed. Package tigervnc-server-minimal-1.10.1-5.fc32.x86_64 is already installed. Package tmux-3.0a-2.fc32.x86_64 is already installed. Dependencies resolved. Nothing to do. Complete! [root@myth ~]# dnf remove dmraid No match for argument: dmraid No packages marked for removal. Dependencies resolved. Nothing to do. Complete! -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Tue, Jun 30, 2020 at 1:35 AM José Abílio Matos wrote: > > On Monday, 29 June 2020 22.23.00 WEST Alexander Ploumistos wrote: > > This tends to take with it many things that it shouldn't, like gdb, > > dbus-x11, python3-pwquality, tigervnc-server-minimal and tmux - among > > others. > > I noticed that before but at least on F32 it does not do it anymore. I have > removed dmraid and I still have gdb and tmux installed. I just tested it on F32 Workstation and for me it does. Have you cleaned dnf's databases by any chance? I think either that or having the packages as dependencies of something that was installed by the user would prevent them from going away with dmraid. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Monday, 29 June 2020 22.23.00 WEST Alexander Ploumistos wrote: > This tends to take with it many things that it shouldn't, like gdb, > dbus-x11, python3-pwquality, tigervnc-server-minimal and tmux - among > others. I noticed that before but at least on F32 it does not do it anymore. I have removed dmraid and I still have gdb and tmux installed. -- José Abílio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 6/29/20 3:59 PM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb wrote: But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. Well notably: plymouth-quit-wait.service. Surely plymouth keeps running until everything else has finished, right? I would hope that gdm tells plymouth to go away or starts a new console anyway, but that would be good to find out. There's no reason for anything to be waiting for abrt to finish loading. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Monday, June 29, 2020 1:57:55 PM MST Michael Catanzaro wrote: > On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro > wrote: > > > We might need to explicitly disable systemd-udev-settle.service > > during the system upgrade to turn it off? > > > Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' > and rebooted again, and it's still running. I tried 'systemd-analyze > plot' and I see it takes 11 seconds during boot! I think the culprit is > dmraid-activation.service (not dmraid.service). Did you get the name of > the service wrong in the change proposal, or have I misunderstood? > > Unrelated: looking at my systemd-analyze plot, other startup time > offenders are NetworkManager-wait-online.service (9.5 seconds, seems > egregious, I wonder why this is necessary?) and grand prize winner > abrtd.service (requiring an amazing 30 seconds!) Well, disabling it on upgrade might be fine, so long as you check that it's not actually in use. Please keep in mind that dmraid is required for, for example, Intel firmware RAID, and so simply disabling this would mean that users' workstations or servers using firmware RAID wouldn't be able to boot.. -- John M. Harris, Jr. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 3:37 pm, Samuel Sieb wrote: But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. Well notably: plymouth-quit-wait.service. Surely plymouth keeps running until everything else has finished, right? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On 6/29/20 1:57 PM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro wrote: We might need to explicitly disable systemd-udev-settle.service during the system upgrade to turn it off? Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' and rebooted again, and it's still running. I tried 'systemd-analyze plot' and I see it takes 11 seconds during boot! I think the culprit is dmraid-activation.service (not dmraid.service). Did you get the name of the service wrong in the change proposal, or have I misunderstood? Unrelated: looking at my systemd-analyze plot, other startup time offenders are NetworkManager-wait-online.service (9.5 seconds, seems egregious, I wonder why this is necessary?) and grand prize winner abrtd.service (requiring an amazing 30 seconds!) But that should be running concurrently. Does the plot show anything important waiting for it? Your desktop should be able to load before that service is finished starting. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 11:09 PM Hans de Goede wrote: > > I fix this on my > own systems with "dnf remove dmraid" This tends to take with it many things that it shouldn't, like gdb, dbus-x11, python3-pwquality, tigervnc-server-minimal and tmux - among others. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 11:09 pm, Hans de Goede wrote: I got the name of the unit wrong in the change proposal, sorry. I fix this on my own systems with "dnf remove dmraid", but unlike multipath some desktop machines may actually have a BIOS/firmware RAID set configured which needs dmraid and we do want to support those setups with the workstation livecd. I'll re-install dmraid and correct the proposal text when I can find some time for that. OK cool. I just wanted to add, I tested and confirmed that if I 'systemctl disable dmraid-activation.service', it does indeed cause systemd-udev-settle.service to no longer run, so seems to work nicely. Next, I will test disabling ABRT and confirm we'll boot twice as fast without it. :( ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 2:58 PM Michael Catanzaro wrote: > > On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro > wrote: > > We might need to explicitly disable systemd-udev-settle.service > > during the system upgrade to turn it off? > > Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' > and rebooted again, and it's still running. I tried 'systemd-analyze > plot' and I see it takes 11 seconds during boot! I think the culprit is > dmraid-activation.service (not dmraid.service). Did you get the name of > the service wrong in the change proposal, or have I misunderstood? > > Unrelated: looking at my systemd-analyze plot, other startup time > offenders are NetworkManager-wait-online.service (9.5 seconds, seems > egregious, I wonder why this is necessary?) and grand prize winner > abrtd.service (requiring an amazing 30 seconds!) Many activate and run in parallel, including NetworkManager-wait-online, and don't directly contribute to startup delays. That one should really just be waiting for all the network configuration to really happen before trying things that depend on the network: e.g. NFS and maybe some kind of network login. Some services can stuck much longer if they try to connect before there's a connection available. But yeah all of the enabled by default services probably need a review for F33 to make sure they're intentionally enabled. /me not a fan of startup delays, I really wanna be under 10s. Right now I'm at 19s and that's on NVMe with no external devices or services to connect to. -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
Hi, On 6/29/20 10:57 PM, Michael Catanzaro wrote: On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro wrote: We might need to explicitly disable systemd-udev-settle.service during the system upgrade to turn it off? Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' and rebooted again, and it's still running. I tried 'systemd-analyze plot' and I see it takes 11 seconds during boot! I think the culprit is dmraid-activation.service (not dmraid.service). Did you get the name of the service wrong in the change proposal, or have I misunderstood? I got the name of the unit wrong in the change proposal, sorry. I fix this on my own systems with "dnf remove dmraid", but unlike multipath some desktop machines may actually have a BIOS/firmware RAID set configured which needs dmraid and we do want to support those setups with the workstation livecd. I'll re-install dmraid and correct the proposal text when I can find some time for that. Regards, Hans ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 3:45 pm, Michael Catanzaro wrote: We might need to explicitly disable systemd-udev-settle.service during the system upgrade to turn it off? Doesn't work... I tried 'systemctl disable systemd-udev-settle.service' and rebooted again, and it's still running. I tried 'systemd-analyze plot' and I see it takes 11 seconds during boot! I think the culprit is dmraid-activation.service (not dmraid.service). Did you get the name of the service wrong in the change proposal, or have I misunderstood? Unrelated: looking at my systemd-analyze plot, other startup time offenders are NetworkManager-wait-online.service (9.5 seconds, seems egregious, I wonder why this is necessary?) and grand prize winner abrtd.service (requiring an amazing 30 seconds!) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
So, in relation to the device-mapper-multipath change in the other thread, I ran 'sudo dnf remove device-mapper-multipath'. Then I ran 'systemctl status dmraid.service' and saw "Unit dmraid.service could not be found," so I must not have that installed at all. Then I rebooted. When I run 'systemctl status systemd-udev-settle.service' I see it's still active and exited after my reboot. I see the vendor preset is disabled, so I guess it should be OK for fresh installs, but maybe the current proposals won't be enough for upgraded systems? We might need to explicitly disable systemd-udev-settle.service during the system upgrade to turn it off? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 4:05 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun > > == Summary == > The Fedora workstation livecd is the default Fedora variant getfedora.org > advices people to download. > As such most Fedora workstation installs will be done from the livecd. This > means that any package which is part of the livecd will be part of the > default install for most users. > > Dmraid is 1 of only 2 packages in the default install which still Requires > the long obsoleted systemd-udev-settle.service, which waits for all > device-detection to be done + some extra waiting just to be sure. This > significantly slows down booting on various systems. > > Fedora only support these RAID sets when they are already configured in the > BIOS at installation time. So we can solve the problem of dmraid.service > still depending on the obsolete udev-settle service by making dmraid.service > disable itself if no supported RAID sets are found on its first run. > Yay! +1 -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Disable dmraid.service on first run if no dmraid sets are found - Fedora 33 System-Wide Change proposal
On Mon, Jun 29, 2020 at 2:06 PM Ben Cotton wrote: > > https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun > Fedora only support these RAID sets when they are already configured in the > BIOS at installation time. So we can solve the problem of dmraid.service > still depending on the obsolete udev-settle service by making dmraid.service > disable itself if no supported RAID sets are found on its first run. Hurray! +1 -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
