Hello Matt, I'm back in the office again and have access to mail and subversion :) Attached .tgz contains a slightly adjusted stage0-creation the way we use it. The used distribution is Fedora Core 4, but with some small changes it should work on RHEL/CentOS-5 (I'll be working on that later). Any comments, ideas are very welcome! Matthew Richards wrote: > I could not see a simple method of building a custom Stage0 image > that would work on unknown scsi hardware without, for example, > including many SCSI drivers and a method of detecting the hardware > and insmoding the appropriate driver. Any suggestions? No, we also include a lot of drivers for all (our) known hardware. > Also, have you tried bootstrapping the loader before (exec chroot > tmp-directory /bin/loader)? When I did this I received a complaint > about the 'term' variable not being set? Never noticed/seen this... > You mentioned a Bugzilla patch that makes it possible to specify more > than one ks.cfg file. Do you know the Bugzilla number for this > please, I would like to take a look (btw, I did do a quick scan of RH > Bugzilla but couldn't find the relevantbug report)? 212146 or https://bugzilla.redhat.com/show_bug.cgi?id=212146 Cheers, Niels > Regards, Matt > > > > ----------------------- Original Message ----------------------- > > From: Niels de Vos <niels.devos@xxxxxxxxxxxxxxxxxx> > To: Matthew Richards <Matthew.Richards@xxxxxxxxxxxxxxxxx> > Cc: anaconda-devel-list@xxxxxxxxxx > Date: Wed, 24 Sep 2008 19:42:45 +0200 > Subject: Re: Can the install method be contained within a kickstart file that is referenced via a %include option > > Hello Matt, > > Matthew Richards wrote: >> I suppose that having a Stage0 solution would indeed be more elegant >> than an updates.img solution. I'm guessing that you would not have to >> rebuild a Stage0 image very often but would have to re-generate an >> updates.img patch any time you moved to a new version of Anaconda. > > It's not that elegant, just working around limitations of anaconda. > > >> I'm curious about this "some kind of detection with two ks.cfgs" that >> you refer to. It sounds like you are implying that this is done via a >> custom patch to Anaconda? I can't help wondering if Anaconda is >> flexible enough to allow this sort of thing without a custom patch >> by, say, placing 2 ks= options in the bootloader config - but that >> would probably result in either an error or only one of the ks.cfg >> files being parsed . . . sorry, just thinking as I type. > > The patch in Bugzilla (#) exactly does make this possible. With this > patch, a ks= option allows more than one ks.cfg. However, it's just > an other workaround for missing functionality. I still don't know what > the best way would be to implement this correctly in anaconda/kickstart. > > >> It is a bit of a challenge to guess what you are getting at with my >> limited Linux app development knowledge, but I imagine you are >> proposing to: >> >> (1) Build a new initrd.img containing only the resources needed for >> your basic environment and the tasks that you need to perform ( I >> have little idea what this would contain but I suppose I could find >> out from Anaconda-Init source and its dependencies, or from LSB, or >> from Linux From Scratch or something similar). > > These are not the references I would suggest. It's probably far more > easy to look into a standard /boot/initrd-$(uname -r).img. They are now > in cpio.gz format, extract it like: > mkdir /tmp/my-initrd > cd /tmp/my-initrd > gunzip /boot/initrd-$(uname -r).img | cpio -id > > The script init is the starting point and can be extended/replaced. It > might be adviseable to include a busybox or something like it ;) > >> (2) Write a new Stage0-Anaconda-Init based on Stage1 Anaconda-Init, >> that will run your tasks and then finish by loading Stage1 initrd.img >> and running /sbin/loader? > > No, don't write a stage0-anaconda-init. It is more like "stage0 > bootstraps anaconda". In the init you would do a minimal setup of the > system (like a standard initrd.img) and some extras: > > * detect the install target (search for /dev/sda,sdb,...) > * detect the install source (search for/dev/sda,sdb,http,nfs,...) > * create a tmp-directory > * extract the original initrd.img which includes the loader > * sed ks.cfg and save it in the same tmp-directory > * exec chroot tmp-directory /bin/loader > > Note that the loader parses /proc/cmdline, therefore you can set > ks=file:///tmp/ks.cfg as boot option. > > >> How's that for a guess? > > Close, but don't think too complicated. Only try to do the minimal > things needed. Everything what the proposed stage0 does can easily be > written in shell-scripts. > > Good luck, > Niels > >
Attachment:
stage0.tgz
Description: application/gz
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
