On Thu, Jul 9, 2020 at 2:03 PM Hans de Goede <hdegoede@xxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxxxx <mailto:hdegoede@xxxxxxxxxx>> 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
_______________________________________________
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
