Anaconda-devel June 2019

anaconda-devel@lists.stg.fedoraproject.org

7 participants
4 discussions

adding PowerNV as a new PPC machine type in the installer (rhbz#1303219)
by Dan Horák 26 Jun '19

26 Jun '19

Hi, there is a request for not installing the PReP partition on PPC system that don't really require it in bug 1303219 [1]. I've spend some time working on it and I think I have the solution, see [2] for details. Because the testing requires a bare-metal Power machine I'm now thinking how to allow testing it with the community in the least intrusive way. Right now my plan is to have the anaconda PR merged and use an updates.img for the corresponding blivet change. This way anaconda itself should work as before and only when used with the updates.img it should change the behaviour. What do you think? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1303219 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1303219#c5 With regards, Dan

3 5

"enabling zram.service on LiveOS boots"
by Chris Murphy 21 Jun '19

21 Jun '19

Hi, Fedora Workstation WG agreed some time ago to enable zram.service when booting LiveOS, which is already the behavior for netinstalls. https://pagure.io/fedora-workstation/issue/56#comment-546837 How should this be done? On netinstall boot I see zram.service is loaded, active, and executed /usr/libexec/anaconda/zramswapon by I think anaconda itself starts this service. On LiveOS boot I see zram.service is loaded, inactive. I thought about changing zram.service to add ConditionKernelCommandLine=rd.live.image But that'd break the netinstall case. It could also be done by making only the LiveOS kernel command line include 'systemd.wants=zram.service' And still another option is I'm seeing there are two of these, at least in Rawhide Lives. [root@localhost-live ~]# systemctl list-unit-files | grep zram zram-swap.service disabled zram.service static [root@localhost-live ~]# zram.service is part of the anaconda package, and zram-swap.service is part of zram-0.3-1.fc30.noarch It's not yet determined if installed Workstation systems will change default behavior to swap on zram, zswap, or something else. Thanks, -- Chris Murphy

4 4

On disk repos, anaconda, and Installation Source
by Pat Riehecky 19 Jun '19

19 Jun '19

I noticed an unexpected behavior in Fedora 30. The net install disk for Workstation ships with the 'fedora-cisco-openh264' repo on the media. However, the repo is not listed under the 'Installation Source' spoke. Should this repo be loaded into the addons list? I suppose this is a bit of confusion based on this comment [1], vs the actual behavior where only `.treeinfo` repos that are also on disk get enabled [2] Thoughts? Pat [1] https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/payload/dnfp… [2] self.addons seems to be populated via __init__.py and what it finds in `.treeinfo` I think. https://github.com/rhinstaller/anaconda/blob/master/pyanaconda/payload/dnfp… -- Pat Riehecky Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

3 3

Re: Question on Anaconda rpmostree payload
by jkonecny＠redhat.com 06 Jun '19

06 Jun '19

Good point. Adding Anaconda devel list. The community could be interesting on this. Jirka On Tue, 2019-05-28 at 14:29 -0400, Colin Walters wrote: > Adding Dusty and Jonathan. > > Can we take this thread to anaconda-devel@ ? No reason not to > discuss in public AFAICS, and this way conversation is archived for > historical purposes, etc. > > On Tue, May 28, 2019 at 1:04 PM <jkonecny(a)redhat.com> wrote: > > Hello, > > > > > > > > We are doing bigger rewrite of the Anaconda and we have a problem > > with > > > > the moving sysroot of rpmostree payload. As you know the payload > > more > > > > then we and most of all you know rpmostree I wanted to ask you > > about > > > > the solution. > > > > > > > > Right now the sysroot of the rpmostree is changing during the > > > > installation. The code for the sysroot handling changed and we > > would > > > > like to simplify the logic, by having the sysroot on static place > > all > > > > the time. > > > > > > > > From the commit message I know there is a deployment and physical > > root. > > > > The problem is however that you have to change to the other during > > the > > > > installation. We would like to avoid this. > > > > > > > > If we can avoid changing the sysroot that would be best but in > > other > > > > case I came with an idea of a bind mount. So when the mount is not > > in > > > > the "correct" place we can bind mount the other folder there. > > > > However, that could complicate other things. > > > > > > > > > > > > Could you please give a suggestion for this? > > > > > > > > > > > > Thanks, > > > > Jirka > > > > > >

3 2

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 2019