Device naming for hd:<dev>:<path> when installing off a USB HD

Fri Oct 10 06:55:25 UTC 2008

	Hi Matthew
	What I did is to create a LiveUSB (using livecd-tools from EPEL on
RHEL5) that triggers a minimal system that partitions hard drive, copies
install ISO image, kernel, initrd and kickstart give that partition
'bootable' status with syslinux and then, restarts, so the system at
next boot, uses hdd to do the install..

	The problem with USB devices is that sometimes it's sda, sdb, whatever,
depending on target system devices/buses ;).

	This method has allowed to use the same kickstart for a USB stick, a
reinstall from hdd partition or a DVD...

	Regards
	Pablo


El vie, 10-10-2008 a las 17:46 +1100, Matthew Richards escribió:
> Hi Charles,
> 
> I am working on a solution to the same issue as well. Have you had any luck 
> with this one :-)
> 
> My main goal is to be able to do a kickstart install from USB without having 
> the user prompted (after 
> they start the install of course) for an install source method.
> 
> > 
> > Would it work to copy ks.cfg onto the local hard drive (which *isn't* 
> > changing names between boots), have a %pre that generates an appropriate 
> > harddrive stanza, and %include that?
> 
> My initial attempt at solving this involved an approach similar to the one you 
> mentioned, thus:
> 
> 1) Give my USB installer a custom file system label.
> 2) Write a %pre script that identifies the USB install device by looking for 
> the custom fs label with e2label,
> then writes the appropriate kickstart method= and ignoredisks= options to 
> /tmp/ks-include
> 3) Finally add %include /tmp/ks-include to the start of my kickstart file.
> 
> The problem with this approach is that the loader (init in Stage1 actually) 
> needs to know the install method 
> before the %pre scripts are run. It's a sort of chicken and egg situation.
> 
> I have explored/considered some alternatives (below). I think what Pablo is 
> suggesting is one of the simplest
> solutions to this problem, and by coincidence I had the exact same solution 
> proposed to me earlier today :)
> 
> Other solutions I've explored/considered:
> 
> (1) Use the latest Anaconda to install CentOS 5.2.
> 
> The latest Anaconda supports specification of harddrive install source via file 
> system label, e.g. 
> method=hd:LABEL="MyLabel1":/iso. This would allow identification of the correct 
> USB HDD no matter which
> device node it was assigned.
> 
> The problem is, apparently coz I haven't tried this yet, is that the latest 
> anaconda has deps that would be too
> complex to resolve see comments here 
> http://lists.centos.org/pipermail/centos-devel/2008-May/002747.html
> 
> (2) Hack the CentOS 5 version of Anaconda to support specification of the 
> harddrive install method via fs label.
> 
> We found that we may be able to do this by hacking the devMakeInode function in 
> anaconda-11.1.2.113/isys/devnodes.c and add a code block at the top to convert 
> fs labels to device nodes. 
> Problem is that you need to use code from e2label to read in and parse the file 
> system super block from your
> local HDDs until you find the right one, then you need to use code from mknod 
> (or perhaps an Anaconda
> equivalent) to set up the dev nodes as they are not set up under /dev at the 
> time.
> 
> It goes on from there, and frankly i'm not sure its worth it.
> 
> (3) Apparently someone wrote a patch to Anaconda that allows specification of 
> multiple kickstart files (ks.cfg).
> 
> I haven't had much luck in tracking this down, tho I've not really tried that 
> hard yet. I'm told this works by 
> getting Anaconda to search for each ks file specified until it find one, so 
> you'd specify on the command line 
> ks=sda1/ks.cfg ks=sdb1/ks.cfg etc and Anaconda would match the USB drive that 
> had your ks file and install
> source.
> 
> (4) Create a Stage0 initrd that contained the actual Anaconda Stage1 initrd.
> 
> This is a nice idea suggested to me by Niels de Vos that I've been playing 
> with. You can read more about it here
> https://www.redhat.com/archives/anaconda-devel-list/2008-October/msg00008.html
> 
> Well, good luck with the USB install.
> 
> Regards,
> Matt
> 
> 
> 
> 
> ----------------------- Original Message -----------------------
> 
>    * From: Pablo Iranzo Gmez <Pablo Iranzo redhat com>
>    * To: Discussion list about Kickstart <kickstart-list redhat com>
>    * Subject: Re: Device naming for hd:<dev>:<path> when installing off a USB 
> HD
>    * Date: Tue, 09 Sep 2008 08:36:19 +0000
> 
> 
>     Hi Charles
> 
> 
> El mar, 09-09-2008 a las 03:24 -0500, Charles Duffy escribi:
> > Howdy, all.
> > 
> > I'm trying to install CentOS 5 off an external USB device. The conflict 
> > here is that the system I'm installing on has other USB storage devices 
> > built-in, and the boot order between them is inconsistent.
> 
> > This means that even if I scan the current list of device names and 
> > labels and then kexec into the installer after observing how my initial 
> > kernel names them, I have only a 50/50 chance of the device names used 
> > for ks=hd:<dev>:/ks.cfg and method=hd:<dev>:/ being valid.
> > 
> > 
> > What's the Right Way to resolve this issue?
> 
> 
>     LiveUSB's use a UUID=????-???? that identifies the root filesystem to
> boot
> 
> > 
> > Would it work to copy ks.cfg onto the local hard drive (which *isn't* 
> > changing names between boots), have a %pre that generates an appropriate 
> > harddrive stanza, and %include that?
> 
>     What I did to resolve this issue is to create a LiveUSB using
> livecd-tools from EPEL, and then inside the disk created a small script
> that searched for the hard drive to partition, give it boot files
> 'syslinux' and then reboot, so the system starts from that hard drive
> and perform an installation with the correct devices placed there.
> 
>     The problem with mixing both scsi, usb drives is that you'll never know
> what are your drive names going to be on the next system... so UUID
> could work but... will need tweaks as afaik anaconda checks for device
> name.
> 
>     Probably you could hack anaconda to run a custom script than looks for
> the correct path, and passes it to 'real' anaconda...
> 
>     Regards
>     Pablo
> 
> --
> 
> _______________________________________________
> Kickstart-list mailing list
> Kickstart-list at redhat.com
> https://www.redhat.com/mailman/listinfo/kickstart-list
-- 

Pablo Iranzo Gómez (Pablo.Iranzo at redhat.com)
RHCE/RHCSP/RHCSS Global Profesional Services Consultant Spain
Phone: +34 645 01 01 49 (CET/CEST)
GnuPG KeyID: 0xFAD3CF0D

--
Inscrita en el Reg. Mercantil de Madrid – C.I.F. B-82 65 79 41
Directores: Michael Cunningham, Charlie Peters y David Owens
Dirección Registrada: Red Hat S.L., C/ Velazquez 63, Madrid 28001, España
Dirección contacto: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, Planta 3ºD, 28016 Madrid, Spain


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Esta parte del mensaje est? firmada	digitalmente
URL: <http://listman.redhat.com/archives/kickstart-list/attachments/20081010/b4da3b3a/attachment.sig>