Mark Knecht posted on Tue, 02 Jul 2013 10:06:31 -0700 as excerpted: > On Mon, Jul 1, 2013 at 2:10 PM, Paul Hartman > <paul.hartman+gen...@gmail.com> wrote:
>> I recently upgraded my machine and disks and am using UUID and labels >> for everything, I can literally boot from either the old HDD or new HDD >> from my BIOS boot menu, plugging them into the motherboard in any >> order, and either one will work properly, even though the /dev/sdX >> assignments might change from boot to boot. You can use the blkid >> command (as root) to see the labels and UUIDs for all of your drives >> and partitions. > Thanks for the interest and sorry for the delay in my response. > I've ended up going in a slightly different direction in the process > which as of yet hasn't yielded much except more work for me. No response > is necessary to this post, although I'm always interested in what folks > are doing and thinking. Sounds like me. =:^) > For the SDD boot I just point the root & kernel commands to the first > partition on the SDD. > > This has worked and the SDD boots reasonably well, but it is > fragile. It appears that drive ordering changes from boot to boot > depending on which USB drives are attached so I probably need to move to > something more like your UUID methods. > > Lastly, because I am still running on the original RAID6 setup I do > not want to touch the internal SATA cabling at all. It's important to me > that the currently working setup continue to work. That sounds like me too. =:^) (I eventually changed the cabling/order, but not until I had the new setup tested and working to my satisfaction.) For the kernel commandline, if you're using an initr* (as you are, IIRC), and if that initr* has udev on it (since it's the bit that allows this to work), I know for sure you can use root=LABEL=rootfslabel (where targetfslabel is the label of your "real" rootfs), and it should "just work". Similarly with root=UUID=rootfsuuid based on the documentation, tho I've not actually tried it here so don't have the personal experience I have with label. I've even been /told/ that you should be able to use anything available in /dev/disk/by-*, including PARTLABEL and PARTUUID (as available on gpt partitions), as well as ID (which should be based on the physical drive model/serial number). However, I've only seen that from one source and have not actually tried it myself, so the confidence level in that is somewhat lower. Also, apparently udev doesn't detect/create the usual by-part* symlinks for mdraid and possibly lvm2 yet. Or at least it wasn't doing so a few months ago when I was actually still running md/raid (not btrfs in raid1 mode as I'm doing now). So even if it's gpt partitioned md/raid and you can see the partition-labels in your gdisk/cgdisk/parted/whatever, if udev isn't creating the symlinks in /dev/disk/by-partlabel, mount can't see them and they can't be used. Because the way all this works is mount can read udev's /dev/disk/by-* symlinks, and that's what's really doing the rootfs mount in this case, the mount on the initr*. (Caveat, I'm not sure busybox mount handles that, nor do I know what its device-manager does in terms of creating those links like udev does by default. So if your initr* is based on that instead of standard udev, plus mount from util-linux...) But a udev-and-util-linux-mount-based initr* should certainly handle at least root=LABEL= just fine, as it's doing so here. That handles the root= bit. There's also the grub bit itself. Grub needs to be pointed at the correct kernel. But that should be easy enough, as long as you're putting it on the same /boot that your grub is pointing at. Meanwhile, once real-root is mounted and you're doing the regular boot, the regular fstab mounts (the localmount service for openrc) should "just work" with labels, and in fact, I've been routinely using LABEL= in the first fstab field for quite some years now. But AFAIK, the kernel itself can't handle root=LABEL style commandline options without an initr*, because AFAIK it doesn't have the necessary mapping. udev and mount handles that in userspace, which means in ordered for it to work, userspace, either on the realrootfs, or on the initr*, must already be going before it'll work. Which leaves initr*-less folks using the old root=/dev/* or root=nnn:nnn (major:minor device numbers) formats, which aren't as flexible in terms of device reordering. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
