[Top] [All Lists]

Re: SL's kickstart corrupting XFS by "repairing" GPT labels?

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: SL's kickstart corrupting XFS by "repairing" GPT labels?
From: Jan Kundrát <kundratj@xxxxxx>
Date: Wed, 06 Apr 2011 16:31:13 +0200
Cc: xfs@xxxxxxxxxxx, lcg-admin@xxxxxx
In-reply-to: <20110406114146.GF31057@dastard>
References: <4D9C3E14.6030009@xxxxxx> <20110406114146.GF31057@dastard>
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20101027 Thunderbird/3.1.6
On 04/06/11 13:41, Dave Chinner wrote:
>> Mar 30 14:04:44 dpmpool5 kernel: Please umount the filesystem, and
>> rectify the problem(s)
> Did you do this?

Not immediately, I wasn't the person immediately handling the issue. My
colleague did unmount that filesystem and ran xfs_repair on it, and was
successful in recovering most of the data.

>> zerombr yes
>> clearpart --all --initlabel
>> part swap --size=1024 --asprimary
>> part / --fstype ext3 --size=0 --grow --asprimary
> There your problem - hello random crap....

Oh crap. "--all" is all, indeed. Well, thanks for clarification, we were
stupid after all :).

> Given the nature of the problem, I have to assume you aren't using
> FC zoning to prevent hosts from seeing disks that don't belong to
> them?

Nope, zoning unfortunately wasn't active.

>> Would a "restore" of GPT partition table at the
>> beginning of a disk from the copy at the end qualify as a possible
>> candidate?
> No. The log messages have already told you what your next step is.

I meant that as "a candidate for the thing to blame for corruption", not
as a next step to undertake.


Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

<Prev in Thread] Current Thread [Next in Thread>