|
|
>>> 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.
--
ubuntu-users mailing list
ubuntu-users@xxxxxxxxxxxxxxxx
Modify settings or unsubscribe at:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
|
|