I agree with the UUID stuff, I do not like them for the exact same reason. I do not understand why RedHat cannot include the partition into the UUID, e.g.
dev-sda1-c05e-449a-837b-b2579b949d55
As for the first drive, when the kernel boots I think it assigns the drives in order of the controller on the system bus/slots. As the new controller sits lower in the slot system (i.e. closer to the CPUs) it is recognised first as I can see it appearing first in the order being initialized by the kernel. I cant move it below the old card as there is no slot that has the correct PCI-x8.
I will try the LABEL way of doing ....
I remember that was the same problem a few years back when one had multiple network interfaces .... until the MAC addresses where introduced into the ifcfg files.
Jobst
On Thu, Aug 23, 2012 at 09:40:24AM -0400, m.roth@5-cent.us (m.roth@5-cent.us) wrote:
Markus Falb wrote:
On 23.8.2012 14:01, Jobst Schmalenbach wrote:
Hi Adrian
yes this will do. Because I do not know (yet) the UUID of the new partitions (drives), if I specify the UUID for the known drives for the partitions the kernel will assign the new drives to higher sdx? Is this correct?
After reboot sdx could be sdy, as you noticed. The solution: you dont access a drive via /dev/sdx You access per UUID and the kernel maps it to the appropiate sdXY which could be sdy after reboot.
You can also label it. I loathe UUIDs - there is *no* way you're going to remember one when you need it. Labels are so much clearer.
I am not sure about initial ramdisks etc. maybe there is hardcoded stuff to sdx in there. Maybe it has to be rebuilt? Maybe you has to rebuild initrd as well as updating fstab?
I've actually never seen a system *not* know what the first drive was, hardware-wise. And grub will point to root hd(0,x), normally, not UUID or anything else. You *can* (and I do, all the time) use LABEL= on the kernel line.
mark
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos