OEM hard disk replication SOLVED?

[Tom H]

>> 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.

> Nope again,

> Look I am no expert on the subject, the way that I understand
> this could be wrong, but I am sure that I am on the right track,
> maybe in the wrong lane.

> I know Grub 1 inside out, grub 2 is lot more complex, and I
> think that it will take a while to work out what the scripts do
> and how it works.

grub2 is not more complex than grub1. Unlike grub1, grub2 has a few
scripts to build its config but it is mostly developer porn. The
"menuentry" stanzas are all that really matters in the config and they
are not substantially different from grub1's "title ..." stanzas.
grub2's boot.img is grub1's stage1 and grub2's core.img is grub1's
stage1_5 and stage2 (and, on mbr partitions, sits where stage1_5 use
to). grub2 does have some advantages though, namely grub-rescue and a
/boot that can be ext4'd, mdadm'd, or lvm'd.


> Here is my theory for now, here goes... :)

> The duplication is NOT changing the UUIDs. I have confirmed
> this.

> To test the theory I have taken the hard drive loaded with
> Ubuntu 9.10 on a MSI G31 mainboard, I then remove the drive and
> plug it into an Intel DQ45CB. It boots. Why because it is
> physically the same hard drive and therefore the UUID matches.
> So I thought?

> I then take the same hard drive and plug it into another G31,
> and another and another and it also works. I checked the UUID
> values and it remains the same. OK...

> It makes sense that UUID is the same because the HDD is the
> same.

> So I take the drive to my duplicator and make 12 copies. I check
> each of the 12 copies on the G31 and none of them boot. All
> report a kernel error, not enough available free memory. But
> interestingly in the next test I plug them into the Intel board
> and they all boot.

> In the results on the G31 board I made a point of checking the
> UUIDs, since none of the drives boot, I boot into rescue command
> shell, I check the fstab and the grub.cfg. If found the UUIDs
> are still exactly the same as the master, and check the values
> of the fstab, and grub.cfg. The UUIDs have not changed. They are
> the same.

> When I repeat the test on the Intel board and all the drives
> boot. I check the fstab and the grub.cfg the UUIDs HAVE changed.
> Each drive has a different UUID.

> This is where I could be in the wrong lane. Suppose the bios has
> something to do with it, the bios on the G31 is identical. The
> OS sees no reason to reconfigure. But when you insert the drive
> into the Intel board, the OS detects that the bios is different
> and starts to reconfigure all the hardware. This could explain
> why the drive loaded on the MSI board can be duplicated and then
> works on the Intel board.

> Each physical hard disk will have its own unique UUID.

> So by duplicating the UUID is NOT changing. The fact that it is
> not changing is where the problem lies.

> When the installer installs, it probes the hardware, now each
> piece of hardware will have some sort of unique element, for
> argument sake the HDD will have a serial number.

> When the system installer starts it will probe the hardware, and
> generate a unique UUID which it links back to the physical
> device </dev/sdaX>. The UUID is only valid for the specific
> piece of hardware.

> So if you duplicated the drive the UUID would point to a
> different piece of hardware, i.e. the master drives UUID. Hence
> why it fails to boot.

> So I would suggest that what is needed is a boot switch to tell
> the OS to redetect and reconfigure the hardware.

I very much doubt that the BIOS can modify a partition's superblock or
files on that partition, so your theory does not make sense to me.

How are you checking the UUIDs of the HDs? Are you just looking at
fstab and grub.cfg or are you running blkid? Anyway, since you can
boot using UUIDs with the Intel boards, neither grub nor the UUIDs are
at fault for the MSI boot failures, especially since your MSI boots
fail because of a kernel error.