Unable to boot

Unable to boot

[George Pochiscan]

Hello,

I have a problem with a server with Fedora 20 and BTRFS. This server had frequent hard restarts before the filesystem got corrupt and we are unable to boot it.

We have a HP Proliant server with 4 disks @1TB each and Software RAID 5.
It had Debian installed (i don't know the version) and right now i'm using fedora 20 live to try to rescue the  system.

When we try btrfsck /dev/md127 i have a lot of checksum errors, and the output is: 

Checking filesystem on /dev/md127
UUID: e068faf0-2c16-4566-9093-e6d1e21a5e3c
checking extents
checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
Csum didn't match
checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
Csum didn't match
-----------------------------------------------------------------

extent buffer leak: start 1006686208 len 4096
found 32039247396 bytes used err is -22
total csum bytes: 41608612
total tree bytes: 388857856
total fs tree bytes: 310124544
total extent tree bytes: 22016000
btree space waste bytes: 126431234
file data blocks allocated: 47227326464
 referenced 42595635200
Btrfs v3.12



When i attempt to repair i have the following error:
-----------------------------------------
Backref 1005817856 parent 5 root 5 not found in extent tree
backpointer mismatch on [1005817856 4096]
owner ref check failed [1006686208 4096]
repaired damaged extent references
Failed to find [1000525824, 168, 4096]
btrfs unable to find ref byte nr 1000525824 parent 0 root 1  owner 1 offset 0
btrfsck: extent-tree.c:1752: write_one_cache_group: Assertion `!(ret)' failed.
Aborted
------------------------------------




I have installed btrfs version 3.12

Linux localhost 3.11.10-301.fc20.x86_64 #1 SMP Thu Dec 5 14:01:17 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[root@localhost liveuser]# btrfs fi show
Label: none  uuid: e068faf0-2c16-4566-9093-e6d1e21a5e3c
	Total devices 1 FS bytes used 40.04GiB
	devid    1 size 1.82TiB used 43.04GiB path /dev/md127
Btrfs v3.12


Please advice.

Thank you,
George Pochiscan

Re: Unable to boot

[Chris Murphy]

On May 2, 2014, at 4:00 AM, George Pochiscan <george.pochiscan@sphs.ro> wrote:

> Hello,
> 
> I have a problem with a server with Fedora 20 and BTRFS. This server had frequent hard restarts before the filesystem got corrupt and we are unable to boot it.
> 
> We have a HP Proliant server with 4 disks @1TB each and Software RAID 5.
> It had Debian installed (i don't know the version) and right now i'm using fedora 20 live to try to rescue the  system.

Fedora 20 Live has kernel 3.11.10 and btrfs-progs 0.20.rc1.20131114git9f0c53f-1.fc20. So the general rule of thumb without knowing exactly what the problem and solution is, is to try a much newer kernel and btrfs-progs, like a Fedora Rawhide live media. These are built daily, but don't always succeed so you can go here to find the latest of everything:

https://apps.fedoraproject.org/releng-dash/

Find Fedora Live Desktop or Live KDE and click on details. Click the green link under descendants   livecd. And then under Output listing you'll see an ISO you can download, the one there right now is Fedora-Live-Desktop-x86_64-rawhide-20140502.iso - but of course this changes daily.

You might want to boot with kernel parameter slub_debug=- (that's a minus symbol) because all but Monday built Rawhide kernels have a bunch of kernel debug options enabled which makes it quite slow.


> 
> When we try btrfsck /dev/md127 i have a lot of checksum errors, and the output is: 
> 
> Checking filesystem on /dev/md127
> UUID: e068faf0-2c16-4566-9093-e6d1e21a5e3c
> checking extents
> checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> Csum didn't match
> checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> Csum didn't match
> -----------------------------------------------------------------
> 
> extent buffer leak: start 1006686208 len 4096
> found 32039247396 bytes used err is -22
> total csum bytes: 41608612
> total tree bytes: 388857856
> total fs tree bytes: 310124544
> total extent tree bytes: 22016000
> btree space waste bytes: 126431234
> file data blocks allocated: 47227326464
> referenced 42595635200
> Btrfs v3.12


I suggest a recent Rawhide build. And I suggest just trying to mount the file system normally first, and post anything that appears in dmesg. And if the mount fails, then try mount option -o recovery, and also post any dmesg messages from that too, and note whether or not it mounts. Finally if that doesn't work either then see if -o ro,recovery works and what kernel messages you get.


> 
> 
> 
> When i attempt to repair i have the following error:
> -----------------------------------------
> Backref 1005817856 parent 5 root 5 not found in extent tree
> backpointer mismatch on [1005817856 4096]
> owner ref check failed [1006686208 4096]
> repaired damaged extent references
> Failed to find [1000525824, 168, 4096]
> btrfs unable to find ref byte nr 1000525824 parent 0 root 1  owner 1 offset 0
> btrfsck: extent-tree.c:1752: write_one_cache_group: Assertion `!(ret)' failed.
> Aborted
> ------------------------------------

You really shouldn't use --repair right off the bat, it's not a recommended early step, you should try normal mounting with newer kernels first, then recovery mount options first. Sometimes the repair option makes things worse. I'm not sure what its safety status is as of v3.14.

https://btrfs.wiki.kernel.org/index.php/Problem_FAQ

Fedora includes btrfs-zero-log already so depending on the kernel messages you might try that before a btrfsck --repair.



Chris Murphy

RE: Unable to boot

[George Pochiscan]

Hello Chris,

Thanks for your response. I tried the steps you gave me, but still no luck.

Each time i try to mount ( normally, -o recovery, -o ro,recovery) i have the following error:

[root@localhost liveuser]# mount /dev/md127 /tmp/hdd
mount: wrong fs type, bad option, bad superblock on /dev/md127,
       missing codepage or helper program, or other error

       In some cases useful info is found in syslog - try
       dmesg | tail or so.

For the simple  mount command the dmesg is : http://pastebin.com/TiPR7U2j
For mount -o recovery option, the dmesg is : http://pastebin.com/NURDTeYf
For mount -o ro,recovery options, the dmesg is : http://pastebin.com/UUmdWGgE


Thank you,
George Pochiscan
Support Engineer

Mobile: +40731831489
Phone: +40213225757
Fax: +40213222522
george.pochiscan@sphs.ro
www.spearheadsystems.ro
64 I.P. Pavlov Street, 1st District
Bucharest, Romania

IT innovation at its finest.

________________________________________
From: Chris Murphy <lists@colorremedies.com>
Sent: Friday, May 2, 2014 22:41
To: George Pochiscan
Cc: linux-btrfs@vger.kernel.org
Subject: Re: Unable to boot

On May 2, 2014, at 4:00 AM, George Pochiscan <george.pochiscan@sphs.ro> wrote:

> Hello,
>
> I have a problem with a server with Fedora 20 and BTRFS. This server had frequent hard restarts before the filesystem got corrupt and we are unable to boot it.
>
> We have a HP Proliant server with 4 disks @1TB each and Software RAID 5.
> It had Debian installed (i don't know the version) and right now i'm using fedora 20 live to try to rescue the  system.

Fedora 20 Live has kernel 3.11.10 and btrfs-progs 0.20.rc1.20131114git9f0c53f-1.fc20. So the general rule of thumb without knowing exactly what the problem and solution is, is to try a much newer kernel and btrfs-progs, like a Fedora Rawhide live media. These are built daily, but don't always succeed so you can go here to find the latest of everything:

https://apps.fedoraproject.org/releng-dash/

Find Fedora Live Desktop or Live KDE and click on details. Click the green link under descendants   livecd. And then under Output listing you'll see an ISO you can download, the one there right now is Fedora-Live-Desktop-x86_64-rawhide-20140502.iso - but of course this changes daily.

You might want to boot with kernel parameter slub_debug=- (that's a minus symbol) because all but Monday built Rawhide kernels have a bunch of kernel debug options enabled which makes it quite slow.


>
> When we try btrfsck /dev/md127 i have a lot of checksum errors, and the output is:
>
> Checking filesystem on /dev/md127
> UUID: e068faf0-2c16-4566-9093-e6d1e21a5e3c
> checking extents
> checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> Csum didn't match
> checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> Csum didn't match
> -----------------------------------------------------------------
>
> extent buffer leak: start 1006686208 len 4096
> found 32039247396 bytes used err is -22
> total csum bytes: 41608612
> total tree bytes: 388857856
> total fs tree bytes: 310124544
> total extent tree bytes: 22016000
> btree space waste bytes: 126431234
> file data blocks allocated: 47227326464
> referenced 42595635200
> Btrfs v3.12


I suggest a recent Rawhide build. And I suggest just trying to mount the file system normally first, and post anything that appears in dmesg. And if the mount fails, then try mount option -o recovery, and also post any dmesg messages from that too, and note whether or not it mounts. Finally if that doesn't work either then see if -o ro,recovery works and what kernel messages you get.


>
>
>
> When i attempt to repair i have the following error:
> -----------------------------------------
> Backref 1005817856 parent 5 root 5 not found in extent tree
> backpointer mismatch on [1005817856 4096]
> owner ref check failed [1006686208 4096]
> repaired damaged extent references
> Failed to find [1000525824, 168, 4096]
> btrfs unable to find ref byte nr 1000525824 parent 0 root 1  owner 1 offset 0
> btrfsck: extent-tree.c:1752: write_one_cache_group: Assertion `!(ret)' failed.
> Aborted
> ------------------------------------

You really shouldn't use --repair right off the bat, it's not a recommended early step, you should try normal mounting with newer kernels first, then recovery mount options first. Sometimes the repair option makes things worse. I'm not sure what its safety status is as of v3.14.

https://btrfs.wiki.kernel.org/index.php/Problem_FAQ

Fedora includes btrfs-zero-log already so depending on the kernel messages you might try that before a btrfsck --repair.



Chris Murphy

Re: Unable to boot

[Hugo Mills]

[-- Attachment #1: Type: text/plain, Size: 5681 bytes --]

On Mon, May 05, 2014 at 03:04:05PM +0000, George Pochiscan wrote:
> Hello Chris,
> 
> Thanks for your response. I tried the steps you gave me, but still no luck.
> 
> Each time i try to mount ( normally, -o recovery, -o ro,recovery) i have the following error:
> 
> [root@localhost liveuser]# mount /dev/md127 /tmp/hdd
> mount: wrong fs type, bad option, bad superblock on /dev/md127,
>        missing codepage or helper program, or other error
> 
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so.
> 
> For the simple  mount command the dmesg is : http://pastebin.com/TiPR7U2j
> For mount -o recovery option, the dmesg is : http://pastebin.com/NURDTeYf
> For mount -o ro,recovery options, the dmesg is : http://pastebin.com/UUmdWGgE

   This looks like btrfs-zero-log may help you, as it's having trouble
recovering the log tree.

   Hugo.

> Thank you,
> George Pochiscan
> Support Engineer
> 
> Mobile: +40731831489
> Phone: +40213225757
> Fax: +40213222522
> george.pochiscan@sphs.ro
> www.spearheadsystems.ro
> 64 I.P. Pavlov Street, 1st District
> Bucharest, Romania
> 
> IT innovation at its finest.
> 
> ________________________________________
> From: Chris Murphy <lists@colorremedies.com>
> Sent: Friday, May 2, 2014 22:41
> To: George Pochiscan
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: Unable to boot
> 
> On May 2, 2014, at 4:00 AM, George Pochiscan <george.pochiscan@sphs.ro> wrote:
> 
> > Hello,
> >
> > I have a problem with a server with Fedora 20 and BTRFS. This server had frequent hard restarts before the filesystem got corrupt and we are unable to boot it.
> >
> > We have a HP Proliant server with 4 disks @1TB each and Software RAID 5.
> > It had Debian installed (i don't know the version) and right now i'm using fedora 20 live to try to rescue the  system.
> 
> Fedora 20 Live has kernel 3.11.10 and btrfs-progs 0.20.rc1.20131114git9f0c53f-1.fc20. So the general rule of thumb without knowing exactly what the problem and solution is, is to try a much newer kernel and btrfs-progs, like a Fedora Rawhide live media. These are built daily, but don't always succeed so you can go here to find the latest of everything:
> 
> https://apps.fedoraproject.org/releng-dash/
> 
> Find Fedora Live Desktop or Live KDE and click on details. Click the green link under descendants   livecd. And then under Output listing you'll see an ISO you can download, the one there right now is Fedora-Live-Desktop-x86_64-rawhide-20140502.iso - but of course this changes daily.
> 
> You might want to boot with kernel parameter slub_debug=- (that's a minus symbol) because all but Monday built Rawhide kernels have a bunch of kernel debug options enabled which makes it quite slow.
> 
> 
> >
> > When we try btrfsck /dev/md127 i have a lot of checksum errors, and the output is:
> >
> > Checking filesystem on /dev/md127
> > UUID: e068faf0-2c16-4566-9093-e6d1e21a5e3c
> > checking extents
> > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> > Csum didn't match
> > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> > Csum didn't match
> > -----------------------------------------------------------------
> >
> > extent buffer leak: start 1006686208 len 4096
> > found 32039247396 bytes used err is -22
> > total csum bytes: 41608612
> > total tree bytes: 388857856
> > total fs tree bytes: 310124544
> > total extent tree bytes: 22016000
> > btree space waste bytes: 126431234
> > file data blocks allocated: 47227326464
> > referenced 42595635200
> > Btrfs v3.12
> 
> 
> I suggest a recent Rawhide build. And I suggest just trying to mount the file system normally first, and post anything that appears in dmesg. And if the mount fails, then try mount option -o recovery, and also post any dmesg messages from that too, and note whether or not it mounts. Finally if that doesn't work either then see if -o ro,recovery works and what kernel messages you get.
> 
> 
> >
> >
> >
> > When i attempt to repair i have the following error:
> > -----------------------------------------
> > Backref 1005817856 parent 5 root 5 not found in extent tree
> > backpointer mismatch on [1005817856 4096]
> > owner ref check failed [1006686208 4096]
> > repaired damaged extent references
> > Failed to find [1000525824, 168, 4096]
> > btrfs unable to find ref byte nr 1000525824 parent 0 root 1  owner 1 offset 0
> > btrfsck: extent-tree.c:1752: write_one_cache_group: Assertion `!(ret)' failed.
> > Aborted
> > ------------------------------------
> 
> You really shouldn't use --repair right off the bat, it's not a recommended early step, you should try normal mounting with newer kernels first, then recovery mount options first. Sometimes the repair option makes things worse. I'm not sure what its safety status is as of v3.14.
> 
> https://btrfs.wiki.kernel.org/index.php/Problem_FAQ
> 
> Fedora includes btrfs-zero-log already so depending on the kernel messages you might try that before a btrfsck --repair.
> 
> 
> 
> Chris Murphy
> 

-- 
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
       --- It's against my programming to impersonate a deity! ---       

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 811 bytes --]

RE: Unable to boot

[George Pochiscan]

Hello Hugo,

Running btrfs-zero-log /dev/md127 i have the following error:

checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
Csum didn't match
btrfs-zero-log: extent-tree.c:2717: alloc_reserved_tree_block: Assertion `!(ret)' failed.
Aborted (core dumped)

Full output : http://pastebin.com/3h5zVuWg
Full dmesg : http://pastebin.com/r9Fk8J8F

Thank you,

George Pochiscan
Support Engineer

Mobile: +40731831489
Phone: +40213225757
Fax: +40213222522
george.pochiscan@sphs.ro
www.spearheadsystems.ro
64 I.P. Pavlov Street, 1st District
Bucharest, Romania

IT innovation at its finest.

________________________________________
From: Hugo Mills <hugo@carfax.org.uk>
Sent: Monday, May 5, 2014 18:07
To: George Pochiscan
Cc: Chris Murphy; linux-btrfs@vger.kernel.org
Subject: Re: Unable to boot

On Mon, May 05, 2014 at 03:04:05PM +0000, George Pochiscan wrote:
> Hello Chris,
>
> Thanks for your response. I tried the steps you gave me, but still no luck.
>
> Each time i try to mount ( normally, -o recovery, -o ro,recovery) i have the following error:
>
> [root@localhost liveuser]# mount /dev/md127 /tmp/hdd
> mount: wrong fs type, bad option, bad superblock on /dev/md127,
>        missing codepage or helper program, or other error
>
>        In some cases useful info is found in syslog - try
>        dmesg | tail or so.
>
> For the simple  mount command the dmesg is : http://pastebin.com/TiPR7U2j
> For mount -o recovery option, the dmesg is : http://pastebin.com/NURDTeYf
> For mount -o ro,recovery options, the dmesg is : http://pastebin.com/UUmdWGgE

   This looks like btrfs-zero-log may help you, as it's having trouble
recovering the log tree.

   Hugo.

> Thank you,
> George Pochiscan
> Support Engineer
>
> Mobile: +40731831489
> Phone: +40213225757
> Fax: +40213222522
> george.pochiscan@sphs.ro
> www.spearheadsystems.ro
> 64 I.P. Pavlov Street, 1st District
> Bucharest, Romania
>
> IT innovation at its finest.
>
> ________________________________________
> From: Chris Murphy <lists@colorremedies.com>
> Sent: Friday, May 2, 2014 22:41
> To: George Pochiscan
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: Unable to boot
>
> On May 2, 2014, at 4:00 AM, George Pochiscan <george.pochiscan@sphs.ro> wrote:
>
> > Hello,
> >
> > I have a problem with a server with Fedora 20 and BTRFS. This server had frequent hard restarts before the filesystem got corrupt and we are unable to boot it.
> >
> > We have a HP Proliant server with 4 disks @1TB each and Software RAID 5.
> > It had Debian installed (i don't know the version) and right now i'm using fedora 20 live to try to rescue the  system.
>
> Fedora 20 Live has kernel 3.11.10 and btrfs-progs 0.20.rc1.20131114git9f0c53f-1.fc20. So the general rule of thumb without knowing exactly what the problem and solution is, is to try a much newer kernel and btrfs-progs, like a Fedora Rawhide live media. These are built daily, but don't always succeed so you can go here to find the latest of everything:
>
> https://apps.fedoraproject.org/releng-dash/
>
> Find Fedora Live Desktop or Live KDE and click on details. Click the green link under descendants   livecd. And then under Output listing you'll see an ISO you can download, the one there right now is Fedora-Live-Desktop-x86_64-rawhide-20140502.iso - but of course this changes daily.
>
> You might want to boot with kernel parameter slub_debug=- (that's a minus symbol) because all but Monday built Rawhide kernels have a bunch of kernel debug options enabled which makes it quite slow.
>
>
> >
> > When we try btrfsck /dev/md127 i have a lot of checksum errors, and the output is:
> >
> > Checking filesystem on /dev/md127
> > UUID: e068faf0-2c16-4566-9093-e6d1e21a5e3c
> > checking extents
> > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> > checksum verify failed on 1006686208 found 457560AC wanted 6B3ECE11
> > Csum didn't match
> > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> > checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> > Csum didn't match
> > -----------------------------------------------------------------
> >
> > extent buffer leak: start 1006686208 len 4096
> > found 32039247396 bytes used err is -22
> > total csum bytes: 41608612
> > total tree bytes: 388857856
> > total fs tree bytes: 310124544
> > total extent tree bytes: 22016000
> > btree space waste bytes: 126431234
> > file data blocks allocated: 47227326464
> > referenced 42595635200
> > Btrfs v3.12
>
>
> I suggest a recent Rawhide build. And I suggest just trying to mount the file system normally first, and post anything that appears in dmesg. And if the mount fails, then try mount option -o recovery, and also post any dmesg messages from that too, and note whether or not it mounts. Finally if that doesn't work either then see if -o ro,recovery works and what kernel messages you get.
>
>
> >
> >
> >
> > When i attempt to repair i have the following error:
> > -----------------------------------------
> > Backref 1005817856 parent 5 root 5 not found in extent tree
> > backpointer mismatch on [1005817856 4096]
> > owner ref check failed [1006686208 4096]
> > repaired damaged extent references
> > Failed to find [1000525824, 168, 4096]
> > btrfs unable to find ref byte nr 1000525824 parent 0 root 1  owner 1 offset 0
> > btrfsck: extent-tree.c:1752: write_one_cache_group: Assertion `!(ret)' failed.
> > Aborted
> > ------------------------------------
>
> You really shouldn't use --repair right off the bat, it's not a recommended early step, you should try normal mounting with newer kernels first, then recovery mount options first. Sometimes the repair option makes things worse. I'm not sure what its safety status is as of v3.14.
>
> https://btrfs.wiki.kernel.org/index.php/Problem_FAQ
>
> Fedora includes btrfs-zero-log already so depending on the kernel messages you might try that before a btrfsck --repair.
>
>
>
> Chris Murphy
>

--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
       --- It's against my programming to impersonate a deity! ---

Re: Unable to boot

[Chris Murphy]

On May 5, 2014, at 9:11 AM, George Pochiscan <george.pochiscan@sphs.ro> wrote:

> Hello Hugo,
> 
> Running btrfs-zero-log /dev/md127 i have the following error:
> 
> checksum verify failed on 1001492480 found 74CC3F5D wanted C222A2C9
> Csum didn't match
> btrfs-zero-log: extent-tree.c:2717: alloc_reserved_tree_block: Assertion `!(ret)' failed.
> Aborted (core dumped)
> 
> Full output : http://pastebin.com/3h5zVuWg
> Full dmesg : http://pastebin.com/r9Fk8J8F

OK. Well I'm out of ideas at this point. I'm not a developer, and don't know what the problem is or how to fix it. So my advice at this point will be like throwing spaghetti  at a wall. (There is a lot of spaghetti available to throw at the wall when it comes to fixing btrfs if the normal mount code doesn't fix it automatically.)

Baring better advice from pretty much anyone else:

- First, btrfs-image -c9 -t4 /dev/md127 /path/for/large/file

The resulting file will be somewhere between 50% to 100% of the size reported for metadata by btrfs filesystem df. put this somewhere in case a developer wants to look at it in the current state.

- Then, btrfs check --init-csum-tree /dev/md127 will remove all checksums from the file system and should remove the csum errors preventing mount. The problem with this is it removes all checksums, so every read is reported as a mismatch but still permits the reads to proceed. As a result it's just a way to mount the file system, make a backup, and then created a new file system to restore to. So it's a recovery operation rather than a repair operation.

Chris Murphy

Re: unable to boot

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

On Sun, 09 Mar 2003 15:17:13 +0530, "praveen R-R.No.200201004" <praveen_r@students.iiit.net>  said:
>  hi,
>     when i boot  RH linux 7.2 it goes to init-2.05# prompt after the 
> message freeing kernel memory.The root partition is mounted read only and 
> none of the other partitions are mounted.Can anybody explain what is 
> happening. 

Wrong list, but I suspect your problem is either:

1) You've booted to 'single' (though other filesystems should be mounted
at this point if that were true).

2) For some reason, you booted with 'init=/bin/bash'.

3) Your root filesystem is screwed up and needs an 'fsck'.  The prompt should
look something like '(repair filesystem) #' if this is the case.

If neither of these are the case, you can either try your luck with more
details on one of the RedHat lists, or call RedHat Support if you have a
support contract....

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: unable to boot

[John Bradford]

>     when i boot  RH linux 7.2 it goes to init-2.05# prompt after the 
> message freeing kernel memory.The root partition is mounted read only and 
> none of the other partitions are mounted.Can anybody explain what is 
> happening. 

If this is a problem with a standard installation of RedHat Linux,
this isn't really an appropriate mailing list - try one of the RedHat
mailing lists instead.

If you have customised the installation, please provide more details
about which kernel you are using, and your hardware setup.

John.

unable to boot

[praveen R-R.No.200201004]

 hi,
    when i boot  RH linux 7.2 it goes to init-2.05# prompt after the 
message freeing kernel memory.The root partition is mounted read only and 
none of the other partitions are mounted.Can anybody explain what is 
happening.