>>> In my experience, >>> the UUID is also embedded internal to the initrd.img >>> and this also should be consistent with the UUID in grub.conf >>> [root@localhost clean]# less init >>> near the end look for "mkrootdev" line: >>> echo Creating root device. >>> mkrootdev -t ext3 -o defaults,ro >>> UUID=54c84c0a-040b-43bd-8887-202519baaae2 >>> So my question remains: >>> If i try to use labels instead of UUID, do i have to modify this >>> mkrootdev line in init (initrd.img) ? > I believe this was Tom H's question, not mine although I am the > threads OP. No. I was just replying to the "my question remains" above. I have not asked any questions in this thread and I had no idea that the question was not being asked by the original OP. I have looked up your original questions in the archive: (1) How do I go about doing a grub-install in a manner that when I take out the dying drive and move the new drive to SATA0, it will reboot from this new drive? Booted from your old drive, chroot to your new drive and run grub-install, etc... If your fstab uses labels or uuids, you will have to update it. (2) I just checked, and /etc/fstab is using UUID's, how can that be fixed, or should I just put it back to LABEL's and be done with it. That drive is labeled, but I don't believe its /boot for /boot, so how do I get the labels off the drive? Or should I just relabel it to gigo? More or less answered above. Use tune2fs (if you are using ext2/3/4) to set the labels (or the uuids if you want to set them by hand). (3) And, if I rsync each directory tree to the new drive, will that move the UUID and/or labels too? No. The label and uuid are in the superblock and its backups and will not be copied by rsync. >> As long as the UUID in init (in initrd) and the root entry in >> grub.conf (whether UUID, LABEL, or /dev/xxxx) point to the same >> partition, you are OK. > You may want to check your facts on that actually being in the > initrd file. My 2.6.32-rc6 initrd, copied from the failing drive > with 'rsync -avcAX src target' syntax, which I booted with after > swapping a new drive onto the sata1 connector, did not require a > rebuild, I simply changed grub.conf to use a > 'root=LABEL=sea-slash' while in rescue mode and chroot'ed, fixed > a couple of other typu's, did a 'grub-install /dev/sda" and > rebooted. If its in there, then it is apparently being > over-ridden by the data in the new /etc/fstab. My facts are correct and I do not need to check them but I will re-phrase my statement: You can refer to the / of a disk with /dev/sdX, label, uuid in the kernel line of grub.conf, the / line of fstab, the mkrootdev line of init in initrd as long as they all refer to the same disk - and you can mix and match the three ways in the same install. > Logically, the root (hd0,0) must over-ride any UUID's that may > be in the initrd.img, otherwise it could not possibly have found > even the grub.conf to show me at boot time. The root line of grub.config does not refer to / but to the partition that holds the grub files. The kernel line sets where / is through the "root=" statement. Since you have /boot on a separate partition, you can check that directly. > Some _real_ docs on grub would be VERY nice. There is good documentation for grub 0.97 (grub 1): http://www.gnu.org/software/grub/manual/grub.html Grub 1.97 (grub 2) is less well documented. There is a wiki that http://www.gnu.org/software/grub refers to. It is http://grub.enbug.org (Why this could not be within the http://www.gnu.org/software/grub is a mystery to me.) https://help.ubuntu.com/community/Grub2 also has some good information given that Ubuntu is now using Grub 2 by default for new installs. >> That it why you can switch the grub.conf entries without >> having to change the UUID (or whatever other way that you >> are pointing to the root partition). > In my case, /boot is a separate partition, so in base 0 > notation, its all 'root (hd0,0)' on a line by itself. And it > Just Works(TM) I can, in a different grub.conf stanza on > (hd0,0)/grub/grub.conf, specify root (hd3,0), then the UUID of > the / partition that contains another distributions / directory > and boot to it just fine. See above. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
