On 2020-06-30 13:53, Hans de Goede wrote: > Hi All, > > For those of you who are still around from when I was a part > of the anaconda team: long time no see. > > First some background on $subject: > > 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. > > As you very well know, with livecd installs the packageset > installed is the one which used to compose the livecd, since > the rootfs is simply rsync-ed over. > > This means that any storage related packages which may > be necessary in some exotic setups are part of the livecd. > > Some of these storage related packages are poorly behaved > wrt their systemd services, they come with services which > simply always run. > > 2 of these are particularly bad because they also bring > in (through Requires=) the long obsolete systemd-udev-settle > service significantly delaying the boot. These are dmraid > and device-mapper-multipath. > > As you may have seen I have proposed 2 changes for Fedora 33 > to deal with this: > > https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun > https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD > > > These are currently being discussed on the fedora-devel > mailinglist. > > One suggestion which came up there and which I think is > probably a better idea then my original solutions is > to make anaconda disable the related services in the > post-install config part of the livecd install. > > This should be easy to implement, unless this has > changed since I last worked on anaconda, the storage > code will provide a list of extra packages which need > to be installed because they are necessary for the > chosen storage config. Yes, Blivet still provides list of packages need for existing storage configuration. > > My idea is to have a table (somewhere) with mappings > of storage packages to service-names to disable. > Then the livecd post-install config code can ask the > storage code for the list of necessary packages and > then walk over this new table. If a package is not > listed as being necessary by the storage code, then > the livecd post-install config code can run > "systemctl disable $mapped-service.service" > thus disabling any (bad behaved) storage services which > are not necessary. > > For starters this table would just contain dmraid > and device-mapper-multipath, but I think this would > be a nice generic config mechanism which we might > be able to use for some other cases in the future. I think we could just remove dm-multipath from the live CD. Or is there a use case where multipath is needed during workstation installation? AFAICT dmraid is no longer being developed but we still need it. mdadm unfortunately doesn't support all firmware RAID variants and we still get a handful of bugs for every release and even new workstations (and laptops) sometimes come preconfigured with bios/fw RAID. > > So 2 questions: > > 1. What do you think of my proposal to disable these > services (when not needed) in the livecd post-install > config phase? Would you be willing to accept a > merge-req for this? I personally don't like the idea of disabling the service, I would prefer to simply remove the package. Disabling the service would mean we have two different default behaviours for the package depending on how it was installed. If the default behaviour is "service X is enabled after installing package Y" we shouldn't change it just because the package was installed by Anaconda. > > 2. Its been a long time since I last touched the > anaconda code, my python is quite rusty and my > plate is way too full, so I was wondering if one > of you could implement this if we chose to go this > route? > > Regards, > > Hans > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
