] BTRFS error (device dm-0): cleaner transaction
attach returned -30
[ 2301.035405] BTRFS: open_ctree failed
It is exactly the same error I saw when trying to boot normally as
mentioned above.
Based on these two links:
> https://btrfs.wiki.kernel.org/index.php/Problem_FAQ
>
on 59394068480 wanted
84587 found 84589
[179649.291776] Failed to read block groups: -5
[179649.312476] btrfs: open_ctree failed
On Ubuntu 13.04, btrfsck would assert with the following error:
btrfsck: disk-io.c:441: find_and_setup_root: Assertion `!(ret)' failed.
I have backup the disk partition
On Sun, Sep 16, 2012 at 03:24:53PM +0200, Sébastien Kalt wrote:
I'm running Debian Sid, 3.2.0-3-amd64 kernel and Btrfs v0.19
(0.19+20120328-8 according to dpkg), using XFCE4 and dolphin as a file
manager. The usb drive is auto-mounting, and I'm accessing it with
dolphin or console. I always
One entire subvolume was restored. But there were 4 subvolumes on that
partition. Is there a way to specify/force the restore of a different
subvolume ?
find-root seems to only find a single root.
thanks
On Mon, Mar 26, 2012 at 3:47 PM, Hugo Mills h...@carfax.org.uk wrote:
On Mon, Mar 26, 2012
On Tue, Mar 27, 2012 at 05:58:17AM -0700, Not Zippy wrote:
One entire subvolume was restored. But there were 4 subvolumes on that
partition. Is there a way to specify/force the restore of a different
subvolume ?
find-root seems to only find a single root.
There is only a single root
I had found that note on the restore but my restore.c does not allow
that flag (it is also missing the m flag as well), I used the branch
dangerousdonteveruse on
https://git.kernel.org/?p=linux/kernel/git/mason/btrfs-progs.git I
switched to the master branch to see if there was a difference but it
Thought I would let you know I did get things figured out. I used
btrfs-progs from github
https://github.com/josefbacik/btrfs-progs
I also used the findroot function from there which generated more
possibilities for the root objectid.
By pluging in the guesses from findroot into -r objectid for
failed on 498530500608 wanted
26696 found 27535
[ 1518.660243] btrfs: open_ctree failed
Tried btrfsck after a lot of messages got:
...
leaf parent key incorrect 563096514560
Unable to find block group for 0
btrfsck: extent-tree.c:284: find_search_start: Assertion `!(1)' failed.
My kernel 3.0.0-16
on 498530500608 wanted
26696 found 27535
[ 1518.640279] parent transid verify failed on 498530500608 wanted
26696 found 27535
[ 1518.660243] btrfs: open_ctree failed
Tried btrfsck after a lot of messages got:
...
leaf parent key incorrect 563096514560
Unable to find block group for 0
btrfsck: extent
Hugo
I did try the dangerdonteveruse branch and thats the error btrfsck
--repair gave me. Looks like the btrfs-restore command may work
(thanks!). And yes I do have backups for the important data - I had
some other data on there which would need to be d/l again..
I don't dabble that much with the
On Mon, Mar 26, 2012 at 03:36:13PM -0700, Not Zippy wrote:
Hugo
I did try the dangerdonteveruse branch and thats the error btrfsck
--repair gave me.
Oooh, a brave one, I see. ;)
Looks like the btrfs-restore command may work (thanks!). And yes I
do have backups for the important data - I
On 27/03/12 09:47, Hugo Mills wrote:
I'd definitely recommend running as recent a kernel as you can --
either the last released (3.3 in this case)
I'm not sure I'd recommend 3.3; there were a number of reports of a
regression regarding preamture ENOSPC in that code which was bisected to
a
33999 found
36704
[ 187.015094] parent transid verify failed on 79466496 wanted 33999 found
36704
[ 187.015764] btrfs: open_ctree failed
uname now reports:
Linux veriton 3.3.0-030300rc4-generic-pae #201202181935 SMP Sun Feb 19
00:53:06 UTC 2012 i686 i686 i386 GNU/Linux
I'm not sure
Hi Curtis,
On Sunday 19 February 2012 13:47:35 Curtis Jones wrote:
I don't want to push this too far in the direction of being an
Ubuntu support thread; but do you happen to know of any convenient
methods for installing a 3.2.x kernel on Ubuntu? I'd like to
minimize the chance of screwing up
Subject: Re: btrfs open_ctree failed (after recent Ubuntu update)
On Sunday 19 February 2012 07:34:22 Curtis Jones wrote:
Any help would be appreciated. Thank you. Please CC me on any
replies.
Linux veriton 3.0.0-16-generic-pae #28-Ubuntu SMP Fri Jan 27
19:24:01 UTC 2012 i686 i686 i386
Thanks, Hugo. I'll check this out. -John
- Original Message -
From: Hugo Mills h...@carfax.org.uk
To: jlcen...@comcast.net
Cc: linux-btrfs@vger.kernel.org
Sent: Sunday, February 19, 2012 2:26:05 PM
Subject: Re: btrfs open_ctree failed (after recent Ubuntu update)
On Sun, Feb 19, 2012
found
36704
[ 187.015764] btrfs: open_ctree failed
uname now reports:
Linux veriton 3.3.0-030300rc4-generic-pae #201202181935 SMP Sun Feb 19
00:53:06 UTC 2012 i686 i686 i386 GNU/Linux
I'm not sure what to try next; or even how to get more diagnostic information.
Please let me know what
found
36704
[ 187.015094] parent transid verify failed on 79466496 wanted 33999 found
36704
[ 187.015764] btrfs: open_ctree failed
uname now reports:
Linux veriton 3.3.0-030300rc4-generic-pae #201202181935 SMP Sun Feb 19
00:53:06 UTC 2012 i686 i686 i386 GNU/Linux
I'm not sure what
I recently let the Update Manager run after ignoring it for a couple of weeks.
It required a reboot. My USB btrfs volume didn't mount after reboot. dmesg
revealed:
[ 463.187097] btrfs: open_ctree failed
[ 991.567090] device label StoreW devid 1 transid 37077 /dev/sdb
[ 1003.171989] device label
On Sunday 19 February 2012 07:34:22 Curtis Jones wrote:
Any help would be appreciated. Thank you. Please CC me on any
replies.
Linux veriton 3.0.0-16-generic-pae #28-Ubuntu SMP Fri Jan 27
19:24:01 UTC 2012 i686 i686 i386 GNU/Linux
That's a fairly old kernel in btrfs terms, you may want to
] Failed to read block groups: -5
[57231.704165] btrfs: open_ctree failed
Can you tell us more about this filesystem? Was there an unclean
shutdown or did you just unmount, mount again?
The confusing thing is that all of your disks seem to have the same copy
of the block, so it looks like things
[57231.680861] parent transid verify failed on 424308420608 wanted 6970
found 8959
[57231.680869] parent transid verify failed on 424308420608 wanted 6970
found 8959
[57231.680875] Failed to read block groups: -5
[57231.704165] btrfs: open_ctree failed
root@xxx:~#
root@xxx:~# btrfs filesystem show
groups: -5
[57231.704165] btrfs: open_ctree failed
Can you tell us more about this filesystem? Was there an unclean
shutdown or did you just unmount, mount again?
The confusing thing is that all of your disks seem to have the same copy
of the block, so it looks like things were written properly
Looks like it, cross posting to linux-btrfs.
-Sam
On Mon, Dec 12, 2011 at 7:20 PM, Matt Weil mw...@genome.wustl.edu wrote:
another butter bug?
btrfs: open_ctree failed
[ cut here ]
WARNING: at fs/btrfs/inode.c:2194 btrfs_orphan_commit_root+0xb0/0xc0
[btrfs
] parent transid verify failed on 3807195136 wanted 5412 found 5414
[ 3821.979182] btrfs: open_ctree failed
[ 6298.660270] device label root devid 1 transid 12174 /dev/mapper/nas-root
[ 6298.660657] btrfs: use lzo compression
[ 6298.662878] parent transid verify failed on 3807195136 wanted 5412 found
-79bc6a4401b60fa9 devid 1 transid 433 /dev/sdc2
btrfs: open_ctree failed
# btrfsck /dev/sdc2
found 21851738112 bytes used err is 0
total csum bytes: 21297140
total tree bytes: 43466752
total fs tree bytes: 17068032
btree space waste bytes: 7526756
file data blocks allocated: 21808271360
/loop0
[140443.202369] BTRFS: couldn't mount because of unsupported optional features
(1).
[140443.202480] btrfs: open_ctree failed
Did I miss something? Using ext3/4 the above works flawlessly..
Probably it's only due to the open_ctree problem above. Using kernel 2.6.30
and btrfs-tools 19-2 (debian
] device label BTRFS_mypole devid 1 transid 7 /dev/loop0
[140443.202369] BTRFS: couldn't mount because of unsupported optional
features (1).
[140443.202480] btrfs: open_ctree failed
Did I miss something? Using ext3/4 the above works flawlessly..
Probably it's only due to the open_ctree
Hey Zheng,
Thanks for your message.
Thought I read some note somewhere that this change had been taken place in
2.6.30 and was using .19 w/o thinking about trying the .18.
Had a look at the module sources but maybe missed some version indication. Is
there a var/macro telling the btrfs source
29 matches
Mail list logo
