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

2020-07-09 Thread Hans de Goede 

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-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-07-09 Thread Brian C. Lane 
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

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

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

2020-07-09 Thread Vendula Poncova 
On Thu, Jul 9, 2020 at 2:03 PM Hans de Goede  wrote:

> Hi,
>
> On 7/9/20 1:06 PM, Neal Gompa wrote:
> > On Thu, Jul 9, 2020 at 7:02 AM Hans de Goede 
> wrote:
> >>
> >> Hi,
> >>
> >> On 7/8/20 12:01 PM, Vendula Poncova wrote:
> >>> On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede  > 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.
>
>
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
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-07-09 Thread Hans de Goede 

Hi,

On 7/9/20 1:06 PM, Neal Gompa wrote:

On Thu, Jul 9, 2020 at 7:02 AM Hans de Goede  wrote:


Hi,

On 7/8/20 12:01 PM, Vendula Poncova wrote:

On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede mailto:hdego...@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

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-07-09 Thread Neal Gompa 
On Thu, Jul 9, 2020 at 7:02 AM Hans de Goede  wrote:
>
> Hi,
>
> On 7/8/20 12:01 PM, Vendula Poncova wrote:
> > On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede  > > 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!


___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-07-09 Thread Hans de Goede 

Hi,

On 7/8/20 12:01 PM, Vendula Poncova wrote:

On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede mailto:hdego...@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

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-07-08 Thread Vendula Poncova 
On Fri, Jul 3, 2020 at 2:07 PM Hans de Goede  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?
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
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-07-03 Thread Hans de Goede 

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.

Regards,

Hans

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-07-03 Thread Hans de Goede 

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

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-07-03 Thread Hans de Goede 

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.

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

2020-07-01 Thread Vendula Poncova 
On Tue, Jun 30, 2020 at 7:01 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?
>

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.

> 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.
>
>
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
>
>
___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-06-30 Thread Brian C. Lane 
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

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

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

2020-06-30 Thread Patrick Riehecky 
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.

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-06-30 Thread Vojtěch Trefný 



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@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

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

2020-06-30 Thread Hans de Goede 

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.

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

___
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list