Hi,
Thank you (and others) for your response. Sorry for being
a bit slow to respond.
On 6/30/20 5:28 PM, Vojtěch Trefný wrote:
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?
No, AFAICT there are no use-cases. We got one objection
against outright removal on the fedora-devel, but when
asked for specific use cases the person objecting couldn't
give any. So yes removing it is an option.
ATM I believe that anaconda depends on it, or maybe anaconda
depends on libblockdev-plugins-all? Either way removing
device-mapper-multipath after doing a livecd install also
removes anaconda, we would need to fix this and make sure that
anaconda does not error out somewhere when device-mapper-multipath
is not installed.
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.
Right, note that it would be very easy to make dmraid disable itself
if no support RAID sets are found on its first run. If we do not want
to make anaconda do service disabling (as discussed below), then that
could be a workaround for now. It seems that no-one really cares about
dmraid atm, also see the lvm2-team member responses on the fedora-devel
list. But as you say we do need to keep it around because some users
need it.
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.
I see, removing the package(s) certainly would work for me, that is
even better (frees up diskspace, no need to needlessly download
them on updates) then just disabling the service. So I'm all for
disabling.
Let me copy and paste Vendula's response further down the thread
here as that is relevant for the remove instead of disable option:
> The idea of handling this in Anaconda is definitely interesting. As Vojta suggested, it would make more sense to remove unneeded packages at the end of the installation. We already track a request to remove the anaconda packages, so it is a use case that we plan to support in the future. It wouldn't require the mapping of storage packages to service names, which I find very fragile. However, it won't be trivial to implement such support in a robust and meaningful way and we are not really there yet. We are in a process of modularizing the Anaconda code and there are some missing pieces that we
> need to move with this further.
Ok, so for the long term the plan would be to remove unnecessary
storage related packages such as dmraid after a livecd install,
but for this cycle (F33 cycle) that is not feasible.
Then for this cycle it seems best to me to go with the solutions
as suggested in the 2 change pages I created:
1. Remove device-mapper-multi-path from the livecd
2. Make the dmraid-activation service disable itself if
no supported RAID sets are found
I can take care of 2. But for 1. I'm going to need some
help from you (the anaconda team) can one of you look into
removing the hard-dep anaconda has on device-mapper-multi-path ?
Note we obviously still want device-mapper-mulipath in the
netboot isos, so we are going to need to do something extra
to ensure that it will still be included there.
Regards,
Hans
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
