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

[Matthew Richards]

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 Gómez <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

--