Anaconda-devel January 2008

anaconda-devel@lists.stg.fedoraproject.org

23 participants
29 discussions

CD and DVD ISO images
by John Summerfield 07 Feb '08

07 Feb '08

I've just run this same subject by fedora users on fedora-list. There were lots of irrelevant responses advocating bittorrent and/or jigdo, but neither addresses the same problem as simply as my proposal. I don't think anyone who understood what I meant said it is a Bad Idea, and certainly some agreed with the proposal. There exists a problem for those who want both CD and DVD-sized images. I've just done a census of the computers around here, and there's a few that have CD drives, not DVD. OTOH, where I have a DVD drive I do prefer the convenience of DVD-sided images. There's also the likelihood that some folk will want to give copies to their mates, or distribute them at their PLUG, SLOG or OLUG, and often the appropriate medium is a set of CDs. I remember that when I last did NFS installs, Anaconda had the ability to install from ISO images accessible by NFS, or from a local hard disk. My proposal is to extend this to doing the same thing from ISO images. That is, one could have nested ISO images (only one level!). An example implementation might be this. An CD (basically boot.iso) boots, and for a CD/DVD install, looks for a set of .ISO images in a particular location, say /iso on the boot disk. If present (and correct), it would offer the option of installing from these .iso images. If this functionality could be added to versions of Anaconda applicable to currently-supported releases of RHEL, that would be really ace! CentOS and the other clones would benefit too. There would be advantages to everyone - RH, Fedora Project, mirrors & clones, in terms of disk storage (compared with two sets of ISO images) and bandwidth consumption. Generally. users would be given the choice of installing directly from the Internet or downloading a DVD image and then either burning a DVD or a set of CDs. I don't know the details of how Windows users manage CD images, but I understand it's possible. It would also be possible to enhance the boot.iso image, giving it the abilities to 1. Eject the boot CD 2. Optionally mount a .iso from NTFS 3. Burn DVDs and/or CDs. This would ensure a documentable standard procedure is available to Windows users, rather than a vague statement about "refer to your software's documentation" and hoping for the best. _I_ may be wrong, but I don't think that this requires much work an Anaconda Installer; basically it needs to run existing code in new circumstances. I also don't think that there's much to be done to add the .iso images to boot.iso, I think the procedure would be to create the layout and run mkisofs twice, once omitting the ISOs. Adding the burning functionality to the boot iso could wait. What do Anaconda hackers think? -- 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:-)

2 7

[PATCH] fsset.py tweaks for ext4dev & xfs
by Eric Sandeen 31 Jan '08

31 Jan '08

ext4dev just got a "test_fs" flag which soon must be set in order for the kernel to mount it; this will prevent ext3 from accidentally getting mounted as ext4, and making it hard to go back. (when ext4 goes prime-time, the need for this flag will be removed). Perhaps anaconda.spec should also depend on e2fsprogs >= 1.40.5 with this change. Also tweak the xfs class a bit; most mkfs arguments specified are actually defaults now, and there is a nicer labeling command available, xfs_admin - a 665-byte bash script which I added to upd-instroot too. *cough* not actually tested in anaconda but what can go wrong? ;) Thanks, -Eric Index: anaconda-11.4.0.30/fsset.py =================================================================== --- anaconda-11.4.0.30.orig/fsset.py +++ anaconda-11.4.0.30/fsset.py @@ -411,9 +411,7 @@ class xfsFileSystem(FileSystemType): def formatDevice(self, entry, progress, chroot='/'): devicePath = entry.device.setupDevice(chroot) - rc = iutil.execWithRedirect("mkfs.xfs", - ["-f", "-l", "internal", - "-i", "attr=2", devicePath], + rc = iutil.execWithRedirect("mkfs.xfs", ["-f", devicePath], stdout = "/dev/tty5", stderr = "/dev/tty5", searchPath = 1) @@ -424,9 +422,8 @@ class xfsFileSystem(FileSystemType): devicePath = entry.device.setupDevice(chroot) label = labelFactory.createLabel(entry.mountpoint, self.maxLabelChars, kslabel = entry.label) - db_cmd = "label " + label - rc = iutil.execWithRedirect("xfs_db", - ["-x", "-c", db_cmd, devicePath], + rc = iutil.execWithRedirect("xfs_admin", + ["-L", label, devicePath], stdout = "/dev/tty5", stderr = "/dev/tty5", searchPath = 1) if rc: @@ -718,9 +715,10 @@ class ext4FileSystem(extFileSystem): extFileSystem.__init__(self) self.name = "ext4dev" self.partedFileSystemType = parted.file_system_type_get("ext3") - self.extraFormatArgs = [ "-j", "-I", "256" ] + # 256-byte inodes are actually default now, but let's be sure. + self.extraFormatArgs = [ "-j", "-I", "256", "-E", "test_fs" ] - # this is way way way experimental at present... + # this is way way experimental at present... if flags.cmdline.has_key("iamanext4developer"): self.supported = -1 else: Index: anaconda-11.4.0.30/scripts/upd-instroot =================================================================== --- anaconda-11.4.0.30.orig/scripts/upd-instroot +++ anaconda-11.4.0.30/scripts/upd-instroot @@ -378,6 +378,7 @@ sbin/tune2fs sbin/xfsdump sbin/xfsrestore sbin/xfs_repair +usr/sbin/xfs_admin usr/sbin/xfs_db usr/sbin/xfs_check usr/sbin/xfs_copy

2 3

refering to bug 395881. let mdadm do its stuff
by Joel Andres Granados 31 Jan '08

31 Jan '08

Hi List: In anaconda, when it is time to write the mdadm.conf file, it is done by each device object "ent.device.mdadmLine()". This is all good, but when other mdN devices that are not in the object list (for whatever reason, look at bug :), are needed to boot the system properly after update or install, this method might present a problem. I just say: "use mdadm". Patch attached. /me gets prepared to get screamed at for missing something completely obvious. :) Regards. -- Joel Andres Granados Red Hat / Brno, Czech Republic

5 9

Re: CD and DVD ISO images (John Summerfield)
by Clinton Lee Taylor 30 Jan '08

30 Jan '08

Greetings ... > What do Anaconda hackers think? Just a lurker, but I'm sure that FC1 had the ablity to so http installs from unpack iso too ... This went away around FC3, if I remember correctly ... I think it a good idea, but not been a hacker, might not understand how hard it could be to put in place ... Either way, got my vote had hope this might come to light. Mailed LeeT

1 0

Releasing anaconda fixes to updates/
by Jeroen van Meeuwen 29 Jan '08

29 Jan '08

Hello, For quite some time now Fedora Unity has been doing these Re-Spins, which primarily just included all the updated packages for what had been released for a Fedora X or Y. With one of our previous Re-Spins, we had successfully ported a fix from anaconda's development back into F8 stock anaconda, bumped the release number and used it for our Re-Spin. The fix we backported had to do with glibc.i686 and openssl.i686 being used during upd-instroot instead of glibc.i386 and openssl.i386, and with help and advice from Chris Lumens we decided we could backport the fix without too much hassle. Today, another issue occurs with libXcomposite not being pulled in during the graphical installer image compose stage (upd-instroot), while mini-wm does require it to even run at all. This means attempting a graphical install will now fail when including the updates/ repository. Right at this moment we have included another fix in anaconda which is supposed to resolve that issue too -we'll be running even more extensive tests on our Re-Spins to verify we haven't broken anything else, but the point I'm trying to raise here is something different. These fixes we apply (and not release to updates/ as obviously we can't), are now not made available to anyone else composing Fedora 8 [1], which kind of eliminates Re-Spin, Re-Factor, Re-Mix or whatever it is you would want to call it. I'm sure you'll appreciate that /me being upstream for one of those compose tools I strongly feel for getting the fixes I apply out there to the general public, preferably via upstream anaconda and all that is Fedora (updates/, koji, bodhi, etc). How would you, anaconda development team, feel for getting fixes into stable branches and updates being pushed to the appropriate repositories? Thank you in advance, Kind regards, Jeroen van Meeuwen -kanarip [1] Of course the fixes are available, after all we're GPL compliant, they're just not in the Fedora Infra..

1 0

pungi/mkisofs for ppc on x64
by Doug Maxey 24 Jan '08

24 Jan '08

Howdy! This may appear to be slightly off topic, please stay with me... I am trying to compose an f8 ppc iso on an x86_64 machine. This should work, as there is no native ppc code run, right?. All goes well until we get to the mkisofs stage. There appears to be 2 bugs involved, see [1]. As part of the debug, I finally got mkisofs to enable the use of the -magic flag, which finally gets me back to the anaconda part. pungi emits the following command: Pungi.Pungi:INFO: Running /usr/bin/mkisofs -v -U -J -R -T -part -hfs \ -r -l -sysid PPC -no-desktop -allow-multidot \ -chrp-boot -map /usr/lib/anaconda-runtime/boot/mapping \ -magic /usr/lib/anaconda-runtime/boot/magic \ -hfs-bless /srv/f8/080118-0222/8/ppc/os/ppc/mac \ -V Fedora 8 ppc DVD -o \ /srv/f8/080118-0222/8/ppc/iso/Fedora-8-ppc-DVD.iso \ /srv/f8/080118-0222/8/ppc/os In anaconda, one sees that scripts/mk-images.ppc is the call site, is attempting to use "/usr/lib/anaconda-runtime/boot/magic", which indeed does not exist. Looking at the anaconda source, I did find a magic file, in bootdisk/ppc/magic. This file is not in the installed /usr/lib/anaconda-runtime anywhere. Would this be the correct file? Should bootdisk/ppc/magic always be installed? Or for that matter, the entire contents of bootdisk/*? [1] https://bugzilla.redhat.com/show_bug.cgi?id=429447 ++doug

5 11

Re: Is boot.iso in todays x86_64 rawhide usable?
by Will Woods 24 Jan '08

24 Jan '08

On Thu, 2008-01-24 at 12:15 -0500, Will Woods wrote: > On Thu, 2008-01-24 at 11:41 -0500, Clyde E. Kunkel wrote: > > Clyde E. Kunkel wrote: > > > Fails for me with : > > > > > > Failed to execute /init > > > Kernel panic - not syncing: no init found. Try passing init= option to > > > kernel. > > > > > > > Well, makes no difference since install is underway using the rescue iso. > > > > Is a bz needed, tho, for todays x86_64 boot.iso? > > Happens on i386 too. We're looking into it. I'm a little baffled. I checked the initrd and the reason /init won't load is.. there are no libraries on the initrd. (Yes, we're using dynamically-loaded binaries in initrd now). So I hacked up pungi to enable --debug on buildinstall (the script that builds the images) and I get the following output: DSO_DEPS for /usr/lib/anaconda-runtime/loader/init are Gosh. Yep, seems like there should be some libraries listed there. Like libc, maybe. Checking the code for buildinstall, I find get_dso_deps in buildinstall.functions. It uses a chroot and some ld.so hackery to figure out what libraries a binary wants to load. But there's no ld-linux.so.* in /lib on the initrd, so this fails, so we get no deps. Okay, that makes sense. So it seems like mk-images would need something like: cp -Lfp $IMGPATH/LIBDIR/ld*.so $MBD_DIR/$LIBDIR/ before any call to instbin (which calls get_dso_deps, which requires ld.so to work right). What *doesn't* make sense is: how did this ever work before? Neither mk-images nor buildinstall* has been modified in the past week. So yeah. I obviously don't understand the problem well enough to solve it. But I hope this information is useful to someone smarter than me. -w

1 0

Does anaconda support AoE?
by Alexander Todorov 24 Jan '08

24 Jan '08

Hello, I remember seeing somewhere ideas to support ATA over Ethernet (AoE). Does Anaconda have such support at the moment? Thanks, Alexander.

1 0

[PATCH] Add required files in stage2.img
by Alexander Todorov 24 Jan '08

24 Jan '08

Adds missing libraries and Python modules. With the new Dogtail port based on pyatspi that will need to change a bit but I can't test it right now.

4 7

[PATCH](resend)Fix gtk.MessageDialog Exception
by HARA Hiroshi 23 Jan '08

23 Jan '08

Hi, When I tested the latest anaconda in my PC,I encountered the following exception. [exception] -------- anaconda None exception report Traceback (most recent call first): File "/usr/lib/anaconda/gui.py", line 788, in __init__ self.dialog = gtk.MessageDialog(mainWindow, 0, style, buttons, text) File "/usr/lib/anaconda/gui.py", line 1067, in messageWindow custom_buttons, custom_icon, run=True, parent=parent).getrc() File "/usr/lib/anaconda/iw/autopart_type.py", line 213, in addZfcpDrive self.intf.messageWindow(_("Error"), e) File "/usr/lib/anaconda/iw/autopart_type.py", line 240, in addDrive rc = self.addZfcpDrive() TypeError: GtkMessageDialog.__init__() argument 5 must be string or None, not exceptions.ValueError -------- anaconda sometimes calls anaconda.intf.messageWindow with exceptions.ValueError like this. But gtk.MessageDialog in messageWindow can not accept it. so I added str() to gtk.MessageDialog like the attached patch. ---------------------- self.dialog = gtk.MessageDialog(mainWindow, 0, style, buttons, str(text)) ---------------------- or should I change all of calling side like the following? ---------------------- self.intf.messageWindow(_("Error"), str(e)) or self.intf.messageWindow(_("Error"), "%s" %(e,)) ---------------------- Would you review the attached patch and give me a comment, please? thanks, Hiroshi HARA

2 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel January 2008