failing to boot pass mdadm monitor

[Asif Iqbal]

On Mon, Mar 12, 2012 at 5:22 PM, Asif Iqbal <vadud3 at gmail.com> wrote:
> On Mon, Mar 12, 2012 at 5:11 PM, Peter M. Petrakis
> <peter.petrakis at canonical.com> wrote:
>>
>>
>> On 03/12/2012 04:13 PM, Asif Iqbal wrote:
>>>
>>> I am failing to boot this server x4270 pass the mdadm --monitor.
>>> Installed lucid amd64. This is a first install.
>>>
>>> details: http://paste.ubuntu.com/880895/
>>>
>>> It boots all the way in recovery mode. what gives?
>>>
>>
>> I would say your problems began once your partition detection went
>> inconsistent.
>>
>> [   26.603469] sd 6:0:3:0: [sdd] 585937500 512-byte logical blocks: (300
>> GB/279 GiB)
>> [   26.603599] GPT:Primary header thinks Alt. header is not at the end of
>> the disk.
>> [   26.603600] GPT:585937498 != 585937499
>> [   26.603602] GPT:Alternate GPT header not at the end of the disk.
>> [   26.603603] GPT:585937498 != 585937499
>>
>> which is coming from fs/partitions/efi.c
>> http://lxr.linux.no/linux+v3.2.9/fs/partitions/efi.c#L487
>>
>>  494        if (le64_to_cpu(agpt->my_lba) != lastlba) {
>>  495                printk(KERN_WARNING
>>  496                       "GPT:Alternate GPT header not at the end of the
>> disk.\n");
>>  497                printk(KERN_WARNING "GPT:%lld != %lld\n",
>>  498                        (unsigned long long)le64_to_cpu(agpt->my_lba),
>>  499                        (unsigned long long)lastlba);
>>  500                error_found++;
>>  501        }
>>
>> The math for lastlba seems correct, 585937500 - 1ULL, a quick google shows
>> the raw size is consistent with what you have. So the question is how
>> did 585937498 get computed? Would someone with some more experience with
>> GPT partitions care to comment?
>>
>> It doesn't look like your system successfully recovered from find_valid_gpt
>> or we would have seen "Alternate GPT is invalid, using primary GPT." or
>> "Primary GPT is invalid, using alternate GPT." in the logs. Those
>> partitions,
>> or what's left of them, is being presented to mdadm for assembly.
>>
>> This part is really weird.
>>
>> [   27.929744] mdadm: sending ioctl 1261 to a partition!
>> [   27.935401] mdadm: sending ioctl 1261 to a partition!
>> [   27.941905] mdadm: sending ioctl 1261 to a partition!
>>
>> Where 1261 is #define __NR_set_mempolicy              1261
>>
>> I don't think that has any business being sent to a partition. At the
>> moment,
>> I can't explain how this event, and the GPT fault could be related.
>>
>> [   28.679619] md1: detected capacity change from 0 to 146360172544
>> [   28.684287]  md1: unknown partition table
>> [   28.709647] mdadm: sending ioctl 1261 to a partition!
>> [   28.713255] mdadm: sending ioctl 1261 to a partition!
>> Begin: Running /scripts/local-premount ...
>> Done.
>> [   29.082318] EXT3-fs: INFO: recovery required on readonly filesystem.
>> [   29.088849] EXT3-fs: write access will be enabled during recovery.
>> [   29.252295] kjournald starting.  Commit interval 5 seconds
>> [   29.252387] EXT3-fs: recovery complete.
>> [   29.265115] EXT3-fs: mounted filesystem with ordered data mode.
>>
>> I really don't know what shape your backing store is in, noting your
>> second post, I'm surprised your disks are readable.
>>
>> So... what changed? Have you upgraded system firmware recently,
>> kernel upgrades, or anything at all really? I see you have an external
>> storage enclosure, has that seen any changes either?
>
> This is a new box. This is the first install. There is nothing attached to it.
>

I am going to reinstall the OS. Should I reformat the disks maybe?

>
>>
>> Peter
>>


-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?