Re: Making anaconda disable some storage-related systemd services in post-install config part of livecd install?
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: F33: preview swap-on-ZRAM using zram-generator feature change
On Sun, Jun 28, 2020 at 10:10 PM Chris Murphy wrote: > Hi, > > This change has been approved. There are still some details to work > out. What do Anaconda folks think for the custom partitioning use case > where the use manually creates disk-based swap? Should and could the > installer then also do: > > 'touch /etc/systemd/zram-generator.conf' > > post install? The effect is to disable the zram-generator and there'd > be only disk-based swap. The alternative outcome without this is > they'll have both swap-on-zram with a higher priority than the > swap-on-disk they created. > > I'm open to suggestions. I think it's mainly a question about what you > think the user expects in this situation. That's hard to answer > because the user expects disk based swap as a long standing > convention. And there is no convention for either swap-on-zram yet, or > two swap devices, even though the kernel has supported up to 32 swap > devices since forever. > > The best experience performance wise would be to have the two swaps. > They gain from swap-on-zram at first, and perhaps mostly. Followed by > the secondary use of disk based swap. But I'm not opposed to disabling > zram-generator in this case. It is a more conservative option and > might better square with expectations. > > Hi Chris, we have discussed it and we don't really have a strong preference. Enabling both seems like a slightly better choice, because the installed systems won't be so different. As far as I know, the hibernation will still work and, as you said, the performance should be better. The generator can be always disabled in a %post script of a kickstart file or after booting into the installed system. Vendy > > Thanks, > > Chris Murphy > > ___ > 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: sd-boot for UEFI installs
On Tue, Jun 30, 2020 at 6:24 PM Jóhann B. Guðmundsson wrote: > Hi > > I'm looking into the scope of replacing grub2 with sd-boot for UEFI > installs in Fedora and I'm wondering how such a change would affect > Anaconda and if Anaconda is capable of detecting if legacy bios settings > is in use and if so install and setup grub2 and if not install and setup > sd-boot. > > Could someone from the bootloader team look into this, please? Vendy > Thanks > > JBG > > ___ > 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: sd-boot for UEFI installs
Hello Vendula, On 7/1/20 12:33 PM, Vendula Poncova wrote: > On Tue, Jun 30, 2020 at 6:24 PM Jóhann B. Guðmundsson > wrote: > >> Hi >> >> I'm looking into the scope of replacing grub2 with sd-boot for UEFI >> installs in Fedora and I'm wondering how such a change would affect >> Anaconda and if Anaconda is capable of detecting if legacy bios settings >> is in use and if so install and setup grub2 and if not install and setup >> sd-boot. >> >> > Could someone from the bootloader team look into this, please? > I've answered to the thread now: https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/7W5MJTP64WXYDRHUD7WTH5GSBQII2BC6/ > Vendy > > Best regards, Javier ___ Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list