Anaconda-devel December 2012

anaconda-devel@lists.fedoraproject.org

30 participants
21 discussions

Anaconda threads and Yum with rpm backend
by Martin Sivak 13 Dec '12

13 Dec '12

Hi, while working on #876716 I came over a particularly nasty issue we have in our packaging code. We execute everything in a thread while other threads are letting the user setup his system. Unfortunately, RPM chroots immediately at the beginning of the install transaction. As we use Yum in a library form and Yum is using RPM also as a library.. well the process that gets suddenly chrooted is anaconda itself. This situation disrupts the environment anaconda uses for work and most of the stuff stops working (because all the files we do not have handle to are suddenly missing). It is not too visible atm as we have a bare minimum of customization screens (only password). But we (and other teams) will be adding more and this will get progressively worse to workaround. I have talked to Panu about libRPM and while he agreed with me that calling chroot or exit in a library is an evil thing, he also said that there is not much that can be done on the RPM side, because some internal mechanisms like lua scripts need the root to be changed this way. That leaves to pieces where we can fix this: Yum: - yum could be modified to for a new process for the RPM transaction and use stdin/out for status reporting. - this would keep API for other apps using Yum (and would be the cleanest solution as far as I can tell) Anaconda: - we could workaround this by forking a child process with the Yum call and do the same thing - this would fix only anaconda and wold be essentially workarounding a behaviour of a library we do not directly use The question here is.. how hard is it to modify Yum to isolate the chroot away from the user (Anaconda) and it is feasible for F18? -- Martin Sivák msivak(a)redhat.com Red Hat Czech Anaconda team / Brno, CZ

6 17

Hostname setting in UI?
by Radek Vykydal 12 Dec '12

12 Dec '12

Hi, we still don't have hostname setting in new UI. There is a bz for f18: https://bugzilla.redhat.com/show_bug.cgi?id=856456 Originally it was placed on user account screen mockup: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/ToPrint/01Oct20… but we need to set it before storage is applied as it is used for default LV and perhaps RAID names. So obviously network spoke comes up to mind. Still, in case network is up we skip standalone network spoke. How would we guide user to set hostname first if he wants to have his LVs named accordingly? Perhaps some hint in partitioning spoke? Radek

8 27

requirement to (re)format volumes when installing
by Chris Murphy 11 Dec '12

11 Dec '12

There are problems with the requirement to format volumes in anaconda (either autopart or Manual Partitioning.) 1. To properly install to hardware RAID 0, 10, 5, 6, I effectively have to learn kickstart. I can properly create the volumes myself, informing the file system at make time what the chunk and stripe width are. The anaconda requirement to reformat in this case is unreasonable. 2. It makes Fedora 18 unfriendly with existing, and its own Btrfs volumes. Existing btrfs volumes, including Fedora 18 installs, legitimately place home in a subvolume. There are other legitimate uses for subvolumes including installing entirely different distributions, user and OS snapshots, etc. The reformat policy demands either that I obliterate all of these, or learn kickstart, and I find this short term hostile and long term untenable for Btrfs. 3. The policy complicates the UI/UX of the Installation Destination spoke. Both basic and advanced users can benefit from a simplified point and shoot UI: select a pre-formatted volume, click an install button. Two clicks and installation commences. This is how 95% of the world's desktop OS's work by default, yet it cannot be done in anaconda at all. Unless I learn kickstart. I am new to oldUI and newUI, I prefer newUI by a lot except for Installation Destination which I think is unnecessarily complicated and hindered by the lack of a point and shoot UI. I should be able to pick volumes by default, not disks, when there are only one or two disks available on the whole system. It's legitimate to disqualify a volume as an install target if it has an invalid file system that doesn't pass fsck, and some other reasonable parameters. But the present behavior I find weird and unreasonable because in effect anaconda is saying "no you can't use other tools and have me install there, only through me do you get any kind of installation." Chris Murphy

3 3

Re: Enterprise storage support in Anaconda for 18
by MANIK BAJPAI 09 Dec '12

09 Dec '12

Hi, This is in reference to the mailing list snapshot given below. I understand that by advanced device filtering we mean the capability given to the user to select a particular disk, with a particular Filesystem type, for a particular mount-point. Say if the user wanted to select /dev/dasdb2 to be formatted as ext2 (or reiserfs or anything), use mount-point "/var" for it, and choose the capacity to his/her will. I just wanted to know whether the F-17 like device filtering is to be _totally done away with_(Y/N), never to be seen again? If that is positively the case, then what about the users who want to use a particular (say a high speed disk for low latency), for a particular mount point? Or in other words what about the users who want to 'hand-customize' the device partitions, and mount points. -- -With regards, Manik Bajpai. IBM Systems & Technology Labs, D Block, 6th Floor, Embassy Golf Links Business Park, Bangalore 560071, INDIA Email (Read opposite) : MOC MBI TENV XUNIL ta pjabinam On 12/6/2012 10:30 PM, anaconda-devel-list-request(a)redhat.com wrote: * Put advanced storage (filtering, multipath/iscsi/zfcp dialogs) back in." It would be good to know for us in QA to what extent ( if any gui/textmode/kickstart etc ) enterprise storage support is in F18 since the lack of it affects the following final criteria [2] "6. The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel) " 1.https://www.redhat.com/archives/anaconda-devel-list/2012-November/msg0007… 2.http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria Basically, anything that does not require user intervention ought to work. The advanced device filtering screen we had in F17 and earlier is obviously out, though I don't think there were test criteria for it. We previously had a dialog that allowed you to log into an iSCSI thing and make anaconda aware of it, as well as dialogs that allowed you to connect ZFCP and FCOE devices. There's no dialog for that right now, so you can't do it interactively. Doing these things via kickstart still ought to work, though I do not know that it's received any testing. Note that adding these things back in is my highest priority post-F18. - Chris

1 0

Enterprise storage support in Anaconda for 18
by "Jóhann B. Guðmundsson" 07 Dec '12

07 Dec '12

Greetings Based on Chris note in [¹] " * Put advanced storage (filtering, multipath/iscsi/zfcp dialogs) back in." It would be good to know for us in QA to what extent ( if any gui/textmode/kickstart etc ) enterprise storage support is in F18 since the lack of it affects the following final criteria [2] "6. The installer must be able to complete an installation using any network-attached storage devices (e.g. iSCSI, FCoE, Fibre Channel) " 1.https://www.redhat.com/archives/anaconda-devel-list/2012-November/msg0007… 2.http://fedoraproject.org/wiki/Fedora_18_Final_Release_Criteria JBG

4 6

anaconda installing packages specified as "no-install"
by Brian J. Murrell 06 Dec '12

06 Dec '12

I have a kickstart file which specifies in it's package selection (amongst other things of course): -kernel-debug foo-modules where foo-modules "requires": kernel = 2.6.32-279.2.1.el6 Yet Anaconda still insists on installing the "kernel-debug" package to satisfy this requirement and not the non-debug "kernel" package of the same version. How can I convince Anaconda to use the "kernel" package instead of the kernel-debug package. I suspect I could probably explicitly list "kernel-2.6.32-279.2.1.el6" in the package list but I am sure you an imagine how much I want to avoid hard-coding package versions into a kickstart file. Cheers, b.

1 0

f18-branch is now live
by Brian C. Lane 05 Dec '12

05 Dec '12

I've created a f18-branch for the remaning few (<G>) bugs for f18. We can start pushing f19 bugs to master now. Freeze is on 12-11, so we should only be pushing blocker fixes to f18-branch. I'd like to see if we can keep master in something like a working state. In the past between releases master tends to get patches but no builds (or media). I'll start doing regular builds from it using 19.1 sometime this week. Maybe we can modify clumens' scripts to also make test iso's based on it. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

1 0

Using Anaconda to install an embedded distro
by Pedro I. Sanchez 05 Dec '12

05 Dec '12

Hello, I have my own embedded Linux distro and I'd like to have an installer program to install the binaries of my distro on a target hard drive (I can generate my own rpm repo). I'm considering Anaconda as the potential installer program but I'd like to fire a couple of questions on this list first. 1. Let's assume that the installer's live environment, say as created with livecd-creator, runs Fedora. Say also that I want to use anaconda inside this live environment to install my embedded distro (by specifying my own rpm repo via the inst.repo option). How much of the Fedora run time will anaconda attempt to configure into the target hard drive? I mean for example, things such us systemd configuration stuff which my embedded distro does not use. How difficult would it be to get anaconda to make a "clean" installation (no Fedora-ish stuff on the target, just my embedded distro)? 2. Would it make more sense to create a live environment running my embedded distro, and then attempt to get anaconda running there to do the binary installation? I would appreciate any comments. Thank you, -- Pedro

1 0

lots of feedback on the test-list
by Kamil Paral 03 Dec '12

03 Dec '12

Hello, since the Fedora 18 Beta release there is a lot of general users feedback on the test list [1]. A large portion of that is related to Anaconda. One of the reasons why we see a lot of feedback there is that this list is recommended to all the users on the official download page [2]. It would be a shame if the Anaconda feedback went unnoticed just because the developers are not subscribed to that list. I recommend all of you to subscribe to test-list, or at least read the archives periodically, to see what parts of NewUI are the most problematic ones for our users. Your response to some of the questions would also be appreciated. Thanks. [1] https://lists.fedoraproject.org/mailman/listinfo/test [2] https://fedoraproject.org/en/get-prerelease

8 12

using a raid as one disk of a another raid in kickstart file
by Oguz Yilmaz 03 Dec '12

03 Dec '12

Hello, I am trying to use anaconda kickstart file to ready my target raid scheme. I will make /tmp as Raid 0+1 which will be made of md0 (sdb+sdc) and sdd. Kickstart should firstly create md0 as raid0 type and then usethis md0 and fourth disk sdd to create a raid partition. Then md1 will be used to create /var. For this purpose, I added "/dev/md0" as first disk and raid.03 as second disk of this raid. Then anaconda gives the error "Tried to use undefined partition /dev/md0 in RAID specification". Line 55 is "raid /tmp --level=1 --device=md2 /dev/md0 raid.03" The error Anaconda has given is also below.I think for raid part, anaconda wants a partition that he created with part. As developers and advanced users, Do you see any way to reach this aim? clearpart --all --initlabel part raid.01 --size=10000 --ondisk=sdb part raid.02 --size=10000 --ondisk=sdc part raid.03 --size=10000 --ondisk=sdd # swap part swap --size=2048 --ondisk=sdb part swap --size=2048 --ondisk=sdc part swap --size=2048 --ondisk=sdd # /var part raid.11 --size=1 --grow --ondisk=sdb part raid.12 --size=1 --grow --ondisk=sdc part raid.13 --size=1 --grow --ondisk=sdd part / --fstype ext3 --size=100 --grow --ondisk=sda --asprimary --label=/ raid /tmpmd0 --level=0 --device=md0 raid.01 raid.02 raid /tmpmd1 --level=0 --device=md1 raid.11 raid.12 #line55 raid /tmp --level=1 --device=md2 /dev/md0 raid.03 raid /var --level=1 --device=md3 /dev/md1 raid.13 +----------------+ Error Parsing Kickstart Config +-----------------+ | The following error was found while parsing your kickstart | | configuration: | | | | The following problem occurred on line 55 of the kickstart file: | | | | Tried to use undefined partition /dev/md0 in RAID specification | .... +-------------------------------------------------------------------+

2 1

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel December 2012