Anaconda-devel May 2004

anaconda-devel@lists.stg.fedoraproject.org

27 participants
36 discussions

Package Setup
by Peter Landy 02 Jun '04

02 Jun '04

I am looking for a step by step guide for setting up my own packages with kickstart and Anaconda. None of the documentation seems complete. I am trying to build me own distribution based on Fedora. Can anyone point me in the right direction. Thankyou Pete

3 2

[Fwd: Re: FC3 working anaconda todo]
by Jeremy Katz 01 Jun '04

01 Jun '04

-------- Forwarded Message -------- From: Jeremy Katz <katzj(a)redhat.com> To: mike(a)flyn.org <mike(a)flyn.org> Subject: Re: FC3 working anaconda todo Date: Tue, 25 May 2004 16:57:09 -0400 On Tue, 2004-05-25 at 16:52 -0500, mike(a)flyn.org wrote: > I would like to see support for installing onto an encrypted root partition > (using cryptsetup/dm-crypt). I am currently working on a patch for Red Hat's > mkinitrd that will add support for creating the necessary initrd. The > changes to anaconda should be pretty simple, but supporting sophisticated > authentication techniques (physical tokens, etc.) may get a little tricky. There was some discussion about this on IRC earlier today I guess. My current opinion is that I'm sort of waiting to see how the userspace setup side pans out before committing to doing anything with this. If the userspace setup is simple enough that it's not going to change and it doesn't make the UI horrendously bad, I'm definitely not against adding it. Jeremy

3 4

FC3 working anaconda todo
by Jeremy Katz 31 May '04

31 May '04

For the second trick, here's a list of a variety of things that are being looked at/worked on within anaconda with sort of a time frame of being done for Fedora Core 3. I've put some thoughts on implementation for each as well, although that's just from my quick thinking on them. If you're interested in working on one of them, feel free to ask questions here. Note that none of these will definitely make it in... it entirely depends on available time, etc * Support for installation via a USB network adapter * Add a pruner of modules.usbmap similar to the one for modules.pcimap * Add appropriate modules to module-info * Make sure BUS_USB is being included in NIC probe * QUESTION: How do these persist on the installed system? Do things "just work"? * I've gotten a lot of this so that it should work with the current devel tree, although it needs testing. * Wireless support during installation * Add a screen to the loader to get wireless settings * Showing this depends on whether iwconfig ioctls work or not * Need: essid, wep * Add support for setting these via kickstart * QUESTION: Do we expose this in the second stage? I'm thinking not, but willing to be convinced otherwise. * This also is well under way (as of today), it's my current project. * Rework langsupport screen * Current screen is non-sensical with what we actually do based on it. * Should just show groups with langonly in the comps file using those names. Allows translation, clearer and provides the obvious way to do post-install * Should allow language class to become much simpler * Reworking lang-table in the process would be an added bonus * Charlie Bennett (ccb(a)redhat.com) is investigating this * Better support for driver disks from non-floppy sources * Allow from USB keys, etc (aka, any disk really) * If disk is partitioned, select partition and then give filename * First pass can use hdinstall.c stuff to select partition + enter the filename * Nicer would be directory browser * New "migrate" upgrade option similar to what exists in OS X. * Preserve changed %config, other files in /etc and /var * Use versioned look-aside in /var * Then, nuke system dirs and do a fresh install * Migrate back hardware configuration * Paul Nasrat (pnasrat(a)redhat.com) is investigating this. * Partition resizing * Often requested, tricky to do and support. * UI thought would be to do it in editing an existing partition * Needs parted fixes to handle new ext[23] features * Keyboard/mouse/monitor configuration * We really don't need to ask about anything other than keyboard on a GUI install. * If they can configure depth, etc all in firstboot, why not have them configure the monitor there too? * Could go to just _copying_ the install x config file * Brent Fox (bfox(a)redhat.com) is investigating this * Firewall/security screen UI improvements * Trusted devices goes away * Trusted ports -> dialog. Add translations * SELinux needs to be put in here somehow better than it currently is. * LVM support * A few weird failure cases sometimes, need better error handling * Are there new useful options to add? * RAID support * Add support for RAID 6 - DONE * Possibly add support for RAID 10? * Better handling of "unsupported" pre-existing RAID levels * Multipathing? * Handling of kickstart errors * Currently, errors in a ks.cfg result in a traceback. We should give a nice error dialog instead. * Finish converting parser errors to raise KickstartError * Catch error, show dialog with exception logged * The big remaining difficulty is the kickstart config is parsed before the interface exists which could lead to different tracebacks. * Internal logging functionality improvements * Add log levels * Don't display all of the debuginfo on tty3, but put in file, only showing the most critical stuff on tty3 * Ask about VNC on a text mode install * If we're unable to start X, ask if the user would like to do a VNC install. * zfcp config support during installation * Newer s390 are using zfcp * IPv6 support * Both for during the install and setup for post-install * Low priority with current IPv6 penetration * Other miscellaneous things to consider * Traceback fingerprinting to make dupe hunting in bugzilla easier * Some objects are opaque in tracebacks, fix those up * Use LVM by default in auto-partitioning? * Make disk filtering in driveDict more modular * Driver disks for things that aren't scsi or network cards Longer term, I have some more radical changes in mind, but with other time constraints, I don't think it's really reasonable to even consider them for FC3. Jeremy

10 20

[Patch] add support for ccwgroup device (mainframe)
by Karsten Hopp 26 May '04

26 May '04

Attached is a patch for ccwgroup devices with kernel-2.6 on mainframes. It basically writes up to two new variables into ifcfg-xxx which are then picked up by the initscripts and written to some special files in /sys Karsten -- Karsten Hopp <karsten(a)redhat.de> GPG 1024D/70ABD02C Fingerprint D2D4 3B6B 2DE4 464C A432 210A DFF8 A140 70AB D02C Red Hat Deutschland, Hauptstaetter Str.58 70178 Stuttgart, Tel.+49-711-96437-0, Fax +49-711-96437-111

2 1

Re: FC3 working anaconda todo
by mike＠flyn.org 25 May '04

25 May '04

> * Firewall/security screen UI improvements > * Trusted devices goes away > * Trusted ports -> dialog. Add translations > * SELinux needs to be put in here somehow better than it currently is. > > * LVM support > * A few weird failure cases sometimes, need better error handling > * Are there new useful options to add? I would like to see support for installing onto an encrypted root partition (using cryptsetup/dm-crypt). I am currently working on a patch for Red Hat's mkinitrd that will add support for creating the necessary initrd. The changes to anaconda should be pretty simple, but supporting sophisticated authentication techniques (physical tokens, etc.) may get a little tricky. -- Mike

1 0

conditionals in comps.xml
by Matthew Miller 25 May '04

25 May '04

Okay, I was sure I had a conversation with Jeremy (or someone) about this a while ago, but I can't remember how it came out, or find record of it anyway.... The old non-XML comps file had the ability to list packages as conditional on others -- you could have a Games group, and tag certain packages within that to only get installed if (for example) X was selected. The new format, while superior in many ways, doesn't seem to have this. And it causes an annoying problem, very apparent in the select-package-groups screen. There shouldn't need to be separate groups for Development, X Development, GNOME Development, and KDE Development. There should just be Development, and then if you've picked that, it'd automatically install the devel stuff for any desktop environments you've choosen. A similar thing applies to the config tools (although, really, those could just be moved from their own special group and put with the things they configure, couldn't they?). Would it be possible to have something like this for Fedora Core 3? This is in some ways a tangent to the thread Havoc Pennington started this afternoon on the fedora-list -- having a more flexible and user-friendly package group syntax would help with making more powerful install class options. -- Matthew Miller mattdm(a)mattdm.org <http://www.mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/>

2 3

anaconda CVS repository moved to rhlinux.redhat.com
by Jeremy Katz 25 May '04

25 May '04

This is a heads-up that the CVS repository for anaconda has moved from its previous home of an internal server to the externally accessible rhlinux.redhat.com. You can check it out by doing cvs -d:pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS login cvs -d:pserver:anonymous@rhlinux.redhat.com:/usr/local/CVS co anaconda This will give you the current trunk of anaconda development (ie, what's destined for FC3 and beyond). I'm going to send a mail shortly with a list of some of the things that myself and some of the other people at Red Hat who work on anaconda are looking at or working on with the goal of getting as much of it done as possible for Fedora Core 3 for discussion or for others to pick up some of the ideas and run with them. Cheers, Jeremy

1 0

conditional kickstart
by King, John (Greg) (LMIT-HOU) 24 May '04

24 May '04

Is there a mechanism that would allow you to load a kickstart file based on a comps.xml group selection? Or some other mechanism other than specifying at the boot prompt? What I am doing is creating FC2 into a single CD format, starting with just a minimal set of packages. Then, as I create different load types, I add them to a new comps.xml file I am creating. Each comps.xml group I am creating will require a different set of %post instructions in my kickstart file. Therefore, it would be nice to say what kickstart file to use based on the selected group. For example, I am working on 3 sets of loads right now: Core (+chkrootkit, snort, and clamav), Log (core + syslog and snmp), Monitor (Core + NMIS, Nagios, MySQL (for snort data)) Each setup also contains a seperate kickstart file that performs permissions hardening, account creation, system configuration and other things. So far I have a seperate build for each one in order to get it to automagically use the ks.cfg file on install. What would be nice is to combine all these on the same disc but into seperate comps.xml groups and tell it to use ks.core ks.log or ks.monitor depending on the selected group. Thanks, Greg King

2 1

Kickstart and SuSE?
by Brian Long 24 May '04

24 May '04

Has anyone on this list used anaconda/kickstart to install SuSE? I've heard it can be done and I wonder if it makes sense to use kickstart instead of learning AutoYast. Thanks. /Brian/ -- Brian Long | | | Americas IT Hosting Sys Admin | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s

1 0

Re: RE: Fedora Core 2 and rebuilding with a custom boot message
by Steve M Bibayoff 21 May '04

21 May '04

Hello, "King, John (Greg) (LMIT-HOU)" <Greg.King(a)lmit.com> wrote: > [...} If the > changes are made in the isolinux directory, what is the > diskboot.img for > then? I believe it's for people that still have to boot off a floppy, or maybe people that don't have the tools yet to build a bootable CDRom with a larger boot image (aka isolinux). But I'm just guessing. Steve

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel May 2004