Hi Niels, Firstly let me say thanks for persisting with this issue and for sharing your work. Secondly, sorry for the long delay in my response, I have been focused on other parts of my project to the exclusion of pretty much all else. I would like to take a look at your stage0-creation but never received the attachment... I think my email client screwed it up because it appears as a block of garbled text at the end of your email. I did manage to spend some more time on the issue of automatic USB drive identification before my attention was diverted. I was lucky enough to have a friend who is also a developer go over the anaconda code with me. We think that you may be able to make Anaconda-11.1.2.113 (RHEL/CentOS 5.2) support a HDD install method where the HDD is identified by its file system label. To do this we think you would need to add some code to the Anaconda loader that would allow it to convert a file system label to a device name when mounting. The idea we had was to borrow some code from e2label that would allow us to read the label in from the file system super block. Then all we would need to do is add a little logic to go through the devices visible to the kernel that would likely be a USB drive and read their f/s labels until we found a match then pass that device name back for mounting in the normal manner. After a quick look at the later versions of Anaconda I think they are doing something similar to this anyway. Although, the differences between 11.1.2.11 and the latest one a vast so it's hard for me to be sure. Of course the problem with doing this is that you have to update the changes every time you move to a new version of Anaconda, but hopefully that would not go on for too long before the version that natively supports mounting by f/s label came along and then you could abandon the updates. All the best,, Matt ----------------------- Original Message ----------------------- From: Niels de Vos <niels.devos@xxxxxxxxxxxxxxxxxx> To: Matthew Richards <Matthew.Richards@xxxxxxxxxxxxxxxxx> Cc: anaconda-devel-list@xxxxxxxxxx Date: Tue, 21 Oct 2008 14:41:54 +0200 Subject: [stage0] 100% automated kickstart from usb-stick This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigF6137EDB4BE904B14E7E09BE Content-Type: multipart/mixed; boundary="------------000508070203010902040208" This is a multi-part message in MIME format. --------------000508070203010902040208 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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=3D212146 Cheers, Niels > Regards, Matt >=20 >=20 >=20 > ----------------------- Original Message ----------------------- > =20 > 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 fil= e that is referenced via a %include option > =20 > Hello Matt, >=20 > 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. >=20 > It's not that elegant, just working around limitations of anaconda. >=20 >=20 >> 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=3D 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. >=20 > The patch in Bugzilla (#) exactly does make this possible. With this > patch, a ks=3D 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= =2E >=20 >=20 >> 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). >=20 > These are not the references I would suggest. It's probably far more=20 > easy to look into a standard /boot/initrd-$(uname -r).img. They are now= =20 > in cpio.gz format, extract it like: > mkdir /tmp/my-initrd > cd /tmp/my-initrd > gunzip /boot/initrd-$(uname -r).img | cpio -id >=20 > The script init is the starting point and can be extended/replaced. It = > might be adviseable to include a busybox or something like it ;) >=20 >> (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? >=20 > No, don't write a stage0-anaconda-init. It is more like "stage0=20 > bootstraps anaconda". In the init you would do a minimal setup of the=20 > system (like a standard initrd.img) and some extras: >=20 > * 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 >=20 > Note that the loader parses /proc/cmdline, therefore you can set=20 > ks=3Dfile:///tmp/ks.cfg as boot option. >=20 >=20 >> How's that for a guess? >=20 > Close, but don't think too complicated. Only try to do the minimal=20 > things needed. Everything what the proposed stage0 does can easily be=20 > written in shell-scripts. >=20 > Good luck, > Niels >=20 >=20 --------------enigF6137EDB4BE904B14E7E09BE Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) iD8DBQFI/c4S5KAkGQPO/QoRAlClAKCDr/xn0ZuOK7cIaOY0vFH4xsB98wCgngcn cAw1oJJZSfRz73YrmwARjyw= =jlV2 -----END PGP SIGNATURE----- --------------enigF6137EDB4BE904B14E7E09BE-- _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
