Anaconda-devel June 2012

anaconda-devel@lists.stg.fedoraproject.org

35 participants
112 discussions

Ability to install to loopmounted filesystem - mentor wanted
by Tirtha Chatterjee 02 Dec '12

02 Dec '12

Hello. I am trying to implement something like Wubi on Fedora. For this, I first need to make it possible to install to loopmounted filesystems through anaconda. I don't think a lot of modification to the existing source code is required. I tried going through the source code, but it seemed quite big to manage without some guidance. I would be extremely happy if someone guided me on this. Hoping for an affirmative reply :-) -- Regards Tirtha Chatterjee KDE developer http://wyuka.co.cc/

2 3

[newui] Remove scdate usage and have timezone only in ksdata
by Vratislav Podzimek 07 Aug '12

07 Aug '12

PATCH 1/2 removes the last piece of live code that uses the system-config-date (note that there still is the old GUI code using the scdate's timezone map). However, I didn't find scdate as a dependency in anaconda.spec.in nor in lorax templates for the installation runtime environment. How it gets to the install image? PATCH 2/2 does basically two things: 1) It removes the Timezone class used in the anaconda object for timezone data replacing it with the code using ksdata as the only sctructure storing data and execute method of the Timezone pykicstart command. 2) It moves some pieces of code from the localization module to the separate timezone module adding a function for writing timezone configuration. This function is based on the old one from the Timezone class. I have just replaced copying timezone file to the /etc/localtime with creating a symlink because this way it is easy to find out which timezone the system is using. -- Vratislav Podzimek

4 10

[PATCH anaconda/master] Add support to determine the ARM processor variety and select the correct kernel to install.
by David A. Marlin 20 Jul '12

20 Jul '12

Attached is my latest version of the ARM processor variety patch. It incorporates suggestions made previously, and was made against anaconda/master (but applied to 17.29 for testing). I simplified the hash/lookup by consolidating some machine types, but I understand this may still be unacceptable. I am currently tracking master and carrying these patches locally. I keep the rpms in a local repo for testing. We are working on a method of exposing the platform in userspace, but that is not in place yet. Would it be possible to accept this as an interim solution with the expressed intent that the hash would be removed as soon as an alternative solution is available? If not, would a version of this patch with the hash/lookup stubbed out be acceptable? I would like to get as much of this upstream as possible, to minimize the patch(es) I need to carry locally and simplify keeping up with master. Any suggestions are appreciated. Note: We successfully completed a test kickstart install on an ARM system today using the modified anaconda-17.29. d.marlin

6 12

noloader: create default ifcfg files already in dracut
by Radek Vykydal 18 Jul '12

18 Jul '12

Hi, this proposition is mainly for Will. Currently we create missing default ifcfg files (i.e. file of devices not activated in dracut or configured by kickstart) in anaconda: commit e1c287f31dcec4c661272f852e14f5d6925f92d2 Author: Will Woods <wwoods(a)redhat.com> Date: Wed Mar 21 20:02:46 2012 -0400 Create default ifcfg-* for each interface (#804504, #804716) Loader used to create a default ifcfg-* file for each unused network interface, containing DEVICE, HWADDR, UUID, BOOTPROTO=dhcp, etc. Network.update() populated self.netdevices by reading those files, *skipping any interface that lacked that file*, which caused the vnc traceback in bug #804504. And without BOOTPROTO=dhcp, "ifup $dev" didn't work post-install, which caused #804716. (Personally I think "ifup" should fall back to the same defaults as NetworkManager rather than making us write the defaults to a file, but we'll save that for later.) This has a problem that NetworkManager activates default connections for devices lacking ifcfg file which differs from behaviour in rhel6 and I think we don't want to start to do this. Perhaps we could run anaconda pre-pivot hook (post pre-pivot/85write-ifcfg.sh) that would take care of missing ifcfg files. What do you think? Should I try to come up with an anaconda dracut patch? Also I'd like to bring back functionality of --activate option, but activation of additional devices could be done in anaconda kickstart processing, even though doing that in dracut might be as simple as writing ONBOOT=yes by dracut/ks to ifcfg file. Radek

2 3

Coordinating https://fedoraproject.org/wiki/Features/InitialExperience with firsboot, anaconda
by Miloslav Trmač 05 Jul '12

05 Jul '12

Hello, it seems that not all relevant parties have been talking to each other; if anyone else should be involved, please add them. In short, a new Fedora feature https://fedoraproject.org/wiki/Features/InitialExperience was proposed, replacing firstboot for the GNOME spin (only) and integrating per-system and per-user configuration. The original suggestion was for non-GNOME spins (including the DVD installation) would continue using firsboot. Now it turns out that anaconda plans to do more setup during the initial installation (including setting up the clock and adding an initial user), perhaps making all of firstboot unnecessary on non-live installations. OTOH for live-{CD,DVD} installations, the same clock/user screens would be displayed in firstboot, sharing the code; if "initial experience" plans to support firstboot screens, this (and the presumed firstboot module API changes) would affect it. Can you all talk to each other and figure out a definite plan, please? The integrated nature of IE goes against the "one installed system with multiple installed desktop environments" concept, which is sort of acceptable as long as both IE and firsboot have active maintainers, but asking the user about the same things both in anaconda and IE wouldn't do. * Which settings/screens happen in anaconda? * Which settings/screens move between anaconda and firsboot/IE (and using what mechanism)? * Which settings/screens happen both in firstboot and IE (and on which installation paths)? What code will be shared? * Which settings will be governed by each desktop environment individually? How does the transition between per-system and per-user settings happen if IE doesn't want the user to log in during the process? * Which parts of the GNOME stack will have to be installed on non-GNOME spins, or from the installation DVD when installing a non-GNOME desktop only? (and other things that I might have forgotten) Thank you, Mirek

7 6

Parsing shell-style config files
by Will Woods 02 Jul '12

02 Jul '12

So here's my shellconfig.py, presented for comment / inspiration. A couple notes: * This is an interesting construct that I wasn't aware of: def quote(s): for c in s: if c not in _safechars: break else: return s ... Apparently, if you have an 'else:' block after 'for:', it gets executed if you 'break' out of the loop. Neat! But _parseline is really the interesting part: def _parseline(self, line): s = line.strip() if '#' in s: s = s[:s.find('#')] # remove from comment to EOL s = s.strip() # and any unnecessary whitespace key, eq, val = s.partition('=') if self.read_unquote: val = unquote(val) if key != '' and eq == '=': return (key, val) else: return (None, None) * You want to remove the comment before the partition(), otherwise this line would end up with a weird value: GRAPHICS="vnc" # other choices: "spice", "none" * quote() and unquote() use pipes._safechars and shlex.split(), respectively. * pipes.quote() doesn't work because it puts single-quotes around '$', assuming that the given string is a literal filename * There's no write() method but it's pretty obvious - you'd just open a file and do f.write(str(config)) or similar. Hope that's useful to somebody, -w

2 1

[newui] Stacking windows of processes run by anaconda (e.g. nm-c-e)
by Radek Vykydal 29 Jun '12

29 Jun '12

The problem is that clicking on spoke/lightbox pulls the spoke/lightbox above nm-c-e window. I tried these approaches to cope with it: 1) Embedding nm-c-e window in anaconda using Gtk.Socket, Gtk.Plug. This requires patch in nm-connection-editor (adding plug). I made simple POC patch adding --socket XID option to nm-c-e (XID is id of socket window created in anaconda). Embedding the window in our UIObject we can e.g make screenshots and control other things. For main connection editor window it works nice even with lightbox. The problem is that other windows created by nm-c-e (e.g. routes dialog) stay owned by nm-c-e process and therefore are stacked below spoke after cliking on it. Also this can't probably be used easily for secret agent's dialogs (wifi authentication) which are run by dbus service. 2) Setting keep_below hints of windows. With hub, spoke, and lighbox we'd need to set it in this order: 1. lightbox 2. spoke 3. hub which means we need access hub from spoke (in the moment when lightbox is created). Without lighbox we could set the parameters already in hub before running a spoke. Or we can hide hub before displaying spoke and show it after it is destroyed, but it makes transition between hub and spoke not smooth (kind of flashing). I am sending raw patch for this last approach (with hiding of hub window) - "Keep nm-c-e-windows...". NMCEEmbedder class is what remained of UIobject using socket/plug (approach 1) - see the second patch "Embed nm-c-e...". It does not make much sense to use UIObject in this case, but strangely when I try to use just function (the third patch) I get this error when accessing lightbox object in the third patch (applied on top of the first one) "Use function...": Fatal Python error: PyEval_SaveThread: NULL tstate Any ideas, comments, hints? Can we hide the hub (perhaps there is finer way to do it, i.e. in callback after spoke is realized...)? Or perhaps we could try to tame our window manager somehow? Radek

2 4

[PATCH] Check all network devices to get an IP address
by Gustavo Luiz Duarte 28 Jun '12

28 Jun '12

It also prevents a crash when no IP address is found. --- pyanaconda/vnc.py | 10 +++++++--- 1 files changed, 7 insertions(+), 3 deletions(-) diff --git a/pyanaconda/vnc.py b/pyanaconda/vnc.py index a7ccc76..000c9fc 100644 --- a/pyanaconda/vnc.py +++ b/pyanaconda/vnc.py @@ -84,8 +84,8 @@ class VncServer: active_devs = network.getActiveNetDevs() self.ip = None - if active_devs != []: - devname = devices[active_devs[0]].iface + for dev in active_devs: + devname = devices[dev].iface try: ips = (isys.getIPAddresses(devname, version=4) + isys.getIPAddresses(devname, version=6)) @@ -97,6 +97,10 @@ class VncServer: log.info("IPs (using first) of device %s: %s" % (devname, ips)) self.ip = ips[0] + break + + if not self.ip: + self.log.warning("No IP address found. You may not be able to connect to VNC server.") ipstr = self.ip @@ -110,7 +114,7 @@ class VncServer: if len(hinfo) == 3: self.name = hinfo[0] - if self.ip.find(':') != -1: + if self.ip and self.ip.find(':') != -1: ipstr = "[%s]" % (self.ip,) if (self.name is not None) and (not self.name.startswith('localhost')) and (ipstr is not None): -- 1.7.7.6

2 3

after install of new Linux ISO with new kernel&initrd, could not boot
by zf5984599 28 Jun '12

28 Jun '12

hi, dear experts When I made my own centOS Linux ISO with new compiled kernel and initrd.img by myself. I met one problem. there is some relation with anaconda, so i turn to ask for help here. Here are steps: 1）build one kernel RPM with compiled kernel and initrd.img in the ISO. 2) when install the new centOS Linux ISO, the installation is fine. 3) after installation, it is not able to reboot, because grub "menu.lst" is broken. There is no "initrd initrd.img" line in menu.lst file. The OS could not boot normally. My questions: Q) since the menu.lst/grub.conf is generated by anaconda, I am wondering that there is something wrong when the anaconda generating the grub menu.lst? Is that something wrong with my kernel name induced this ? Many thanks for your help. BRs feng

2 1

Rescue mode
by Martin Sivak 27 Jun '12

27 Jun '12

Hi, I'd like to start discussion about the rescue mode purpose and look in the newui environment. Currently we have just a shell encapsulated in very simple menu (with the possibility of calling firstaidkit tasks .. of which we have about two working..). I see the following common use cases: 1) Somebody with a hosed bootloader, but the system and hardware are OK 2) Somebody who needs to do partitioning stuff to fix something 3) Reseting root password for users who forgot 4) Real rescue when hardware fails (including a graphic card malfunction) 5) Rescue tasks for corporate customers using serial console hardware (with possibly not working NICs or network) 6) Our QA sometimes used kickstarted rescue to do testing tasks (commonly in virt environment with no NICs) I suppose we could use the hub and spoke model for the first three cases, but the fourth and fifth one is going to be harder. We cannot rely on GUI when the cause might be in graphic adapter (or there is no adapter at all). So tell me what you think or if you know more use cases. -- Martin Sivák msivak(a)redhat.com Red Hat Czech Anaconda team / Brno, CZ

5 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 2012