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

["Jan Kundrát" <kundratj@fzu.cz>]

[-- Attachment #1.1: Type: text/plain, Size: 1176 bytes --]

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


[-- Attachment #1.2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4354 bytes --]

[-- Attachment #2: Type: text/plain, Size: 121 bytes --]

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs