• Welcome to Overclockers Forums! Join us to reply in threads, receive reduced ads, and to customize your site experience!

Persistent device naming help

Overclockers is supported by our readers. When you click a link to make a purchase, we may earn a commission. Learn More.

Misfit138

Member
Joined
Mar 23, 2005
Location
Jersey
I need some help from the gurus!

I recently added a 3rd SATA drive to my system, to try out Vista.
So now I have 3 SATA drives. 2 Seagates, (One 80 GB and one 160 GB) and one WD 250 GB.
My trouble is, I believe I have 2 sata controllers on my mobo (nVidia and promise) and each control 2 headers. Each time I reboot, the drives are recognized differently. Adding linux to the 80 gig drive has been problematic because of this.

Off the top of my head, (I am at work) my grub is very simple for now. Something like this:
Code:
title Linux [vmlinuz26]
root (hd1,0)
kernel /vmlinuz26 root=/sdb1 vga=773 ro
initrd /kernel26.img
That would not boot at all.. wrong fs type (being redirected to an NTFS volume, I guess).

changing it to this helped a little bit:

Code:
title Linux
root (hdo,0)
kernel /vmlinuz26 root=/sda1 vga=773 ro
initrd /kernel26.img
But I get a kernel panic, not syncing error.

So I got a suggestion to use PDN, via /disk/by-label in GRUB and fstab.

So I am thinking my grub should look like this:
Code:
title Linux
root (hd0,0)
kernel /vmlinuz26 root=/dev/disk/by-label/root vga=773 ro
initrd /kernel26.img
BUT....here is my question:
If my SATA drives are randomly changing names, WHAT should my "root (hd0,0)" line read?
Won't that line be haunted by the same issues, even though I utilize disk/by-label on the kernel line?

Help.
 
I've never heard of anything like that happening. That's really weird. udev lets you control how linux assigns device names, but that is well after grub gets to them.

Have you considered going into bios and manually assigning IRQ's to your pci devices? This might fix the order in which they are recognized.
 
Well, I was right in my guesses. (for once).
The /dev/disk/by-label worked beautifully. Thanks for the response, MRD. More info for your reading pleasure:


http://wiki.archlinux.org/index.php/Persistent_block_device_naming
http://www.nslu2-linux.org/wiki/HowTo/MountDisksByLabel

An exerpt:

Why persistent naming?

While Linux distributions and udev are evolving and hardware detection is becoming more reliable, there are also a number of new problems and changes:

* If you have more than one sata/scsi or ide disk controller, the order in which they are added is random. This may result in device names like hdX and hdY switching around randomly on each boot. The same goes for sdX and sdY. Persistent naming allows you not to worry about this at all.
* With the introduction of the new libata pata support, all your ide hdX devices will become sdX devices at some point in the future. Again, with persistent naming, you won't even notice.
* Machines with both sata and ide controllers are quite common these days. With the libata changes mentioned above, the first problem will become even more common, as sata and ide hard drives will both have sdX names.
* Persistent naming just looks prettier.
 
Last edited:
GRUB root (hdx,y) labels are determined by the BIOS, which should remain constant boot-to-boot. The root= bit in the kernel line, on the other hand, is used by the linux kernel after it has loaded, which explains why it helped: You told GRUB to boot from the first device instead of the second, which got it accessing the linux disk, where /dev/disk/by-label could then work after udev scrambled everything ;p
 
ponkan pinoy said:
GRUB root (hdx,y) labels are determined by the BIOS, which should remain constant boot-to-boot. The root= bit in the kernel line, on the other hand, is used by the linux kernel after it has loaded, which explains why it helped: You told GRUB to boot from the first device instead of the second, which got it accessing the linux disk, where /dev/disk/by-label could then work after udev scrambled everything ;p

Excellent explanation. Thank you so much for this simple but excellent information. When people take the time to share their knowledge the whole community can grow and benefit.
 
Back