Anaconda-devel September 2017

anaconda-devel@lists.stg.fedoraproject.org

9 participants
5 discussions

x86 SIG / Dropping PAE support
by Jeff Backus 04 Nov '17

04 Nov '17

Hi List, I wanted to reach out to you to let you know that we have established an x86 SIG in an effort to help address x86-related issues in Fedora. To help keep track of such issues, we have two x86-related tracker bugs: * One for General x86-related issues: https://bugzilla.redhat.com/show_bug.cgi?id=1489998 * One for x86 ExcludeArch-related issues: https://bugzilla.redhat.com/show_bug.cgi?id=179258 Please feel free to also reach out to us via the x86 mailing list(x86(a)lists.fedoraproject.org) or via the #fedora-x86 IRC channel. Also, I wanted to let you know that we have decided to drop PAE support. I believe the kernel team has already disabled it for F27. They pointed out that this may affect Anaconda as well. And that the Lorax templates may need to be updated? Thanks! jeff -- Jeff Backus jeff.backus(a)gmail.com http://github.com/jsbackus http://gitlab.com/jsbackus

5 12

Historic and current issues with filesystem tools?
by Jan Tulak 02 Oct '17

02 Oct '17

Hi guys, I'm looking for historic and current issues Anaconda had with filesystem tools which don't have a nice API. For example, some tool getting stuck because it waits for a confirmation which never comes, output that was difficult to parse and led to some errors, that kind of things. I'm trying to get some real data on where (or if) it is worth to put an effort into making those tools more computer-friendly, so if you remember anything, let me know. I tried to find something in bugzilla, but Anaconda has too many issues there to read them all (even historical, already fixed issues are good as examples, or to identify tools which have the most problem). If you remember anything, let me know. Thanks. :-) Cheers, Jan

3 2

Mandatory user spoke
by Cristian Stan 02 Oct '17

02 Oct '17

Hello all, I have an issue I could not fix by myself so far: We have a custom Fedora build. After the base Anaconda install, Initial Setup runs with two spokes, one with a custom add-on, and the user creation spoke. Our issues are with the default user creation spoke; we should both enable by default the 'Make this user administrator' checkbox and make the user creation mandatory, so that the setup may not be exited without creating a user. I've even tried disabling altogether the user creation spoke to be able to run my own user creation add-on. I've had no luck so far. What I've tried until now: To enable by default 'Make this user administrator' I have: * modified the 'c_admin' object in user.glade to enable it by default * tested separately the 'c_admin' user.glade object in Glade Interface Designer (it works, as expected) * tested the 'c_admin' modification on 'c_usepassword' (to isolate the issue; the same setting for one object does not work for the other) To make the original user creation spoke in Initial Setup mandatory I have: * modified the '_checkUsername' method from user.py, class 'UserSpoke' (Anaconda sources) All the modifications were performed after Anaconda's first stage and before running Initial Setup. Do you have any ideas about this and how should I proceed? Thank you, your help is greatly appreciated! Cristian Stan

2 1

logging mount assembly and bootloader install, chroot missing?
by Chris Murphy 15 Sep '17

15 Sep '17

The program.log shows mount commands for assembly, followed by installation itself copying files to a path prefix /mnt/sysimage, and then bootloader setup. Isn't there a chroot happening before the bootloader setup? It's not in the log so I'm having some difficulty exactly replicating an installation environment while troubleshooting this bug: So the questions are: Is there a chroot? Is there a way to discover the command being used? And if there is a chroot, is there a way to log this command in the future? https://bugzilla.redhat.com/show_bug.cgi?id=1289752 Thanks, -- Chris Murphy

4 3

default kickstart configuration (beyond interactive-defaults.ks)
by Colin Walters 15 Sep '17

15 Sep '17

I'd like to fix: https://pagure.io/atomic-wg/issue/226 Right now for Atomic Host, we embed the ostree content inside the squashfs, with the goal that users of the ISO don't have to hit the network. We hook bits into interactive-defaults.ks; see this change for how it works: https://pagure.io/fedora-lorax-templates/c/e34c371501d6eac75925aae86bd737c8… However, if one wants to then extract the ISO to do a kickstart install, the user must repeat the `ostreesetup` bits: https://lists.fedoraproject.org/archives/list/cloud@lists.fedoraproject.org… Specifically from his attachment: ostreesetup --osname="fedora-atomic" --remote="fedora-atomic" --url="file:////run/install/repo/content/repo" --ref="fedora-atomic/25/x86_64/docker-host" --nogpg which is really internal implementation details that I'd like the ability to change without breaking people's kickstarts, and conversely not require them to specify by default. Are there any facilities today for a "default kickstart" like /usr/share/anaconda/interactive-defaults.ks, except not just interactive?

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