Nathan J. Mehl wrote:
This may fall under the heading of "Doctor, it hurts when I do this",
but here's trying...
Per Eric Sandeen's take a few days ago, mkfs.xfs was failing to
properly clear the signatures of any underlying filesystems on the
partition being mkfs'ed, causing gnu parted to fail to recognize an
XFS partition as such, in turn causing Anaconda's upgrader to fail.
The primary partition on my workstation was in exactly that state:
parted was recognizing it as a linux swap partition, due to the
signature of a swap file ("SWAPSPACE2" at offset 4086) still being
In an attempt to clear this, I did the following:
dd if=/dev/hda5 of=outfile bs=4096 count=1
I then ran ghex (the gnome hex editor) on "outfile", and changed
"SWAPSPACE2" to "SW4PSP4C32". I then saved the file to a floppy,
booted off of the xfs linux rescue cdrom, mounted the floppy, and
wrote those four kilobytes back to the partition:
dd if=outfile of=/tmp/hda5 bs=4096
This appeared to work, and the partition survived an xfs_repair with
only a few small errors. Unfortunatly, parted still believed the
partition to be swap, so I repeated the process again, this time
zeroing out the last 10 bytes completely. After that was done, parted
recognized the partition as XFS, and an xfs_repair run on the
partition completely cleanly, with only one notice about rebuilding
the inode for directory 128.
Well, this is the root inode, and if it had to do surgery on it, repair
disconnected all your other inodes. Now, it should put them in lost+found,
and in theory you can work out which one is which and rename them back
again. Unless repair is nice and gives you whole subtrees in there this is
not exactly a workable solution.
What did repair say about your inode?
Also, I assume all the editing of the first 4K was done with the filesystem
offline, in which case if you did really just overwrite those 10 bytes,
all should have been well. I cannot see how XFS can be using that
part of the disk. If you wrote the 4K whilst the filesystem was
online then yes, it is probably toast.
I then rebooted into the XFS installer, and attempted an upgrade,
which failed with a "partition out of space" error when it tried to
rebuild the RPM database. As the partition was a 70gb one at less
than 50% utilization, this seemed unlikely, so I rebooted back into
the rescue image and tried to run xfs_repair on it again. At this
point, all hell broke loose: xfs_repair could not find the first
superblock, and after finding the second superblock, it failed at the
step of trying to zero out the log, claiming that it could not find
the log header, or words to that effect.
At this point, I am stymied. xfs_repair will not progress beyond the
log-clearing step. "xfs_repair -n" reveals thousands of inode errors;
enough that I haven't had the patience to let it scroll through to the
end. (I gave up after about 4 minutes.)
I'm prepared to assume that this FS is a total loss, and I expext that
I've broken something badly by restoring an out-of-date (even if only
by minutes) first 4k of the partition. But just in case, I'm throwing
it to the list -- does anybody know any tricks for persuading
xfs_repair to cope with these sorts of situations? The manpage makes
tantalizing reference to "subopts", but the only one mentioned is
"assume_xfs", which probably isn't helpful in this case.
Many thanks in advance,
"You don't qualify as the typical male snakebite victim: you weren't drinking,
you don't have any tattoos, and you have all your teeth."