My Lenovo netbook crashed and it can’t boot anymore, it seems something’s got corrupted and it can’t mount sda2. I loaded a rescue version of opensuse on a Live USB, and when I try to mount the partition it gives the following message:
Error mounting /dev/sda2 at /run/media/linux/275642f1-154a-42f4-928f-0af92854dede: Command-line `mount -t “xfs” -o “uhelper=udisks2,nodev,nosuid” “/dev/sda2” “/run/media/linux/275642f1-154a-42f4-928f-0af92854dede”’ exited with non-zero exit status 32: mount: mount /dev/sda2 on /run/media/linux/275642f1-154a-42f4-928f-0af92854dede failed: Structure needs cleaning
Is there anything I can do from this Live USB that can fix the partition so I can boot from the hard drive normally? There’s probably more info needed to answer this question, but I have no idea what it may be. Please, let me know.
linux@linux:~> sudo fsck /dev/sda2
fsck from util-linux 2.25.1
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_repair(8).
And with xfs_repair,
linux@linux:~> sudo xfs_repair /dev/sda2
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
ERROR: The filesystem has valuable metadata changes in a log which needs to
be replayed. Mount the filesystem to replay the log, and unmount it before
re-running xfs_repair. If you are unable to mount the filesystem, then use
the -L option to destroy the log and attempt a repair.
Note that destroying the log may cause corruption -- please attempt a mount
of the filesystem before doing this.
> Code:
> --------------------
> linux@linux:~> sudo xfs_repair /dev/sda2
> Phase 1 - find and verify superblock…
> Phase 2 - using internal log
> - zero log…
> ERROR: The filesystem has valuable metadata changes in a log which needs to
> be replayed. Mount the filesystem to replay the log, and unmount it before
> re-running xfs_repair. If you are unable to mount the filesystem, then use
> the -L option to destroy the log and attempt a repair.
> Note that destroying the log may cause corruption – please attempt a mount
> of the filesystem before doing this.
> --------------------
>
>
> There’s something I’m doing wrong, right?
Well, the message is telling you exactly what you have to do
I do not think you are doing anything wrong. Please take into account that I do not use XFS. Until recently, fsck was a wrapper around fsck funcrionality for all sorts of file systems. Normaly it was able to find out which file system it was and then called the appropriate tool.
In this case, fsck does see it is XFS but does not call the tool itself. Instead it advices you to do so. Which you did.
It outputs a whole story, where one thing is clear: there is a problem on that file system (as you feared for already).
It advices you to mount the file system and try to replay the log. As you already showed that you can not mount it, this path is blocked.
Next option is then to use the -L option as adviced. IMHO the only chance you have to repair things (but you may want to wait for a guru here that knows better ;)).
When using the -L does not help, I assume that, apart from forensic techniques, the creation of a new file system and restore from your backups is the only thing left.
linux@linux:~> sudo xfs_repair -L /dev/sda2
Phase 1 - find and verify superblock...
Phase 2 - using internal log
- zero log...
ALERT: The filesystem has valuable metadata changes in a log which is being
destroyed because the -L option was used.
- scan filesystem freespace and inode maps...
agf_freeblks 15656617, counted 15654918 in ag 3
agi_freecount 41, counted 63 in ag 2
ir_freecount/free mismatch, inode chunk 3/46400, freecount 3 nfree 1
agi_count 17088, counted 17152 in ag 3
agi_freecount 26, counted 69 in ag 3
block (1,9447579-9447579) multiply claimed by cnt space tree, state - 2
sb_icount 116096, counted 116736
sb_ifree 337, counted 373
sb_fdblocks 55607240, counted 55508896
- found root inode chunk
Phase 3 - for each AG...
- scan and clear agi unlinked lists...
- process known inodes and perform inode discovery...
- agno = 0
- agno = 1
data fork in ino 344014734 claims free block 43002003
- agno = 2
- agno = 3
data fork in ino 805352341 claims free block 100672897
data fork in ino 805352344 claims free block 100669161
correcting imap
imap claims a free inode 805352349 is in use, correcting imap and clearing inode
cleared inode 805352349
correcting imap
data fork in ino 805383444 claims free block 100672927
data fork in ino 805383773 claims free block 100672926
data fork in ino 805383775 claims free block 100672611
data fork in ino 805383789 claims free block 100672612
data fork in ino 808658647 claims free block 101082336
data fork in ino 809076754 claims free block 101134596
data fork in ino 809076756 claims free block 101134305
- process newly discovered inodes...
Phase 4 - check for duplicate blocks...
- setting up duplicate extent list...
- check for inodes claiming duplicate blocks...
- agno = 0
- agno = 1
- agno = 2
- agno = 3
entry "revocations.txt" at block 0 offset 2416 in directory inode 805306464 references free inode 805352349
clearing inode number in entry at offset 2416...
entry "recovery.js" in shortform directory 537308102 references free inode 555635773
junking entry "recovery.js" in directory inode 537308102
Phase 5 - rebuild AG headers and trees...
- reset superblock...
Phase 6 - check inode connectivity...
- resetting contents of realtime bitmap and summary inodes
- traversing filesystem ...
bad hash table for directory inode 805306464 (no data entry): rebuilding
rebuilding directory inode 805306464
- traversal finished ...
- moving disconnected inodes to lost+found ...
Phase 7 - verify and correct link counts...
Metadata corruption detected at block 0x27e8db98/0x1000
libxfs_writebufr: write verifer failed on bno 0x27e8db98/0x1000
Metadata corruption detected at block 0x27e8db98/0x1000
libxfs_writebufr: write verifer failed on bno 0x27e8db98/0x1000
done
So I guess that “metadata corruption detected” means there is no chance to recover it.
It’s a pain, but I can live losing the data in that partition (/home), but I’d like to be able to boot without a reinstall because I’m relying on a very slow wifi connection. If I format the partiton with Yast partition manager, will it boot normally? Or do I need to do something else?
> It advices you to mount the file system and try to replay the log. As
> you already showed that you can not mount it, this path is blocked.
No, it is not. You (he, that is) have to try again.
And better make sure that the rescue system is at least of the same
release as the installed system.
> Next option is then to use the -L option as adviced. IMHO the only
> chance you have to repair things (but you may want to wait for a guru
> here that knows better ;)).
>
> When using the -L does not help, I assume that, apart from forensic
> techniques, the creation of a new file system and restore from your
> backups is the only thing left.
It is quite rare that an xfs repair fails completely. And in that case,
the folks (devs included) at the XFS mail list are quite helpful
>
> So I guess that “metadata corruption detected” means there is no chance
> to recover it.
Maybe not.
Run another xfs repair without options, see what it says.
Then try to mount.
I would also run a S.M.A.R.T. long check with smartctl.
> It’s a pain, but I can live losing the data in that partition (/home),
> but I’d like to be able to boot without a reinstall because I’m relying
> on a very slow wifi connection. If I format the partiton with Yast
> partition manager, will it boot normally? Or do I need to do something
> else?
You can boot if you comment out the “/home” line in the fstab file. Then
you will have to login as root…
While the XFS system is used as your /home, you can of course boot without it. Use an editor from the rescue system to edit /etc/fstab. Put a # sign before the entry.
When you boot that system, you can of course not loginb as the normal user. Use Ctrl-Alt-F1 to get the console and login as root. Call yast in it’s ncurrses version and create the new file system on the partiition.
But, did you try to mount it after your repair trial?
Fine, but because of the messages, there is a chance that not all and everything is OK. The logic of the file system is now repaired, but there maybe files lost (or even files restored that were deleted). Thus, when you are able to check against e.g. a backup if all files are present and e.g. are of the same size (and where you can confirm to yourself that differences might be allright sice the time you made the backup), that would be recommendable.
Also, I do not know if XFS sports a lost+found directory, but, when yes, inspecting it might not be a bad idea.
