NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Failed ReadyNas 104, mount BTRFS volume on Linux
Hi community, I was happy user of ReadyNas 104 (had two of them in different time) and was loyal to netgear brand (routers, mesh, etc). But my recent experience is not that positive as after about ...
Yermak wrote:
P.S. Additional heart-stopping episode was with my cat messing around HDD hanging from the PC tower and causing HDD to disconnect during btrfs check recovery. Raid went out of sync, assembling 3 drives out of 4. But I was able to restore the raid with
mdadm /dev/md127 --add /dev/sdb
It took about 10 hours to resync, but seems to be fine now.
Are you saying the mdadm is fine, but btrfs still fails to mount? Or that you were able to remount the volume as btrfs after the resync???
I'm guessing that btrfs still fails to mount.
Yermak wrote:
dmesg
[ 4498.628078] BTRFS info (device md127): flagging fs with big metadata feature
[ 4498.628095] BTRFS warning (device md127): 'recovery' is deprecated, use 'rescue=usebackuproot' instead
[ 4498.628100] BTRFS info (device md127): trying to use backup root at mount time
[ 4498.628104] BTRFS info (device md127): disk space caching is enabled
[ 4498.664705] BTRFS critical (device md127): corrupt leaf: root=1 block=28693330493440 slot=49, invalid root flags, have 0x10000 expect mask 0x1000000000001
[ 4498.664711] BTRFS error (device md127): block=28693330493440 read time tree block corruption detected
[ 4498.664877] BTRFS critical (device md127): corrupt leaf: root=1 block=28693330493440 slot=49, invalid root flags, have 0x10000 expect mask 0x1000000000001
[ 4498.664881] BTRFS error (device md127): block=28693330493440 read time tree block corruption detected
[ 4498.664886] BTRFS warning (device md127): failed to read root (objectid=2): -5
[ 4498.708647] BTRFS critical (device md127): corrupt leaf: root=1 block=28693526478848 slot=49, invalid root flags, have 0x10000 expect mask 0x1000000000001
[ 4498.708657] BTRFS error (device md127): block=28693526478848 read time tree block corruption detected
[ 4498.712357] BTRFS critical (device md127): corrupt leaf: root=1 block=28693526478848 slot=49, invalid root flags, have 0x10000 expect mask 0x1000000000001
[ 4498.712367] BTRFS error (device md127): block=28693526478848 read time tree block corruption detected
[ 4498.712392] BTRFS warning (device md127): failed to read root (objectid=2): -5
[ 4498.731972] BTRFS error (device md127): parent transid verify failed on 28693524611072 wanted 3643412 found 3643414
[ 4498.744606] BTRFS error (device md127): parent transid verify failed on 28
Alternatively considering downgrading ubuntu to 14 and potentially get lower version of BTRFS.
I think downgrading is a long shot. But if you want to match the btrfs and mdadm versions running on the NAS, here's what it is running (OS 6.10.8):
root@RN102:~# mdadm --version
mdadm - v4.1 - 2018-10-01
root@RN102:~# btrfs version
btrfs-progs v4.16
root@RN102:~#
Unfortunately, the modinfo method doesn't work:
root@RN102:~# modinfo btrfs | grep version
modinfo: ERROR: Module btrfs not found.The only module listed in /proc/modules is the VPD
root@RN102:~# cat /proc/modules
vpd 9104 0 - Live 0xbf000000 (PO)
root@RN102:~#
Have you tried using smartctl to run a long test on all the disks?
Here is root cause and solution I found:
incompat_flags 0x21
( MIXED_BACKREF |
BIG_METADATA )It seems my ReadyNas migrated to btrfs at some strange point, where those flags where enabled for btrfs, this resulted btrfs being incompartible with btrfs in ubuntu (it was 5.x version).
Is it an issue for all ReadyNas with i.e. ReadyNas OS have those flags for everynas or is it dependant on time of migration to btrfs, it's hard to say. I was running quite latest version of OS available at that moment.
So, eventually I solved the problem using Ubuntu 14, it just worked with btrfs - no incompatibliyt issues. Could it work on something between Ubuntu 14 and Ubuntu 20, - i don't know. But you may want to experiment if you faced this issue.
As there is coninuation of story.
Once I mounted btrfs I had to restore several LUNs, several of them where encrypted with VeraCrypt.
There are multiple guides to mount iscsi file via loop device, e.g. here http://infotinks.com/mount-luns-with-partitions-using-losetup-and-kpartx/
where you would use command
# losetup /dev/loop0 lunfile -o OFFSET
To calculate offset you need to use command and multilply offset by sector size normally 512.
# fdisk -lu lunfile
The problem with Ubuntu 14, fdisk returns wrong results and does not show correct offset.
# sgdisk -p lunfile - does not work either, despite fdisk show partition in lunfile as GPT.
So, i had to copy lunfile to another linux and run fdisk on lunfile there and it worked ok gave me expected rusult of offset (I can't remember exact offset which was used and I did not keep lun files).
Then I was able to mount lunfile via losetup as expected.
On encrypted lunfiles, i tried to expose on another system via iSCSI hoping to mount them via VeraCrypt on windows machine, but probably iSCSI demon implementation also changed and another linux could not expose raw devices properly.
So, i downlowed quite old console version of VeraCrypt to match Ubunu 14 and after mounting lunpartion via loopback was able to mount it via console version of VeraCrypt.
So, it was happy end for me. Restoring data from ReadyNas is possible, but good guide or better live linux distro would be nice.
I think it's not diffucult to build linux distro with compatible versions of mdadm, btrfs, fdisk, iSCSI, so, if someone face similar issue again - you just plug your disks and live drive into PC and follow instuction...
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
