[pipes]

i shutdown on shutdown button....

is possible take scrrens shots of xbian??

thanks

[IriDium]

Yes it's possible - just press "Prt Scr" and it should ask you for which folder, if not already setup.

[CurlyMo]

I recently have issues with XBian Beta 1.1 and Beta 2. I constantly get this message (even after clean installs):

Code:

[  262.108203] mmcblk0: timed out sending r/w cmd command, card status 0x400d00
[  274.095609] mmc0: Controller never released inhibit bit(s)

And then my system becomes hardly usable.

[mk01]

few days ago solved this by buing one card new and second reformated twice with some kind of software.

[CurlyMo]

What software? This happens with both brand new SD cards and already used ones.

[mk01]

https://www.sdcard.org/downloads/formatter_4/

low level sector by sector rewrite - nothing special. i also cleaned the sd card slots on RPis from dust. did nothing else.

[CurlyMo]

Didn't work

Terminal

[ 341.999925] mmc0: Controller never released inhibit bit(s).
[ 342.028957] mmcblk0: timed out sending r/w cmd command, card status 0x400d00
[ 426.830707] mmc0: Controller never released inhibit bit(s).
[ 426.857978] mmcblk0: timed out sending r/w cmd command, card status 0x400d00
[ 432.822228] mmc0: Controller never released inhibit bit(s).
[ 432.853970] mmcblk0: timed out sending r/w cmd command, card status 0x400d00
[ 482.328184] mmc0: Controller never released inhibit bit(s).
[ 482.415509] mmcblk0: timed out sending r/w cmd command, card status 0x400d00
[ 608.907543] device label xbian-beta2 devid 1 transid 67 /dev/mmcblk0p2
[ 874.122386] mmc0: Controller never released inhibit bit(s).
[ 874.149114] mmcblk0: timed out sending r/w cmd command, card status 0x400d00
[ 885.314163] mmc0: Controller never released inhibit bit(s).
[ 885.419626] mmcblk0: timed out sending r/w cmd command, card status 0x400d00

[mk01]

I'm wondering whether the "boom" like anounced solution in rpi firmware for SD-card corruption is this one ;-)

What firmware you run ?

[CurlyMo]

Terminal

root@xbian:~# uname -r
3.10.12+
root@xbian:~# vcgencmd version
Oct 1 2013 00:37:09
Copyright © 2012 Broadcom
version a421d4b2cee544ec22bd4eee75080248f18fc20b (tainted) (release)

[IriDium]

Beta 2 – Latest upgrades + staging.

From 2G SD card boot, created an .img file via ssh xbian-config to an external NTFS drive. Image file creation ended normally. (Or so it said)

Used this image to flash a new 2G SD card with Win32diskimager.

Booted the RPi – all lights came on but wouldn’t boot. Flashing cursor in top left corner (Tried twice, same results).

cmdline.txt and config.txt look Ok, so removed the # from initram in config.txt, but all that happened was that it then wouldn’t boot at all – only red light.

Read the original SD card with Win32diskimager and created an image with that.

There was a difference in size. Xbian = 1665M Win32 = 1982M.

Couldn’t use the Win32 image as it was too large for the SD card.

Any idea what could be happening here?

The system is 69% full using df –h.

Retried with a fresh Xbian 2 no staging this time, upgraded. System 54% full. Wrote a .img as before. Rewrote the image to SD card and rebooted. Worked just fine.

So, tried again on the Staging SD card. Removed some files, space now 55% - wrote img as before and retried.

Same results. So looks like something is amiss in the staging repo

root@xbian:~# xbian-apt-show-versions -u
gnupg/wheezy 1.4.12-7+deb7u2 upgradeable to 1.4.12-7+deb7u3
gpgv/wheezy 1.4.12-7+deb7u2 upgradeable to 1.4.12-7+deb7u3
kpartx/wheezy 0.4.9+git0.4dfdaf2b-7~deb7u1 upgradeable to 0.4.9+git0.4dfdaf2b-7~deb7u2
libcurl3/wheezy 7.26.0-1+wheezy6 upgradeable to 7.26.0-1+wheezy7
libcurl3-gnutls/wheezy 7.26.0-1+wheezy6 upgradeable to 7.26.0-1+wheezy7
libexpat1/wheezy 2.1.0-1 upgradeable to 2.1.0-1+deb7u1
libmysqlclient18/wheezy 5.5.31+dfsg-0+wheezy1 upgradeable to 5.5.33+dfsg-0+wheezy1
mysql-common/wheezy 5.5.31+dfsg-0+wheezy1 upgradeable to 5.5.33+dfsg-0+wheezy1
tzdata/wheezy 2013d-0wheezy1 upgradeable to 2013h-0wheezy1
xbian-package-config-shell/stable 2.1.6-52g upgradeable to 2.1.6-52h
xbian-package-config-xbmc/stable 1.1.4-3a upgradeable to 1.1.4-4b
xbian-package-vnc-server/stable 1.0.0-3b upgradeable to 1.0.1

Any ideas?

[mk01]

My guess is VFAT didn't survive the dd-ing into img file. There is no magic while doing the clone - first partition (32mb) is copied with dd. If PCs would have been 100% reliable then it MUST boot. Apparently no so I will re-code this to proper mkfs.vfat and copy files (with -v).

Also initramfs should be uncommented as after reflash we need resize + swap creation. Will fix.

Size difference is ok as xbianclone is not doing block copy. It uses btrfs internal functions. And always makes .img as small as possible (to be able to restore to smaller SDs as well in case of emergency).

[CurlyMo]

Any ideas to my problems?

[mk01]

@Curly

hardly specially if you saying that existing beta1 install is doing the same "suddenly". in few results from google reasons were wearing off PSU, wearing off SD, wearing off RPI.

btw: feel free to update firmware. you can update to -9 (Dec-1st) or -11 (Dec-9th). Dec1st was the one generally recommended with all the fixes.

[CurlyMo]

Trying right know. The wierd thing is that it happens with two pi's, with two PSU, and with multiple SD cards, were i never had issues before.

[mk01]

@CurlyMo

I was reviewing some past changes on kernels and found at least two commits which are actually INTRODUCING outputs about errors on MMC.

So could be that those errors are happening (or were happening) all the time, only nobody took care with notifications.