[rhelv6-list] kickstarting rhel6 from usb key

Jason Keltz jas at cse.yorku.ca
Thu Jun 16 02:26:50 UTC 2011


Hi Greg,

Thanks for the link!  Fortunately, the location of the kickstart config 
file isn't the problem.  Right now, I server my ks.cfg through an NFS 
server, so that part works great.  My custom kickstart USB key has as 
its first option "kickstart" which does does a " ... 
ks=nfs:1.2.3.4:/obj/kickstart/", and that part always works fine.  The 
problem isn't really finding the ks config file.  The problem is that 
when I setup a system in our hardware database, I specify say, "sda" is 
the install location for kickstart -- if I use an install CD, it will 
certainly be sda, but if I use my USB key (which is much faster and more 
convenient than a CD) -- then sometimes it will be sda, and other time 
it won't be sda, and as it stands right now, I'd have to check each time 
to be sure or I could wipe out the USB key by choosing the wrong 
option!!  It just doesn't seem like something that I should have to 
"hack" into kickstart to get it right!  Surely there must be a way for 
Anaconda to distinguish between hard disk and USB keys!   If I want to 
use the USB key for installation, then I need to do some other magic, 
but this will mess with my simplicity of just specifying a disk device, 
and having the kickstart file automatically assigned... and I don't even 
know whether I *can* hack it because of a "chicken and egg" type 
problem... if I define the disk device in the kickstart file, and the 
pre script notices that the USB key is inserted, and it needs to 
"change" the disk as specified, then I don't know whether I can do that 
after the fact -- the system has already read the kickstart file, and 
the disk device was already specified on the clearpart line and on other 
lines..

sigh.

jas.

On 15/06/2011 4:55 PM, Greg Swift wrote:
> check this out... specifically the bit about it defaulting to ks.cfg
> in root directory of media:
>
> http://forums.fedoraforum.org/showthread.php?t=235489
>
>
> On Wed, Jun 15, 2011 at 15:36, Jason Keltz<jas at cse.yorku.ca>  wrote:
>> Hi Greg,
>>
>> I believe /dev/disk/by-label is available, and I looked into using that, but
>> still, if the usb key becomes /dev/sda, then this will effect installation
>> of bootloader, etc.  hard to work around.
>> Does red hat not support installation via usb key?
>> I'm not using multipath so I don't have /dev/disk/by-scsi-id..
>> In this particular case, the system has a 3ware 9750-8e card (which is
>> referred to first in bios)..
>>
>> I wish there was some way to force the usb device as being sdb.
>>
>> jas.
>>
>> Greg Swift wrote:
>>> in the stage2 environment check to see if /dev/disk/by-label is
>>> available.  If it is, and you know or can change the label of your usb
>>> device, you should be able to reference this.
>>>
>>> I know that in the multipath bits they are trying to push more heavily
>>> into using the /dev/disk/by-scsi-id/ for disk handling in rhel 6
>>> anaconda.
>>>
>>> -greg
>>>
>>>
>>> On Wed, Jun 15, 2011 at 15:18, Jason Keltz<jas at cse.yorku.ca>  wrote:
>>>> Hi Ges,
>>>>
>>>> Thanks for your reply.
>>>> Does this mean that kickstarting from a USB key is just not reliable?
>>>> You have to be able to specify a device during kickstart, and if you
>>>> don't
>>>> know what the device that represents the hard disk will be, then what do
>>>> you?
>>>> I could "calculate" it on the fly, and modify the kickstart process
>>>> accordingly, but if there are multiple disks in the system, and I want to
>>>> be
>>>> able to specify which of those devices will be used for kickstart, then
>>>> this
>>>> messes things up ..
>>>> Once a system is kickstarted, you can use labels, etc. to identify disks,
>>>> but assuming you're starting with a totally blank hard disk, who knows
>>>> what
>>>> device the kernel will see..
>>>>
>>>> I remember this was an issue years and years ago .. can't believe we
>>>> haven't
>>>> found a better way to handle this under Linux yet...
>>>>
>>>> sigh..
>>>>
>>>> Jason.
>>>>
>>>>
>>>> Grzegorz Witkowski wrote:
>>>>> Hi,
>>>>>
>>>>> /dev/... devices may not be persistent between reboots.
>>>>> It is not a bug. The kernel usually just assigns unpredictable device
>>>>> names based on the order of discovery. See udev related info.
>>>>>
>>>>> Regards,
>>>>> Ges
>>>>>
>>>>> On Wed, 2011-06-15 at 15:44 -0400, Jason Keltz wrote:
>>>>>> Hi.
>>>>>>
>>>>>> I'm kickstarting a new Red Hat 6.0 system from a USB key.
>>>>>> I've kickstarted it many times from the key in the last week, and the
>>>>>> USB
>>>>>> key is recognized as sdb, and the system hard disk as sda.
>>>>>> However, this morning, I went to kickstart, and the USB key was
>>>>>> suddenly
>>>>>> being recognized as sda which, of course messed up the process.
>>>>>> I tried it various times, and it continued to be that way.
>>>>>> I then had to leave it for a while because I was busy with other stuff.
>>>>>> When I came back, the hard disk is now being recognized as sda, usb key
>>>>>> as sdb.
>>>>>> What's up?  seems like an odd bug...
>>>>>>
>>>>>> Jason.
>>>>>>
>>>>>> _______________________________________________
>>>>>> rhelv6-list mailing list
>>>>>> rhelv6-list at redhat.com
>>>>>> https://www.redhat.com/mailman/listinfo/rhelv6-list
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> rhelv6-list mailing list
>>>>> rhelv6-list at redhat.com
>>>>> https://www.redhat.com/mailman/listinfo/rhelv6-list
>>>> _______________________________________________
>>>> rhelv6-list mailing list
>>>> rhelv6-list at redhat.com
>>>> https://www.redhat.com/mailman/listinfo/rhelv6-list
>>>>
>>> _______________________________________________
>>> rhelv6-list mailing list
>>> rhelv6-list at redhat.com
>>> https://www.redhat.com/mailman/listinfo/rhelv6-list
>> _______________________________________________
>> rhelv6-list mailing list
>> rhelv6-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/rhelv6-list
>>
> _______________________________________________
> rhelv6-list mailing list
> rhelv6-list at redhat.com
> https://www.redhat.com/mailman/listinfo/rhelv6-list




More information about the rhelv6-list mailing list