* Unable to boot @ 2014-05-02 10:00 George Pochiscan 2014-05-02 19:41 ` Chris Murphy 0 siblings, 1 reply; 9+ messages in thread From: George Pochiscan @ 2014-05-02 10:00 UTC (permalink / raw) To: linux-btrfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unable to boot 2014-05-02 10:00 Unable to boot George Pochiscan @ 2014-05-02 19:41 ` Chris Murphy 2014-05-05 15:04 ` George Pochiscan 0 siblings, 1 reply; 9+ messages in thread From: Chris Murphy @ 2014-05-02 19:41 UTC (permalink / raw) To: George Pochiscan; +Cc: linux-btrfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Unable to boot 2014-05-02 19:41 ` Chris Murphy @ 2014-05-05 15:04 ` George Pochiscan 2014-05-05 15:07 ` Hugo Mills 0 siblings, 1 reply; 9+ messages in thread From: George Pochiscan @ 2014-05-05 15:04 UTC (permalink / raw) To: Chris Murphy; +Cc: linux-btrfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unable to boot 2014-05-05 15:04 ` George Pochiscan @ 2014-05-05 15:07 ` Hugo Mills 2014-05-05 15:11 ` George Pochiscan 0 siblings, 1 reply; 9+ messages in thread From: Hugo Mills @ 2014-05-05 15:07 UTC (permalink / raw) To: George Pochiscan; +Cc: Chris Murphy, linux-btrfs [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Unable to boot 2014-05-05 15:07 ` Hugo Mills @ 2014-05-05 15:11 ` George Pochiscan 2014-05-05 21:49 ` Chris Murphy 0 siblings, 1 reply; 9+ messages in thread From: George Pochiscan @ 2014-05-05 15:11 UTC (permalink / raw) To: Hugo Mills; +Cc: Chris Murphy, linux-btrfs 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! --- ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: Unable to boot 2014-05-05 15:11 ` George Pochiscan @ 2014-05-05 21:49 ` Chris Murphy 0 siblings, 0 replies; 9+ messages in thread From: Chris Murphy @ 2014-05-05 21:49 UTC (permalink / raw) To: George Pochiscan; +Cc: Hugo Mills, linux-btrfs 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* unable to boot @ 2003-03-09 9:47 praveen R-R.No.200201004 2003-03-09 9:54 ` John Bradford 2003-03-09 19:02 ` Valdis.Kletnieks 0 siblings, 2 replies; 9+ messages in thread From: praveen R-R.No.200201004 @ 2003-03-09 9:47 UTC (permalink / raw) To: linux-kernel 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: unable to boot 2003-03-09 9:47 unable " praveen R-R.No.200201004 @ 2003-03-09 9:54 ` John Bradford 2003-03-09 19:02 ` Valdis.Kletnieks 1 sibling, 0 replies; 9+ messages in thread From: John Bradford @ 2003-03-09 9:54 UTC (permalink / raw) To: praveen R-R.No.200201004; +Cc: linux-kernel > 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: unable to boot 2003-03-09 9:47 unable " praveen R-R.No.200201004 2003-03-09 9:54 ` John Bradford @ 2003-03-09 19:02 ` Valdis.Kletnieks 1 sibling, 0 replies; 9+ messages in thread From: Valdis.Kletnieks @ 2003-03-09 19:02 UTC (permalink / raw) To: praveen R-R.No.200201004; +Cc: linux-kernel [-- 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 --] ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2014-05-05 21:49 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-05-02 10:00 Unable to boot George Pochiscan 2014-05-02 19:41 ` Chris Murphy 2014-05-05 15:04 ` George Pochiscan 2014-05-05 15:07 ` Hugo Mills 2014-05-05 15:11 ` George Pochiscan 2014-05-05 21:49 ` Chris Murphy -- strict thread matches above, loose matches on Subject: below -- 2003-03-09 9:47 unable " praveen R-R.No.200201004 2003-03-09 9:54 ` John Bradford 2003-03-09 19:02 ` Valdis.Kletnieks
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.