I've been trying to use a kickstart file to guide the Red Hat installer (RHEL6.5) without user intervention. It correctly looks for the kickstart file in /dev/sdb/fs.cfg, but because the USB is recognized as /dev/sda, it is actually located at /dev/sda/fs.cfg. I can manually point the installer to this destination, but the rest of kickstart file relies on having the native hard drive be sda. I would like to do so without editing the kickstart files, but that's what is necessary, I'm willing to do it.

Is there any way to force the kernel to recognize the USB as sdb and the HD as sda (I'm assuming the kernel is responsible for the mix up, but I'm not sure)? It seems very odd that it chooses an external drive (the USB) as sda and forces the internal (HD) to sdb.

Note: My issue is very similar to this one, except that my kickstart file absolutely depends on the HD being sda

This problem only occurs for RHEL6.5 installer and not for RHEL5.X installer (I haven't tried any previous version of RHEL6.X). What I really want to know is why it is changes between versions.

  • 2
    It's not the kernel that's mixed up, it's whoever wrote the kickstart file. However, you can probably avoid this problem by booting without the USB attached, then after the system is up, plug it in. – goldilocks Jul 22 '14 at 18:28
  • BTW, I dunno how you end up with /dev/sd[anything]/whatever -- unless I'm about to learn something new, this should not be a real path. Files are in filesystems, not device nodes. – goldilocks Jul 22 '14 at 18:31
  • I considered this, but I wasn't sure on the timing. I guess I should just keep trying different time intervals until I get a successful install boot with USB as sdb. – skamazin Jul 22 '14 at 18:35
  • I'm fairly certain that when a path like /dev/sdX is given manually (or through kickstart file) during installation, the kernel (or some other software) automatically chooses a mount point to load the files on. – skamazin Jul 22 '14 at 18:42
  • 1
    @goldilocks has the only valid solution here if you are really focused on using the /dev reference. However, you should consider using consistent device names (e.g., labels or UUIDs). – HalosGhost Jul 22 '14 at 19:08

Ok, so here's the way the boot process works:

  • firmware > bootloader maybe > kernel ${parameters} > initramfs > userspace maybe

On a redhat installation disk their dracut system of scripts is what builds and constitutes initramfs and their anaconda installation system constitutes the final userspace.

It is udev that handles the device setup - as in, it names the devices in /dev. But this almost always happens twice - once in initramfs and again when the init within has found its target root device and is ready to mount a devfs on it.

So this is how it works:

  • bootloader (or firmware) invokes the kernel with an optional parameter set and an optional initramfs image. This parameter set is saved in /proc/cmdline and the kernel ignores all parameters it doesn't understand.

  • The initramfs is a working linux userspace. Whether its / contents are unpacked from an image handed it at invocation or they are compiled in doesn't matter - since kernel 2.6 it is always the first working root filesystem the linux kernel mounts. From this point the linux kernel leaves it all to userspace.

    • Usually (as is true for redhat's dracut) the initramfs contains only what is absolutely necessary to find a root device and mount it over itself. Generally all that is included is busybox and the kernel modules required to mount your target root device.

    • It probably needs udev to do that though, so udev is most often included - with its own tiny little set of rules.

    • As mentioned, initramfs is its own little complete linux root filesystem. A complete one might look like: /bin /etc /dev /new_root /proc /sys init. There's generally nothing very unusual about any of the contents of these directories - there's almost always a /bin/sh and an /etc/fstab.

    • Most inits will parse /proc/cmdline for any kernel parameters they might interpret. A very common one is root=/dev/somedisk or root=UUID=somediskUUID or root=LABEL=somedisklabel. It is the initramfs init that interprets these root=... parameters - not the kernel or the final init execed later (though the final one may very well interpret others). It will accept this parameter and mount it on /new_root (or whatever name it uses for the staging mount before it switchroots). If udev is included in initramfs then it is the initramfs ruleset that decides what that target disk's /dev/... entry is named for now - but that can change.

    • When the initramfs init successfully finds and mounts the /new_root device it usually looks for something to exec itself into - usually /new_root/bin/init - so whatever that program is becomes pid 1. It usually does this with the switch_root program provided with busybox - which does an exec while simultaneously mounting /new_root over /. Its process is described in the kernel docs thus:

    But initramfs is rootfs: you can neither pivot_root rootfs, nor umount it. Instead delete everything out of rootfs to free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs with the new root (cd /newmount; mount --move . /; chroot .), attach stdin/stdout/stderr to the new /dev/console, and exec the new init.

  • The root device init just execed now has to populate its own root filesystem. It calls its udev and mounts its own devfs on /dev based on its own ruleset and does all the rest. When it's through you are ready to use your computer.

Sorry for the level of detail there, but I wanted to make it clear why the following is true:

  • any kernel parameter you hand in from the bootloader like root=/dev/sda doesn't have to be the same /dev/sda that you will eventually access on /dev/sda after the initramfs /init is through.

So one way to do this, I think, is to set a udev rule on your anaconda disk - which is actually a squashfs archive, probably - that instructs it to setup all usb disks somewhere else. There's an excellent example here:

KERNEL=="sd*", SUBSYSTEMS=="scsi", ATTRS{model}=="USB 2.0 Storage Device", SYMLINK+="usbhd%n"

And it would be a very good thing if you read the rest of that link as well. You should be able to do that so your usb disk device is /dev/sda for initramfs - so you don't have to change any bootloader configurations - but then later creates a node for the same disk as /dev/usba for the anaconda install system.


go into the BIOS of the host and rearrange the order of the hard drives and removable drives. This will adjust the order as it appears to the Linux kernel.

  • Rearrange the boot order? Or is there another option in the BIOS to rearrange the order it 'finds' the drives. – skamazin Jul 22 '14 at 18:57
  • Different BIOSes are different; you'll need to play around with it. – Michael Martinez Jul 22 '14 at 19:00
  • The only options I could find were related to boot order. The default has "All USB HD" as the first drive to boot from. Moving the native HD to the top makes the machine boot into the current OS and it does not run the RHEL installer at all. =[ – skamazin Jul 23 '14 at 14:42
  • Yeah, some BIOSes are more limited than others. – Michael Martinez Jul 23 '14 at 17:50

On my shiny new but ancient $45 HP G60 laptop I was having the same issue. I made USB move from /dev/sda to /dev/sdb by putting the new SSD first in the boot order. Then on boot, press ESC like you're going into BIOS but there is a preBIOS menu. So instead of hitting F10 to enter BIOS, I pressed F9 for BOOT OPTIONS. Then in there you can manually choose to boot from USB regardless of BOOT ORDER set in BIOS. Obviously I chose the USB and then on installation my SSD was showing as /dev/sda.

I've searched and searched and many people have similar problems but no one suggested that. Much simpler than anything else I found. I discovered that on a hunch.


Starting in RHEL6 you can use labels for your install media such that you access the drive/hd by a unique name not the inconsistent kernel sdX naming.

When you create the file systems on your USB drive make sure to label them with something like e2label or the 101 other ways to label the file system.

Once labeled you can access the USB by that name ex: ks=hd:LABEL=yourname:/path/to/fs.ks

Also keep in mind this type of naming can be used for other locations as well. install media, repos, etc...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.