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

[Jan Kundrát]

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.

Cheers,
Jan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://oss.sgi.com/pipermail/xfs/attachments/20110406/1da79be8/attachment.p7s>