ack sorry... i guess i read the first e-mail in a rush. i get and sympathize with the problem. I've been having a very similar issue with doing san boots, because I dont care about mpatha-z, i need to be identify based on UUID.
Are there no other /dev/disks/by-* that are available to you for what you want? -greg On Wed, Jun 15, 2011 at 21:26, Jason Keltz <[email protected]> wrote: > 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<[email protected]> 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<[email protected]> 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 >>>>>>> [email protected] >>>>>>> https://www.redhat.com/mailman/listinfo/rhelv6-list >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> rhelv6-list mailing list >>>>>> [email protected] >>>>>> https://www.redhat.com/mailman/listinfo/rhelv6-list >>>>> >>>>> _______________________________________________ >>>>> rhelv6-list mailing list >>>>> [email protected] >>>>> https://www.redhat.com/mailman/listinfo/rhelv6-list >>>>> >>>> _______________________________________________ >>>> rhelv6-list mailing list >>>> [email protected] >>>> https://www.redhat.com/mailman/listinfo/rhelv6-list >>> >>> _______________________________________________ >>> rhelv6-list mailing list >>> [email protected] >>> https://www.redhat.com/mailman/listinfo/rhelv6-list >>> >> _______________________________________________ >> rhelv6-list mailing list >> [email protected] >> https://www.redhat.com/mailman/listinfo/rhelv6-list > > _______________________________________________ > rhelv6-list mailing list > [email protected] > https://www.redhat.com/mailman/listinfo/rhelv6-list > _______________________________________________ rhelv6-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv6-list
