[clue-tech] New System Configuration

[Jed S. Baer]

On Sun, 7 Oct 2007 14:44:36 -0600
Collins Richey wrote:

> On 10/7/07, Jed S. Baer <cluemail-jsb at freedomsight.net> wrote:
> 
> > The other option would be to partition, make the root filesystem and
> > swap, write an MBR, and then tar from the old drive to the new one.
> > I'd have to boot a live CD to do it, which is no biggie, I guess.
> > What issues would I have with this?
> 
> I've done the equivalent quite a few times, and it's no big deal.
> Quite literally, the only problem you'll have is with fixing up
> /boot/grub/menu.lst and /etc/fstab. Unbuntu and Debian now use UUID
> for everything, and there's one little gotcha waiting in
> /boot/grub/menu.lst.
> 
> 1. use 'blkid /dev/sdxx' (address of the root partition) and again for
> the swap partition to get the UUID values for your new partition(s).

Well, now that is interesting. Does the UUID value for filesystems/swap
remain constant, even when moved to another machine? While the manpage
doesn't say this, it seems implicit in the description, where it states
that it reads this data from the block device.

>From the Google, I see that UUID stands for Universally Unique
Identifier, and digging further, I find the uuidgen manpage,
and /etc/blkid.tab. Oh joy!

> 2. in /boot/grub/menu.lst, pay attention to the following lines which
> look like comments, but trust me they are not. Here's an example from
> mine. These will have values for your old disk and you need to modify
> them for the new partition.
> 
> # kopt=root=UUID=c9cd073d-f3e0-4510-95be-d040d1fd6c6a ro
> ...
> # groot=(hd1,7)
> 
> The next time you install a kernel, the update-grub procedure that is
> run under the covers will ignore values for your running system and
> blindly use these values to reconstruct all boot stanza entries
> entries for your Ubuntu system!!! If you didn't change them, you're in
> for an ah sh*t - system recovery again.

Well, it seems my menu.lst is already using UUIDs. My kopt is commented
out, but all the kernel lines say root=UUID=...

Thinking about that, it explains why the system managed to come up as far
as it did.

> 3. Finally /etc/fstab. You're beginning to get the picture that UUID
> is king in Debian land. RH systems use partition labels for the same
> purpose. This is all to get around the problem that the bios may
> renumber drives when you add new drives, but the UUID and the labels
> remain constant.

Labels can be a problem. Just another aside. We run into this at work
sometimes, but we also are reconfiguring test systems all the time.
However, it's easy to imagine it happening in the enterprise. If you
re-use a drive with a common label, maybe / or /home, sometimes, RH will
mount the wrong one. I haven't had that happen with those two labels, but
in IA64 land, /boot/efi is always there, and if I do an install, then
plug in a JBOD and reboot, and that JBOD was previously used for the
system partitions, well, there you have it. If, at work or home, you
decide to retire a machine and reuse the drives in another, and you're
running RH, you might hit this one.

SuSE has a different problem, which I won't belabor.

Suffice it to say that both RH and SuSE would benefit from switching to
UUIDs.

> # added by rebuildfstab [/dev/sdb8, no label]

Well, it looks to me as if I should be able to just run rebuildfstab on
my existing system, then plug the drive into the new box and boot without
any complaints other than not having swap. Yeah, I'd test the reboot
first.

> Good luck.

Thanks. I definitely could use a bit. But that's some other news.

jed