Anaconda-devel June 2020

anaconda-devel@lists.stg.fedoraproject.org

12 participants
5 discussions

F33: preview swap-on-ZRAM using zram-generator feature change
by Chris Murphy 16 Jul '20

16 Jul '20

Hi, I'm following-up now that there's a preview of the change proposal ready: https://fedoraproject.org/wiki/Changes/SwapOnZRAM Highlights: - This is a system-wide change, for all editions and spins. And if Anaconda folks are still agreeable, it would be included on all install media where Anaconda is found: DVD/Live/netinstall. - Fedora Workstation edition will no longer create swap-on-disk by default. Instead swap-on-zram will be used. I expect to get buy-in from other editions/spins to do the same. This applies only to the default/automatic partitioning path, as previously discussed. - Tentative (proposed) defaults similar to what's used by IoT: ZRAM device is 50% RAM, with a 4GiB cap. The max size, which is configurable, is to help scale ZRAM device size for more uses cases and hopefully settle on a single default Fedora wide. This is a bit different than Anaconda's implementation, which doesn't activate above 2GiB, and uses a 1:1 ZRAM to RAM ratio. Based on my testing, even VM's with 3GiB RAM still prefer to use quite a decent amount of swap ~200MiB. If it's available. I think this adjustment is neutral to slightly better for Anaconda. And in any case the installer and installed environments will have the same configuration and implementation as a result of the change. - Disable or somehow deprecate the Anaconda specific implementation, to avoid conflict and user confusion among the implementations. - Test day will be planned Critical feedback welcome. -- Chris Murphy

6 24

Making anaconda disable some storage-related systemd services in post-install config part of livecd install?
by Hans de Goede 09 Jul '20

09 Jul '20

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/RemoveDeviceMapperMultipathFromWorks… 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

6 14

sd-boot for UEFI installs
by Jóhann B. Guðmundsson 01 Jul '20

01 Jul '20

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. Thanks JBG

3 2

Query about rhinstaller/anaconda#2651
by Neal Gompa 29 Jun '20

29 Jun '20

Hey all, So I was looking at the Anaconda commits today, and I saw this change[1] land, which changes how default partitioning is set up. The change is somewhat confusing to me, because it _seems_ like it makes it so that we suddenly are encrypting swap and other volumes by default in Fedora, and I don't recall anyone asking for that to happen. Admittedly, this change is a bit ambiguous when compared to what the code looked like before, but the comment that says "the mount point will be encrypted" makes me think that setting "(encrypted)" will actually encrypt by default. Can someone please help me understand what's going on here? Thanks in advance! [1]: https://github.com/rhinstaller/anaconda/commit/d6df9b3c597b14a8e12fafaacc27… -- 真実はいつも一つ！/ Always, there's only one truth!

3 2

Cannot install on the same device (iSCSI target) where LiveOS booted from
by Dick Marinus 02 Jun '20

02 Jun '20

Hi all! I've prepared an iSCSI target (32 GB) with a small (2GB) ext4 filesystem containing LiveOS/squashfs.img, initrd.img and vmlinuz and configured extlinux to make that partition bootable (root=live:UUID=3aa6fe78-5418-4d86-ba80-bec7d5fff742 rd.live.image netroot=iscsi rd.iscsi.firmware=1) and to boot Fedora-Workstation-Live. Then I'm using iPXE with iBFT configured to boot LiveOS from this target, all fine. Now I'd like to install Fedora on the remainder of the same iSCSI target (30GB), for some reason it isn't available as a installation target and when I try to add the iSCSI target the following message is shown: Failed to call Login method on /org/freedesktop/UDisks2/Manager with ('iqn...') arguments: GDBus.Error:org.freedesktop.UDisks2.Error.Failed: Login failed: initiator reported error (15 - session exists). I guess Anaconda doesn't allow to install on the device where it booted from, is there a way to workaround this? Thanks for your reply! Dick Marinus

2 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel June 2020