Arch Linux

DKMM

Member

Registered: 2015-01-21

Posts: 1

Unable to mount btrfs root (dev/sda2) - saying it's out of memory

Hi there.

I updated my laptop today (might've have had a new kernel upgrade?) and went on without rebooting. When I then went to shut it down, it locked (hard-locked, no input what so ever), so I shut down the laptop by holding the button down 5 seconds.

When booting up again, the system immediately went into emergency mode, with the following message:

:: mounting '/dev/sda2' on real root
BTRFS: error (device sda2) in btrfs_recover_log_trees:4429: errno=-12 Out of memory (Couldnt read tree log root.)
BTRFS: error (device sda2) in open_ctree:2886: errno=-12 Out of memory (Failed to recover log tree)
BTRFS: open_ctree failed
mount: wrong fs type, bad option, bad superblock on /dev/sda2
           missing codepage or helper program, or other error

...

And I am now stuck in emergency mode. I am unable to mount root manually using -o recover, so I'm having quite some trouble.

Any ideas?

EDIT: I am able to mount my /home partition (/dev/sda3) just fine.

Last edited by DKMM (2015-01-21 16:56:21)

martinc2

Member

Registered: 2011-09-23

Posts: 60

Re: Unable to mount btrfs root (dev/sda2) - saying it's out of memory

Not a diagnosis, but a suggestion:  Boot into a rescue CD with an up-to-date btrfs (I found Exton/D worked for me), and run "btrfs check" on /dev/sda2.  This should give you some further info, and you might (emphasis on "might", don't shoot me, other people may give better advice, etc.) be able to fix it using "btrfs check --repair".

Last edited by martinc2 (2015-01-22 13:47:06)

WonderWoofy

Member

From: Los Gatos, CA

Registered: 2012-05-19

Posts: 8,414

Re: Unable to mount btrfs root (dev/sda2) - saying it's out of memory

I *think* this sounds like a case which will require you to use btrfs-zero-log.  But I am not 100% sure on that.  As with anything btrfs, it is probably best to ask on #btrfs (freenode) or the linux-btrfs mailing list.

A while back, someone asked what the 'proper' recovery method would be for btrfs (at the time).  Hugo Mills responded with:

   Let's assume that you don't have a physical device failure (which
is a different set of tools -- mount -odegraded, btrfs dev del
missing).

   First thing to do is to take a btrfs-image -c9 -t4 of the
filesystem, and keep a copy of the output to show josef.

   Then start with -orecovery and -oro,recovery for pretty much
anything.

   If those fail, then look in dmesg for errors relating to the log
tree -- if that's corrupt and can't be read (or causes a crash), use
btrfs-zero-log.

   If there's problems with the chunk tree -- the only one I've seen
recently was reporting something like "can't map address" -- then
chunk-recover may be of use.

   After that, btrfsck is probably the next thing to try. If options
-s1, -s2, -s3 have any success, then btrfs-select-super will help by
replacing the superblock with one that works. If that's not going to
be useful, fall back to btrfsck --repair.

   Finally, btrfsck --repair --init-extent-tree may be necessary if
there's a damaged extent tree. Finally, if you've got corruption in
the checksums, there's --init-csum-tree.

   Hugo.

Syncopated

Member

Registered: 2015-02-07

Posts: 14

Re: Unable to mount btrfs root (dev/sda2) - saying it's out of memory

I *think* this sounds like a case which will require you to use btrfs-zero-log.  But I am not 100% sure on that.  As with anything btrfs, it is probably best to ask on #btrfs (freenode) or the linux-btrfs mailing list.

I had a similar problem yesterday with my BTRFS partition after I did a hard reset when my computer froze. I got the "BTRFS: open_ctree failed" and something about the log tree/root, but not the part about memory. At first, btrfs-zero-log did nothing because it encountered some errors it didn't know how to handle, but it worked after I switched to a more recent version of btrfs-zero-log. (First attempt was using Fedora 21 live system, and second attempt was using updated Fedora 21.)

Last edited by Syncopated (2015-02-28 13:10:27)