** John Cooper <lug@???> [2010-09-28 10:48]:
> On 28/09/10 10:15, Paul Tansom wrote:
>> I must be missing something obvious on this, but I've done it before without
>> problems and, although I've got a bit more investigating up my sleeve, this one
>> is getting annoying!
>>
>> I've got a system (Ubuntu 8.04 LTS Server) that is running quite happily on a
>> software RAID mirror. One drive needs swapping, which I have just done without
>> problems until I want to swap and replace the second one as well. Before I
>> removed the failing drive I checked that I had grub installed in the boot
>> sector of both drives and that I could boot off the good drive without the
>> failing one connected - no problems whether connected to SATA1 or SATA2 on the
>> motherboard.
>>
>> I installed the second drive, matched up the partition sizes, rebooted and
>> resync'd the partitions. All is working fine - except...
>>
>> If I remove the original drive to boot purely from the new one (as I did
>> initially for the first swap out) I cannot boot. Grub has been installed in the
>> boot sector, but somewhere there must be a direct reference to the original
>> drive with some form of identification. I just can't think what!
>>
>> If the drive is connected to SATA1 the boot hangs after the grub menu with:
>>
>> Loading please wait...
>>
>> at the top of the screen, and at the bottom:
>>
>> Kernel alive
>> kernel direct mapping tables up to 100000000 @ 8000-d000
>>
>> Which is exactly what you see during a successful boot.
>>
>> If the drive is connected to SATA2 the boot fails with
>>
>> GRUB Hard Disk Error
>>
>> Clearly it is looking for something that has to be on SATA1 and seems to want
>> the original drive. Oddly the original drive still boots on either SATA1 or
>> SATA2 without problems. The entire disk is sync'd with the RAID mirror so the
>> drive contents are the same, and grub has been installed in the same way to
>> both drives. Both drives are of the same capacity (500G and amazingly the
>> capacity matches exactly, not just in marketing termes), although the original
>> is Samsung and the new one is WD.
>>
>> Anyone have any ideas? I'm about to double check the location of
>> /boot/grub/stage1 at the grub boot stage in case that is different. There's
>> half a temptation to install 3 drives at the same time to sync up the new
>> drive, but I'm not happy to do that until I can boot cleanly of the new drive
>> on its own.
>>
>> This is annoying as I've done the same process before (admittedly on PATA not
>> SATA) and even done it to higher capaicty drives and then grown the partitions
>> to use the extra space.
>>
>
> Paul, is this a UUID problem. Both grub and fstab can state unique UUIDs
> and LVM names (fstab also can use disk label names). My grub has
>
> rd_LUKS_UUID=luks-411e43ee-XXXX-XXXX-XXXX-XXXXXXXXXXXX
> rd_LVM_LV=vg_mail/lv_root rd_LVM_LV=vg_mail/lv_swap
>
> in the kernel line. fstab has root partition as
> /dev/mapper/vg_mail-lv_root amd /boot as UUID=XXXXX
** end quote [John Cooper]
That was my thought, but as yet I've found no way to check the UUID in use or change it.
/boot is on the root partition, not on separate one. The UUID in fstab refers
to /dev/md0, so I would assume that even if one of the drives used for this
mirror changes the UUID should remain the same. the grub menu.lst makes no
reference to UUID, and having run grub-update and install-grub /dev/sda and the
same for sdb I would hope that any changes to UUID have been accounted for.
Those top two lines from grub don't look familiar at all in format. All my
references are /dev/mdx ones. I was looking to invextigate any issues with the
groot values, or possibly the updatedefaultentry perhaps. I need to read up a
bit more.
--
Paul Tansom | Aptanet Ltd. |
http://www.aptanet.com/ | 023 9238 0001
======================================================================
Registered in England | Company No: 4905028 | Registered Office:
Crawford House, Hambledon Road, Denmead, Waterlooville, Hants, PO7 6NU
