failing to boot pass mdadm monitor

Asif Iqbal vadud3 at gmail.com
Mon Mar 12 21:22:50 UTC 2012


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.


>
> Peter
>
> --
> ubuntu-server mailing list
> ubuntu-server at lists.ubuntu.com
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-server
> More info: https://wiki.ubuntu.com/ServerTeam



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




More information about the ubuntu-server mailing list