Re: Making anaconda disable some storage-related systemd services in post-install config part of livecd install?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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
> 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:
> 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

> 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

Anaconda-devel-list mailing list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux