If you are going to use btrfs-zero-log please create a btrfs-image first that you can then upload to a bug report so that this can be fixed. # btrfs-image -c 9 -t 8 /dev/yourbtrfs /tmp/fs_image On Mon, Mar 11, 2013 at 11:53 PM, Jan Steffens <jan.steffens@xxxxxxxxx> wrote: > On Mon, Mar 11, 2013 at 11:49 PM, Harald Glatt <mail@xxxxxxxxx> wrote: >> On Mon, Mar 11, 2013 at 11:44 PM, Matthew Booth <matthew@xxxxxxxxxxxxx> wrote: >>> My laptop crashed hard earlier today. It reset immediately to a black >>> screen followed by the BIOS. I have no idea why. >>> >>> However, it now fails to boot. I took a picture of the kernel panic >>> that results from trying to mount the root filesystem: >>> https://plus.google.com/107763699965053810188/posts/QZZt7GYzBZi >>> >>> To make things worse, btrfsck aborts with a double free, without >>> fixing it. I took a picture of that, too: >>> https://plus.google.com/107763699965053810188/posts/gKYqGgFhWyT >>> >>> As the kernel panic mentions btrfs_remove_free_space, I also tried >>> mounting with clear_cache. Unfortunately it didn't dislodge anything. >>> >>> This is on a fully updated Fedora 18 system. I would really like to >>> get this data back. If anybody could offer a suggestion I'd be very >>> grateful. >> If you can make a complete image backup of the drive before trying any >> things to bring it back. >> Try mounting with -o nospace_cache, also try -o ro and -o recovery as >> well as -o recovery,ro. > > I think the bug happens during log recovery, so btrfs-zero-log might > get it mountable again, with the caveat of losing the most recently > fsynced changes. > -- > To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
