OEM hard disk replication SOLVED?

Tom H tomh0665 at gmail.com
Wed Mar 3 20:07:17 UTC 2010


>>> So for all you fellows out there trying to duplicate hard drives,

>>> Edit /etc/fstab
>>> # / was on /dev/sdaX during installation
>>> UUID=xxxxxxxxxxxxxxxxxxxxxxxxx  /       ext3    errors=remount-ro
>>> 0        1

>>> And

>>> # swap was on /dev/sdaX during installation
>>> UUID=xxxxxxxxxxxxxxxxxxxxxxxxx  none    swap    sw
>>> 0       0

>>> Replace the UUID=xxxxxxxxxxxxxxxxxxxxx with the relevant /dev/sdaX

>>> Then you need to regenerate your  grub

>> I just wanted to confirm... judging by this solution, I assume that for your
>> situation, the partition UUIDs were in fact changing when you duplicated the
>> disks?

>> If this is the case, it makes me a sad panda (or...confused, which may be
>> more appropriate here)... as I was under the impression, as someone else
>> pointed out, that duplicating the disk should preserve the partition UUID...
>> therefore making this a non-issue...

>> So, I suppose my question is this: How is the duplicator actually duplicating
>> the hard drives? Is it a bit-for-bit copy process? a straight partition copy?
>> something like a RAID mirroring process? I do know that at the very least, the
>> latter-most option does duplicate UUIDs (at least in my experience) since the
>> drives are treated as the same device...allowing you to boot from either
>> copy...

>> I ask this question mainly for posterity, but also out of sheer curiosity. Maybe
>> you could provide a link to your duplicator's spec sheet so I could research it
>> myself? (or if you don't want to for trade-secret reasons or whatever, a
>> duplicator similar to it?) thanks!

> Nope!  the problem is that the UUID is NOT changing and that is causing the problem.
> Duplicating the hard drive is preserving the UUID's. Because they are written into the
> grub.cfg and the efstab

Your duplication process must be changing the UUIDs because you would
otherwise be able to boot using the UUID values in grub.cfg and fstab.


> By enabling this setting and rebuild the grub config -
> GRUB_DISABLE_LINUX_UUID=true

> The system reverts back to /dev/sdaX dropping the UUID system altogether.
> But you still need to edit out the UUIDs from the fstab as I discovered this morning...

That is fine as long as no one adds a disk to one or more of your
computers and udev (possibly!) renames your boot disk /dev/sdb


> Now I am not entirely sure how it works. But it seems that grub has a lot to do with it.
> If I take the drive and plug it into a completely different spec machine, it boots and
> redetects all the hardware. No prob... that works as it was pointed out in one of the posts.
> But it is the same physical hard drive which I plug into both machines.
> Now because it is the same HARD DRIVE :) the UUID will always be the same hence why the hard
> drive can boot in any system.
> But when you duplicate the drive even block by block. The new or destination drives will each
> have their own unique UUID. But the image which is duplicated on those destination drives will
> contain the UUID of the master. Hence why the system fails to boot.

Am I misunderstanding? You duplicate a disk using your duplicator and
you can boot from that disk in some boxes but not others?!


> So to work around it you need to revert back the old school way of declaring the device in the
> two config files.

You could, post-duplication, either generate new UUIDs with tune2fs
and use these new UUIDs in grub.cfg and fstab or set the UUIDs using
tune2fs to the fstab UUID values.




More information about the ubuntu-users mailing list