OEM hard disk replication SOLVED?

[Karl F. Larsen]

Chadley Wilson wrote, On 03/03/2010 11:00 PM:
>>
>> 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.
> Here is my theory for now, here goes... :)

	Here is another theory. I hate UUID because it is an 
automatic way to define the partitions. These are always a 
problem if you ALSO change the BIOS. Try this: Replace the 
UUID partition name with the actual partition name in 
/boot/grub/grub.cfg. The actual name is like /dev/sda3. Then 
Grub2 should boot proper on all the bios you have.


73 Karl



>
> 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 think that sums it up from my side.
>
> Thanks again...
>
>
> Pinnacle Technology Holdings E-Mail Disclaimer:
>
> This e-mail is confidential and intended solely for the use of the individual(s) to whom it is addressed. Any views or opinions presented are solely those of the author and do not necessarily represent those of Pinnacle Technology Holdings any of it's divisions or affiliates. If you are not the intended recipient, be advised that you have this e-mail in error and that any use, dissemination, forwarding, printing, or copying of it is strictly prohibited.
>


-- 

	Karl F. Larsen, AKA K5DI
	Linux User
	#450462   http://counter.li.org.
         Key ID = 3951B48D