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/RemoveDeviceMapperMultipathFromWorkst...
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.
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.
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?
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
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/RemoveDeviceMapperMultipathFromWorkst...
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:
- 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.
- 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@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
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/RemoveDeviceMapperMultipathFromWorkst...
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:
- 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
On Tue, 2020-06-30 at 13:53 +0200, Hans de Goede wrote:
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.
Can we work make these services smarter? Perhaps make the units check some other system condition before attempting to start? I'm not sure how feasible that actually is though.....
Hi,
On 6/30/20 5:53 PM, Patrick Riehecky wrote:
On Tue, 2020-06-30 at 13:53 +0200, Hans de Goede wrote:
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.
Can we work make these services smarter? Perhaps make the units check some other system condition before attempting to start? I'm not sure how feasible that actually is though.....
Unfortunately making these services smarter is a lot of work and at least dmraid is not actively being worked on any more, so making it smarter is not something which is likely to happen in the near future.
Regards,
Hans
On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote:
So 2 questions:
- 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?
- 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?
I think implementing this may be even easier. Anaconda runs post-script snippets from /usr/share/anaconda/post-scripts/*ks at the end of every install. The livecd could drop in a script to handle disabling these, I think.
Current scripts are here:
https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts
Brian
On Tue, Jun 30, 2020 at 7:01 PM Brian C. Lane bcl@redhat.com wrote:
On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote:
So 2 questions:
- 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?
Hi Hans,
I prefer the original plan proposed in the Fedora changes. Let the dmraid service to disable itself on the first run and remove the device-mapper-multipath package from Live CD.
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.
- 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?
I think implementing this may be even easier. Anaconda runs post-script snippets from /usr/share/anaconda/post-scripts/*ks at the end of every install. The livecd could drop in a script to handle disabling these, I think.
I agree with Brian. If you want to go this way, then the best option is a post script. I guess that the script would be generated by the file https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-base.ks that belongs to the component spin-kickstarts. It means that no change is needed in Anaconda.
You should probably talk to someone from Fedora Silverblue in this case, because they are trying to be as close to Fedora Workstation as possible.
Vendy
Current scripts are here:
https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts
Brian
-- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Hi,
On 6/30/20 6:59 PM, Brian C. Lane wrote:
On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote:
So 2 questions:
- 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?
- 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?
I think implementing this may be even easier. Anaconda runs post-script snippets from /usr/share/anaconda/post-scripts/*ks at the end of every install. The livecd could drop in a script to handle disabling these, I think.
Current scripts are here:
https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts
Yes that would be an option, although getting the list of pkgs which are deemed as being necessary for the configured storage (and thus should not have their services disabled) might be tricky to do from such a post-install script ?
Anyways, going by Vojtěch's reply, there are no objections to removing device-mapper-multipath from the livecd. And it will be quite easy to make the dmraid-activation service disable itself if no dmraid sets are found (it already is a shell script).
So I believe it would be best to move forward with this as I original proposed in the 2 change pages:
https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkst...
This requires almost no anaconda changes as mentioned in another part of the thread, the hard-dep on device-mapper-multipath needs to be dropped. But with some luck that is all that is required on the anaconda side.
Regards,
Hans
On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 6/30/20 6:59 PM, Brian C. Lane wrote:
On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote:
So 2 questions:
- 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?
- 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?
I think implementing this may be even easier. Anaconda runs post-script snippets from /usr/share/anaconda/post-scripts/*ks at the end of every install. The livecd could drop in a script to handle disabling these, I think.
Current scripts are here:
https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts
Yes that would be an option, although getting the list of pkgs which are deemed as being necessary for the configured storage (and thus should not have their services disabled) might be tricky to do from such a post-install script ?
Anyways, going by Vojtěch's reply, there are no objections to removing device-mapper-multipath from the livecd. And it will be quite easy to make the dmraid-activation service disable itself if no dmraid sets are found (it already is a shell script).
So I believe it would be best to move forward with this as I original proposed in the 2 change pages:
https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun
https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkst...
This requires almost no anaconda changes as mentioned in another part of the thread, the hard-dep on device-mapper-multipath needs to be dropped. But with some luck that is all that is required on the anaconda side.
The anaconda's dependency on device-mapper-multipath is caused by fcoe-utils:
anaconda -> anaconda-install-env-deps -> fcoe-utils -> device-mapper-multipath
Is it expected that the support for FCoE devices will be dropped from Live OS? If yes, it shouldn't be a problem to change the dependency on fcoe-utils to weak.
Vendy
Regards,
Hans
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
Hi,
On 7/8/20 12:01 PM, Vendula Poncova wrote:
On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede <hdegoede@redhat.com mailto:hdegoede@redhat.com> wrote:
Hi, On 6/30/20 6:59 PM, Brian C. Lane wrote: > On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote: >> 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? >> >> 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? > > I think implementing this may be even easier. Anaconda runs post-script > snippets from /usr/share/anaconda/post-scripts/*ks at the end of every > install. The livecd could drop in a script to handle disabling these, I > think. > > Current scripts are here: > > https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts Yes that would be an option, although getting the list of pkgs which are deemed as being necessary for the configured storage (and thus should not have their services disabled) might be tricky to do from such a post-install script ? Anyways, going by Vojtěch's reply, there are no objections to removing device-mapper-multipath from the livecd. And it will be quite easy to make the dmraid-activation service disable itself if no dmraid sets are found (it already is a shell script). So I believe it would be best to move forward with this as I original proposed in the 2 change pages: https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD This requires almost no anaconda changes as mentioned in another part of the thread, the hard-dep on device-mapper-multipath needs to be dropped. But with some luck that is all that is required on the anaconda side.
The anaconda's dependency on device-mapper-multipath is caused by fcoe-utils:
anaconda -> anaconda-install-env-deps -> fcoe-utils -> device-mapper-multipath
Is it expected that the support for FCoE devices will be dropped from Live OS?
That was not part of the Change proposal, but having FCoE support in the Workstation LiveCD makes about as much sense as having multipath support, so I believe that dropping it is fine. I can amend the Change proposal to mention this.
If yes, it shouldn't be a problem to change the dependency on fcoe-utils to weak.
If you can do that, then that would be great. But I believe that dnf includes weak deps by default. I must admit that it is a long time since I've done anything wrt livecd composes. Is there a way to explicitly exclude some weak deps when doing composes, or are they excluded by default now a days?
I guess I should just re-learn how to do composes and do a compose to make sure things turn out as we want. Is there a short primer on how to do a livecd compose these days somewhere?
Regards,
Hans
On Thu, Jul 9, 2020 at 7:02 AM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 7/8/20 12:01 PM, Vendula Poncova wrote:
On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede <hdegoede@redhat.com mailto:hdegoede@redhat.com> wrote:
Hi, On 6/30/20 6:59 PM, Brian C. Lane wrote: > On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote: >> 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? >> >> 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? > > I think implementing this may be even easier. Anaconda runs post-script > snippets from /usr/share/anaconda/post-scripts/*ks at the end of every > install. The livecd could drop in a script to handle disabling these, I > think. > > Current scripts are here: > > https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts Yes that would be an option, although getting the list of pkgs which are deemed as being necessary for the configured storage (and thus should not have their services disabled) might be tricky to do from such a post-install script ? Anyways, going by Vojtěch's reply, there are no objections to removing device-mapper-multipath from the livecd. And it will be quite easy to make the dmraid-activation service disable itself if no dmraid sets are found (it already is a shell script). So I believe it would be best to move forward with this as I original proposed in the 2 change pages: https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD This requires almost no anaconda changes as mentioned in another part of the thread, the hard-dep on device-mapper-multipath needs to be dropped. But with some luck that is all that is required on the anaconda side.
The anaconda's dependency on device-mapper-multipath is caused by fcoe-utils:
anaconda -> anaconda-install-env-deps -> fcoe-utils -> device-mapper-multipath
Is it expected that the support for FCoE devices will be dropped from Live OS?
That was not part of the Change proposal, but having FCoE support in the Workstation LiveCD makes about as much sense as having multipath support, so I believe that dropping it is fine. I can amend the Change proposal to mention this.
If yes, it shouldn't be a problem to change the dependency on fcoe-utils to weak.
If you can do that, then that would be great. But I believe that dnf includes weak deps by default. I must admit that it is a long time since I've done anything wrt livecd composes. Is there a way to explicitly exclude some weak deps when doing composes, or are they excluded by default now a days?
I guess I should just re-learn how to do composes and do a compose to make sure things turn out as we want. Is there a short primer on how to do a livecd compose these days somewhere?
If you set them as excluded in the live media kickstart files, they'll be properly excluded. I fixed this some time ago so that even weak installs would not take effect in this scenario.
So you'd probably want to add a "-fcoe-utils" line to %packages in fedora-live-base.ks: https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-base.ks
As for the process to create the media, I don't have it offhand, but usually you can look at a recent Koji task to create the ISO to see how it's done.
-- 真実はいつも一つ!/ Always, there's only one truth!
Hi,
On 7/9/20 1:06 PM, Neal Gompa wrote:
On Thu, Jul 9, 2020 at 7:02 AM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 7/8/20 12:01 PM, Vendula Poncova wrote:
On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede <hdegoede@redhat.com mailto:hdegoede@redhat.com> wrote:
Hi, On 6/30/20 6:59 PM, Brian C. Lane wrote: > On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote: >> 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? >> >> 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? > > I think implementing this may be even easier. Anaconda runs post-script > snippets from /usr/share/anaconda/post-scripts/*ks at the end of every > install. The livecd could drop in a script to handle disabling these, I > think. > > Current scripts are here: > > https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts Yes that would be an option, although getting the list of pkgs which are deemed as being necessary for the configured storage (and thus should not have their services disabled) might be tricky to do from such a post-install script ? Anyways, going by Vojtěch's reply, there are no objections to removing device-mapper-multipath from the livecd. And it will be quite easy to make the dmraid-activation service disable itself if no dmraid sets are found (it already is a shell script). So I believe it would be best to move forward with this as I original proposed in the 2 change pages: https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkstationLiveCD This requires almost no anaconda changes as mentioned in another part of the thread, the hard-dep on device-mapper-multipath needs to be dropped. But with some luck that is all that is required on the anaconda side.
The anaconda's dependency on device-mapper-multipath is caused by fcoe-utils:
anaconda -> anaconda-install-env-deps -> fcoe-utils -> device-mapper-multipath
Is it expected that the support for FCoE devices will be dropped from Live OS?
That was not part of the Change proposal, but having FCoE support in the Workstation LiveCD makes about as much sense as having multipath support, so I believe that dropping it is fine. I can amend the Change proposal to mention this.
If yes, it shouldn't be a problem to change the dependency on fcoe-utils to weak.
If you can do that, then that would be great. But I believe that dnf includes weak deps by default. I must admit that it is a long time since I've done anything wrt livecd composes. Is there a way to explicitly exclude some weak deps when doing composes, or are they excluded by default now a days?
I guess I should just re-learn how to do composes and do a compose to make sure things turn out as we want. Is there a short primer on how to do a livecd compose these days somewhere?
If you set them as excluded in the live media kickstart files, they'll be properly excluded. I fixed this some time ago so that even weak installs would not take effect in this scenario.
So you'd probably want to add a "-fcoe-utils" line to %packages in fedora-live-base.ks: https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-base.ks
Ok, this sounds good. Anaconda-team, can one of you turn the fcoe-utils dep into a weak-dep then and let me know when a build with that change has been done.
Once that is in place I will make and test the necessary change to the fedora-live-base.ks file.
Regards,
Hans
On Thu, Jul 9, 2020 at 2:03 PM Hans de Goede hdegoede@redhat.com wrote:
Hi,
On 7/9/20 1:06 PM, Neal Gompa wrote:
On Thu, Jul 9, 2020 at 7:02 AM Hans de Goede hdegoede@redhat.com
wrote:
Hi,
On 7/8/20 12:01 PM, Vendula Poncova wrote:
On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede <hdegoede@redhat.com
mailto:hdegoede@redhat.com> wrote:
Hi, On 6/30/20 6:59 PM, Brian C. Lane wrote: > On Tue, Jun 30, 2020 at 01:53:19PM +0200, Hans de Goede wrote: >> 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? >> >> 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? > > I think implementing this may be even easier. Anaconda runs
post-script
> snippets from /usr/share/anaconda/post-scripts/*ks at the end
of every
> install. The livecd could drop in a script to handle disabling
these, I
> think. > > Current scripts are here: > >
https://github.com/rhinstaller/anaconda/tree/master/data/post-scripts
Yes that would be an option, although getting the list of pkgs which are deemed as being necessary for the configured storage (and thus should not have their services disabled) might be tricky to do from such a post-install script ? Anyways, going by Vojtěch's reply, there are no objections to removing device-mapper-multipath from the livecd. And it will be quite easy to make the dmraid-activation service disable itself if no dmraid sets are found (it already is a shell script). So I believe it would be best to move forward with this as I original proposed in the 2 change pages: https://fedoraproject.org/wiki/Changes/DisableDmraidOnFirstRun
https://fedoraproject.org/wiki/Changes/RemoveDeviceMapperMultipathFromWorkst...
This requires almost no anaconda changes as mentioned in another part of the thread, the hard-dep on device-mapper-multipath needs to be dropped. But with some luck that is all that is required on the anaconda side.
The anaconda's dependency on device-mapper-multipath is caused by
fcoe-utils:
anaconda -> anaconda-install-env-deps -> fcoe-utils ->
device-mapper-multipath
Is it expected that the support for FCoE devices will be dropped from
Live OS?
That was not part of the Change proposal, but having FCoE support in the Workstation LiveCD makes about as much sense as having multipath
support, so
I believe that dropping it is fine. I can amend the Change proposal to
mention
this.
If yes, it shouldn't be a problem to change the dependency on
fcoe-utils to weak.
If you can do that, then that would be great. But I believe that dnf
includes
weak deps by default. I must admit that it is a long time since I've
done
anything wrt livecd composes. Is there a way to explicitly exclude some
weak
deps when doing composes, or are they excluded by default now a days?
I guess I should just re-learn how to do composes and do a compose to
make
sure things turn out as we want. Is there a short primer on how to do a
livecd
compose these days somewhere?
If you set them as excluded in the live media kickstart files, they'll be properly excluded. I fixed this some time ago so that even weak installs would not take effect in this scenario.
So you'd probably want to add a "-fcoe-utils" line to %packages in fedora-live-base.ks: https://pagure.io/fedora-kickstarts/blob/master/f/fedora-live-base.ks
Ok, this sounds good. Anaconda-team, can one of you turn the fcoe-utils dep into a weak-dep then and let me know when a build with that change has been done.
https://github.com/rhinstaller/anaconda/pull/2722
Once that is in place I will make and test the necessary change to the fedora-live-base.ks file.
Regards,
Hans
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Thu, Jul 09, 2020 at 01:00:30PM +0200, Hans de Goede wrote:
I guess I should just re-learn how to do composes and do a compose to make sure things turn out as we want. Is there a short primer on how to do a livecd compose these days somewhere?
Once you have your kickstart you can use livemedia-creator, either with a boot.iso from the release you are building for:
sudo livemedia-creator --make-iso \ --iso=/extra/iso/boot.iso --ks=./docs/fedora-livemedia.ks
Or if you have anaconda installed on the host:
sudo livemedia-creator --make-iso --no-virt \ --ks=./docs/fedora-livemedia.ks
https://weldr.io/lorax/livemedia-creator.html#quickstart
Brian
Hi,
On 7/9/20 5:26 PM, Brian C. Lane wrote:
On Thu, Jul 09, 2020 at 01:00:30PM +0200, Hans de Goede wrote:
I guess I should just re-learn how to do composes and do a compose to make sure things turn out as we want. Is there a short primer on how to do a livecd compose these days somewhere?
Once you have your kickstart you can use livemedia-creator, either with a boot.iso from the release you are building for:
sudo livemedia-creator --make-iso \ --iso=/extra/iso/boot.iso --ks=./docs/fedora-livemedia.ks
Or if you have anaconda installed on the host:
sudo livemedia-creator --make-iso --no-virt \ --ks=./docs/fedora-livemedia.ks > https://weldr.io/lorax/livemedia-creator.html#quickstart
Great, thank you for the pointers.
Regards,
Hans
anaconda-devel@lists.stg.fedoraproject.org