Threaded Mode | Linear Mode

alfaromeo · 8th Feb, 2014, 06:43 AM

Hallo!!

First of all, thank you again for that great piece of work Smile

If it doesn't trouble me, the Xbain System works so great and smooth Smile

But now and then I have some issues.
Once a week or like every 5 days, my Xbian hung up and I wasn't able to reboot it. It got stuck on the boot-screen.
Every time, I wrote a backup-image from some weeks ago on the USB-Drive.
After doing all the updates, everything was fine again. Until some days later the same game started again Sad

Now I have the following issue (I don't know, if this one is similar to the ones before...):
Sickbeard would not work anymore, so I checked Updates.
It finds some, but when trying to install them, it won't work, because the file system is read-only!?

How can that happen? I cannot do anything! But the xbian system is still running Huh

Well, I wanted to do a restart (old windows habbit), but I thought, then it wouldnt start anymore and I have to wipe again.
NOW maybe I can find out whats the real problem - with your help Smile

I'm running xbian (newest release) on my Raspberry Pi (newest model) on a 8 GB USB Stick Transcend Jet Flash.

Do you have any suggestions?! Undecided

Thank you so much in advance!!

freem@n · 8th Feb, 2014, 08:32 AM

+1 same problem at my place with an external 2.5" USB HDD connected via an active USB hub to my XBian setup. I can confirm that it was working flawlessly before upgrading to RC1. now I can't get write permissions when accessing the samba share

alfaromeo · 11th Feb, 2014, 04:21 PM

I couldn't wait anymore and on sunday I reinstalled the backup.
Updatet everything and some time it ran all right.

10 hours ago everything was fine and I was watching stuff and the Stick and the OS was all right.
Now, the read-only bug is there again! I tried to restart the XBMC (soft restart through the menu) but during startup it hangs! "Starting XMBC" is showing about 30 to 40 seconds, then a black creen appears with some code on it - but it disappears to fast to read it. Undecided

**IriDium** · 12th Feb, 2014, 02:19 AM

Ok let's get some logs. Via pastebin as defined in "Read before you post".

1) Output from df -h
2) Output from dmesg when the R/O occurs
3) xbmc.log

alfaromeo · 15th Feb, 2014, 03:29 AM

1) Output from df -h

Code:

xbian@xbian ~ $ df -h

Dateisystem    Größe Benutzt Verf. Verw% Eingehängt auf

rootfs          7,2G    1,8G  5,2G   26% /

udev            256K    4,0K  252K    2% /dev

tmpfs            38M    228K   38M    1% /run

/dev/sda1       7,2G    1,8G  5,2G   26% /

/dev/mmcblk0p1   34M     23M   12M   66% /boot

/dev/sda1       7,2G    1,8G  5,2G   26% /home

/dev/sda1       7,2G    1,8G  5,2G   26% /lib/modules

/dev/sda1       7,2G    1,8G  5,2G   26% /xbmc-backup

/dev/sdb1       932G    920G   12G   99% /media/Files

2) Output from dmesg when the R/O occurs

Code:

[170210.449516] parent transid verify failed on 35209216 wanted 18806 found 18654

that line comes like 1000 times - only the number at the beginning changes

3) xbmc.log

Spoiler (Click to View)

ganchito55 · 16th Feb, 2014, 05:38 AM

well I have the same problem 3 times in this week. I always could fix it running:
$ sudo fsck.ext4 -v /dev/sda2

for ext4 File System

**IriDium** · 17th Feb, 2014, 01:08 AM

[170210.449516] parent transid verify failed on 35209216 wanted 18806 found 18654

is a data corruption. Was the USB card reformatted prior to the restore?
Also, how are you restoring the image?

**IriDium** · 17th Feb, 2014, 03:08 AM

Maybe related to Boot USB

alfaromeo · 17th Feb, 2014, 06:33 AM

(17th Feb, 2014 01:08 AM)IriDium Wrote: [170210.449516] parent transid verify failed on 35209216 wanted 18806 found 18654

is a data corruption. Was the USB card reformatted prior to the restore?
Also, how are you restoring the image?

I have a image file on a windows machine.
I just write that one on the stick with Win32 Disk Imager v0.9
Usually, I don't format it before... maybe that was the failure...

Unfortunately my USB-Drive got the read-only status permanetly now!! I just cannot restore or erase it. Not even with using the manufactur tools!

I made a completely new installation to my SD-Card and see how it works

**IriDium** · 17th Feb, 2014, 08:54 PM

I have a feeling that the image created by xbian-config can only be restored back to a SD card. You cannot just restore back to the USB flash driive as it will contain the /boot commands and all sorts of problems will occur.

You will need to restore to the SD card and then copy/clone to the USB card.

If you made a DD image of the USB drive this could also be the cause of your issues as DD should not be used on a btrfs file systems.

alfaromeo · 18th Feb, 2014, 06:01 AM

(17th Feb, 2014 08:54 PM)IriDium Wrote: I have a feeling that the image created by xbian-config can only be restored back to a SD card. You cannot just restore back to the USB flash driive as it will contain the /boot commands and all sorts of problems will occur.

You will need to restore to the SD card and then copy/clone to the USB card.

If you made a DD image of the USB drive this could also be the cause of your issues as DD should not be used on a btrfs file systems.

I did not use the backup from xbian-config.

I just putted the USB-Drive in my Windows PC and made an image with Win32 Disk Imager ^^
Restoring worked fine some until the RC1!

Well but as I mentioned, I did a fresh installation to my SD and don't use a USB-Stick now.

dbman · 28th Feb, 2014, 03:20 AM

+1 for this problem. I have a HFS+drive that used to mount just fine, but now it's only mounting read only.

output from df -h:
df -h
Filesystem Size Used Avail Use% Mounted on
rootfs 7.2G 1.5G 5.4G 22% /
/dev/mmcblk0p2 7.2G 1.5G 5.4G 22% /
devtmpfs 187M 4.0K 187M 1% /dev
none 38M 308K 38M 1% /run
/dev/mmcblk0p1 34M 21M 14M 61% /boot
/dev/mmcblk0p2 7.2G 1.5G 5.4G 22% /home
/dev/mmcblk0p2 7.2G 1.5G 5.4G 22% /lib/modules
/dev/mmcblk0p2 7.2G 1.5G 5.4G 22% /xbmc-backup
/dev/sda1 197M 5.0K 197M 1% /media/EFI
/dev/sda2 1.4T 766G 632G 55% /media/Ganymede

output from ls -l /dev/ (down to just sda1 and sda2)
ls -l /dev/
total 0
crw------- 1 root root 10, 235 Feb 26 00:23 autofs
drwxr-xr-x 2 root root 180 Feb 26 00:23 block
drwxr-xr-x 2 root root 60 Jan 1 1970 bsg
crw------- 1 root root 10, 234 Feb 26 00:23 btrfs-control
drwxr-xr-x 3 root root 60 Jan 1 1970 bus
drwxr-xr-x 2 root root 2060 Feb 26 00:23 char
crw------- 1 root root 5, 1 Feb 26 00:23 console
crw------- 1 root root 10, 63 Feb 26 00:23 cpu_dma_latency
drwxr-xr-x 6 root root 120 Feb 26 00:23 disk
crw-rw-rwT 2 root root 235, 12 Feb 26 00:23 erandom
crw-rw---T 1 root video 29, 0 Feb 26 00:23 fb0
lrwxrwxrwx 1 root root 13 Feb 26 00:23 fd -> /proc/self/fd
crw-rw-rwT 3 root root 235, 11 Feb 26 00:23 frandom
crw-rw-rw- 1 root root 1, 7 Feb 26 00:23 full
crw-rw---T 1 root fuse 10, 229 Feb 26 00:23 fuse
drwxr-xr-x 2 root root 60 Jan 1 1970 input
crw-r--r-- 1 root root 1, 11 Feb 26 00:23 kmsg
crw-rw---T 1 root video 247, 0 Feb 26 00:23 lirc0
lrwxrwxrwx 1 root root 21 Feb 26 00:23 lircd -> ../var/run/lirc/lircd
srw-rw-rw- 1 root root 0 Feb 26 01:36 log
crw------T 1 root root 10, 237 Feb 26 00:23 loop-control
drwxr-xr-x 2 root root 60 Feb 26 00:23 mapper
crw-r----T 1 root kmem 1, 1 Feb 26 00:23 mem
brw-rw---T 1 root floppy 179, 0 Feb 26 00:23 mmcblk0
brw-rw---T 1 root floppy 179, 1 Feb 26 00:23 mmcblk0p1
brw-rw---T 1 root floppy 179, 2 Feb 26 00:23 mmcblk0p2
brw-rw---T 1 root floppy 179, 3 Feb 26 00:23 mmcblk0p3
drwxr-xr-x 2 root root 60 Feb 26 00:23 net
crw------- 1 root root 10, 62 Feb 26 00:23 network_latency
crw------- 1 root root 10, 61 Feb 26 00:23 network_throughput
crw-rw-rw- 1 root root 1, 3 Feb 26 00:23 null
crw------T 1 root root 108, 0 Feb 26 00:23 ppp
crw-rw-rw- 1 root root 5, 2 Feb 27 17:18 ptmx
drwxr-xr-x 2 root root 0 Jan 1 1970 pts
crw-rw-rwT 2 root root 235, 12 Feb 26 00:23 random
crw-rw-rwT 1 root root 1, 8 Feb 26 00:23 random.orig
lrwxrwxrwx 1 root root 14 Jan 1 1970 root -> /dev/mmcblk0p2
brw-rw---T 1 root floppy 8, 0 Feb 26 00:23 sda
brw-rw---T 1 root floppy 8, 1 Feb 26 00:23 sda1
brw-rw---T 1 root floppy 8, 2 Feb 26 00:23 sda2

Edit: managed to get it working. Ran it through First Aid through disk utility on my mac a few times and disk warrior… not having Journaled file systems is the worst.

mk01 · 4th Apr, 2014, 12:49 PM

@dbman

be careful with HFS+ outside MAC and forcing RW. such setup is expected to hit troubles sooner or later making the HFS+ doing bad.

HFS(without journal) is ok.

and for XBian / BTRFS / suddenly R/O:
- be sure you are on 3.12.x kernel already (not 3.10.x ! )
- with 3.12.x and hitting RO remount - 99.999% hw issue (RPI itself), too much OC, or too less AC, or bad cabling or bad USBHUB (if on USB drive)

BTRFS is doing checksums of metadata written while checking that during read. RO remount means that just read metadata does not match their CRC at the time of write. making drive RO is actually a GOOD thing as continuing would mean only further and further corruption - spreading like virus.

depending on how severe the dmesg reported error is, "btrfs scrub " can recalculate the "wrong" CRC although keep in mind that either Metadata or the checksum is wrong already meaning we have to consider some file/dir properties being not correct.

but again - 3.10.x kernel could cause this corruption (under some very specific conditions), for 3.12.x no bug like that is known. so if this happens, consider the "HW staff". the "problem" could be even in 10MHz OC difference. And if someone would like to think at this point that why other FS is running OK with the same setup - the answer is it is not. but other filesystems are not checksumming what means "silent corruption" possibly realised much more later - with no way rescuing possible.

(if BTRFS fails totally with no possibility to mount it anymore, there is "btrfs restore" command allowing at least copy content out and reformat).

dbman · 9th May, 2014, 12:23 PM

Thanks @mk01 I actually do have journaling off- meaning that power outages leads to corruption often too (as there is no journal to fall back on). I eventually got it fixed with DiskWarrior on my mac- like you said the metadata was corrupt. Even disk utility wasn't able to touch it and it usually does the trick after a power outage. Thank you for your help. I will use btrfs scrub in the future. Thank you for all of your work on this. I really appreciate it and all the time you take to help people.