Anaconda-devel April 2008

anaconda-devel@lists.stg.fedoraproject.org

26 participants
28 discussions

Filling in the gateway address
by Mark Hamzy 05 Apr '08

05 Apr '08

I've been asked to look into calculating at least something to fill in for an initial stab at a gateway address. I know you can't determine what the real router's address is. But you could get the user at least close. What do y'all think about that in general? For the IPv4 case, if there is one network, then you could use the network address, mask it off, and then use the first address. If there is more than one network, then use the first one? Mark Common Information Model/Web-Based Enterprise Management at http://www.openpegasus.org/ Take a look at the Linux Omni Printer Driver Framework at http://omniprint.sourceforge.net/

4 3

Re: Re: Filling in the gateway address
by Mark Hamzy 04 Apr '08

04 Apr '08

> On Fri, 2008-04-04 at 09:45 -0500, Mark Hamzy wrote: > > I've been asked to look into calculating at least something to fill in > > for an initial stab at a gateway address. I know you can't determine > > what the real router's address is. But you could get the user at least > close. What do y'all think about that in general? > We used to do it, you're always wrong about half the time. Some people > use the first, some use the last. It's just not something that you can > guess. Okay, I can understand that. How about in the case where there is just one interface defined? For example, given an IP address of 9.53.40.25 and a netmask of 255.255.255.0, how about filling in just "9.53.40."? That way, the user has to complete the gateway IP address or they will receive an error dialog. Mark Common Information Model/Web-Based Enterprise Management at http://www.openpegasus.org/ Take a look at the Linux Omni Printer Driver Framework at http://omniprint.sourceforge.net/

2 1

[PATCH] Support encrypted RAID member devices. (#429600)
by David Lehman 04 Apr '08

04 Apr '08

When creating the RAIDDevice instance, pass in Device instances (as opposed to device names) for the members list. This way we have all the information we need to set up the RAID, including encryption stuff. Previously we instantiated Devices for the RAID members in the setupDevice method. Now we just use the preexisting Device instances from the member RequestSpecs. --- fsset.py | 24 +++++++++++------------- partRequests.py | 3 ++- 2 files changed, 13 insertions(+), 14 deletions(-) diff --git a/fsset.py b/fsset.py index 34259dd..0f34859 100644 --- a/fsset.py +++ b/fsset.py @@ -2362,7 +2362,7 @@ class RAIDDevice(Device): self.crypto.setDevice(self.device) # make sure the list of raid members is sorted - self.members.sort() + self.members.sort(cmp=lambda x,y: cmp(x.getDevice(),y.getDevice())) def __del__ (self): del RAIDDevice.usedMajors[self.minor] @@ -2414,13 +2414,13 @@ class RAIDDevice(Device): entry = entry + "persistent-superblock 1\n" entry = entry + "nr-spare-disks %d\n" % (self.spares,) i = 0 - for device in self.members[:self.numDisks]: + for device in [m.getDevice() for m in self.members[:self.numDisks]]: entry = entry + " device %s/%s\n" % (devPrefix, device) entry = entry + " raid-disk %d\n" % (i,) i = i + 1 i = 0 - for device in self.members[self.numDisks:]: + for device in [m.getDevice() for m in self.members[self.numDisks:]]: entry = entry + " device %s/%s\n" % (devPrefix, device) entry = entry + " spare-disk %d\n" % (i,) @@ -2428,13 +2428,10 @@ class RAIDDevice(Device): return entry def setupDevice (self, chroot="/", devPrefix='/dev'): - def devify(x): - return "/dev/%s" %(x,) - if not self.isSetup: - for device in self.members: - pd = PartitionDevice(device) - pd.setupDevice(chroot, devPrefix=devPrefix) + memberDevs = [] + for pd in self.members: + memberDevs.append(pd.setupDevice(chroot, devPrefix=devPrefix)) if pd.isNetdev(): self.setAsNetdev() args = ["--create", "/dev/%s" %(self.device,), @@ -2445,16 +2442,17 @@ class RAIDDevice(Device): if self.spares > 0: args.append("--spare-devices=%s" %(self.spares,),) - args.extend(map(devify, self.members)) + args.extend(memberDevs) log.info("going to run: %s" %(["mdadm"] + args,)) iutil.execWithRedirect ("mdadm", args, stderr="/dev/tty5", stdout="/dev/tty5", searchPath = 1) - raid.register_raid_device(self.device, self.members[:], + raid.register_raid_device(self.device, + [m.getDevice() for m in self.members], self.level, self.numDisks) self.isSetup = 1 else: - isys.raidstart(self.device, self.members[0]) + isys.raidstart(self.device, self.members[0].getDevice()) if self.crypto: self.crypto.formatDevice() @@ -2471,7 +2469,7 @@ class RAIDDevice(Device): elif not asBoot: return self.device else: - return self.members[0] + return self.members[0].getDevice(asBoot=asBoot) def solidify(self): return diff --git a/partRequests.py b/partRequests.py index 0b77e4c..cf83b25 100644 --- a/partRequests.py +++ b/partRequests.py @@ -690,7 +690,8 @@ class RaidRequestSpec(RequestSpec): # Alway return a new device for minor changing raidmems = [] for member in self.raidmembers: - raidmems.append(partitions.getRequestByID(member).device) + request = partitions.getRequestByID(member) + raidmems.append(request.getDevice(partitions)) self.dev = fsset.RAIDDevice(int(self.raidlevel[4:]), raidmems, minor = self.raidminor, spares = self.raidspares, -- 1.5.4.1

2 1

[PATCH] mkinitrd support for encrypted RAID member devices
by David Lehman 04 Apr '08

04 Apr '08

This is the companion patch to handle encrypted RAID members in mkinitrd.

1 1

on creating driver disks
by John Summerfield 03 Apr '08

03 Apr '08

I had in mind the idea of doing a network install of CentOS5. The primary impediment is that the target machine's going to be wireless just as soon as I stick my wireless card in it. Support for the card's not an issue, the prism54 driver in Ubuntu Warty's been working fine for years. What I think I would like is a driver disk. Not really knowing how to create one, I asked Google. Google is full of helpful advice "download dd.img and write it to a floppy" that misses the mark, and I found Doug Ledford's kit and comments which is a bit nearer the mark, but not really. I've read through it and got a bit of an idea, but I think it's not going to work. I need the driver (and I'm supposing I have a suitable one already built, but if not then I _can_ address that), and I need to load firmware for the wireless card. Now I'm sure I can open up the initrd and add the necessary magic, but that doesn't seem the One True Way. In the interests of getting this working before me cheese gets back, I'm going to work around the issue, but it does raise some questions" 1. Is Doug's documentation the best there is? 2. Assuming I popped the right prism53.ko and appropriate files (including firmware) on to a floppy disk in the proper layout, would it actually work? 3. Where is the layout of the disk described? 4. Where is the content of the support files described? -- CU John -- Cheers John -- spambait 1aaaaaaa(a)coco.merseine.nu Z1aaaaaaa(a)coco.merseine.nu -- Advice http://webfoot.com/advice/email.top.php http://www.catb.org/~esr/faqs/smart-questions.html http://support.microsoft.com/kb/555375 You cannot reply off-list:-)

3 3

[PATCH] Add gnome-applets to the upgrade blacklist as it is no longer multilib in F9
by Jesse Keating 03 Apr '08

03 Apr '08

It was multilib in F8 and so many F8 systems will have a .i386 and .x86_64 version installed. We want to remove the i386 version upon upgrade. --- upgrade.py | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/upgrade.py b/upgrade.py index 51ad886..0fcdbf3 100644 --- a/upgrade.py +++ b/upgrade.py @@ -57,7 +57,7 @@ if rhpl.getArch() == "ppc": upgrade_remove_blacklist.extend(map(lambda x: (x, "ppc64"), splitpkgs)) if rhpl.getArch() == "x86_64": - upgrade_remove_blacklist.extend( [("perl","i386")] ) + upgrade_remove_blacklist.extend( [("perl","i386"), ("gnome-applets","i386")] ) def guessGuestArch(rootdir): """root path -> None|"architecture" -- 1.5.4.5

3 4

correctly close nfs mounts when we shutdown
by Joel Andres Granados 02 Apr '08

02 Apr '08

Hey list: Was doing some work for rhel4 (#208103) in the loader department and was wondering if the idea of putting it into rawhide would be a good one. The basic idea is to add some function to tell the nfs server that we no longer need the shared directory. In the case of the rhel4 patch, I used the nfs_umount_rpc_call function from the util-linux rhel4 package. Haven't gone into detail on rawhide or rhel5 and before I do, I would like some feedback from the community. specially since we did some mount changes in the installer. I really doubt that that would affect the init script, but I could be wrong. So: How relevant do you think closing the nfs mount at shutdown is? patch attached. (the rhel4 one) -- Joel Andres Granados Red Hat / Brno, Czech Republic

1 0

[PATCH] simplify ext4 install boot option
by Eric Sandeen 01 Apr '08

01 Apr '08

I think just "ext4" is enough at this point... migration seems totally busted; the root fs and everything in its fstab is mounted before the migration routine runs, so it doesn't get its fs type changed until the *next* mount, which for this migration path pretty well misses the window of opportunity. :( So I figure maybe "ext4migrate" to enable it, but it's not really going to do what you might hope... Thanks, -Eric Index: anaconda-11.4.0.64/fsset.py =================================================================== --- anaconda-11.4.0.64.orig/fsset.py +++ anaconda-11.4.0.64/fsset.py @@ -722,7 +722,7 @@ class ext3FileSystem(extFileSystem): self.name = "ext3" self.extraFormatArgs = [ "-j" ] self.partedFileSystemType = parted.file_system_type_get("ext3") - if flags.cmdline.has_key("iamanext4developer"): + if flags.cmdline.has_key("ext4migrate"): self.migratetofs = ['ext4dev'] def formatDevice(self, entry, progress, chroot='/'): @@ -758,7 +758,7 @@ class ext4FileSystem(extFileSystem): self.extraFormatArgs = [ "-j", "-I", "256", "-E", "test_fs" ] # this is way way experimental at present... - if flags.cmdline.has_key("iamanext4developer"): + if flags.cmdline.has_key("ext4") or flags.cmdline.has_key("ext4migrate"): self.supported = -1 else: self.supported = 0

2 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 April 2008