(hd0) /dev/sda
(hd0) /dev/disk/by-id/scsi-3600508b1001c8a3ec4c301f8d86386b8
Is there any reason why it should have taken up this setup.
The d/dev/sd* device names are non-persisting, iow they might change between reboots. I’ve only seen this happen when swapping disk devices (physically), so the impact on “ordinary” server installations isn’t that big… but “it was decided” that in order to address specific disks, some unique identifier should be used, which is what you’re seeing in the second syntax.
Now while you will not have to watch out if /dev/sd* changes when you’re re-arranging your physical disks and/or adding new ones, you’ll have to remember to adjust the “persistent device names” when you exchange such disks. But at least, this “new” way add stability and makes device handling less random.
BTW, there are various different “by-*” entries for many devices / file systems, so you have a certain amount of flexibility, depeding on your needs (i.e. referencing file systems by disk UUID/partition name, vs. per name, or using PCI bus IDs for certain devices).
Thanks for the suggestion. I know that persistent naming is always preferred. But is there a way we can use this in the root line of grub’s menu.lst ? I guess grub has limitation in this case.
eg:
title SUSE Linux Enterprise Server 11 SP3 - 3.0.101-0.31
root (hd0,1) <— In here
kernel /boot/vmlinuz-3.0.101-0.31-default root=/dev/disk/by-id/scsi-3600508b1001c17428a66591e1ffb8275-part2 resume=/dev/disk/by-id/scsi-3600508b1001c17428a66591e1ffb8275-part1 splash=silent crashkernel=256M-:128M showopts vga=0x314
initrd /boot/initrd-3.0.101-0.31-default
as persisting naming is a feature that is only available once the Linux file systems and udev are up & running, grub (as a pre-boot subsystem) has no chance to access up-to-date information from /dev/disk/by-*. So using persistent names in grub is not an option.
The options on the kernel line are handed on to the initrd environment, which already runs some udev support, so the by-* names are ok there (and not evaluated by grub, but simply passed on).
For completeness sake, please keep in mind that grub2 is a totally different story (but not used in the setup discussed in this thread).
Thanks for the answer. I have read that grub would understand the following:
(hd0,0) First Disk, First Partition
(hd0,1) First Disk, Second Partition
(hd1,1) Second Disk, Second Partition
May I ask if grub would use the file /boot/grub/device.map? Is there any significance for this file during startup or while referring to the actual disks.
[QUOTE=vijish;27326]Thanks for the answer. I have read that grub would understand the following:
(hd0,0) First Disk, First Partition
(hd0,1) First Disk, Second Partition
(hd1,1) Second Disk, Second Partition
May I ask if grub would use the file /boot/grub/device.map? Is there any significance for this file during startup or while referring to the actual disks.
according to a manual page (https://www.gnu.org/software/grub/manual/legacy/Device-map.html), device.map is read by the grub shell, and stage2 (the part run at boot time) is not mentioned. From the description, it looks like the file is used to provide grub with the required information to put the proper BIOS device names (“hd0,0”) into the menu file used by stage2.
Disclaimer: I’ve not dug that deep into the internals of Grub, so if anyone has contradicting/correcting information, please add to this thread!