22nd Dec, 2013, 01:11 AM
22nd Dec, 2013, 01:31 AM
Yes it's possible - just press "Prt Scr" and it should ask you for which folder, if not already setup.
22nd Dec, 2013, 09:17 AM
I recently have issues with XBian Beta 1.1 and Beta 2. I constantly get this message (even after clean installs):
And then my system becomes hardly usable.
Code:
[ 262.108203] mmcblk0: timed out sending r/w cmd command, card status 0x400d00
[ 274.095609] mmc0: Controller never released inhibit bit(s)
22nd Dec, 2013, 09:35 AM
few days ago solved this by buing one card new and second reformated twice with some kind of software.
22nd Dec, 2013, 09:40 AM
What software? This happens with both brand new SD cards and already used ones.
22nd Dec, 2013, 09:50 AM
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.
low level sector by sector rewrite - nothing special. i also cleaned the sd card slots on RPis from dust. did nothing else.
22nd Dec, 2013, 10:25 AM
Didn't work
[ 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
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
22nd Dec, 2013, 11:19 AM
I'm wondering whether the "boom" like anounced solution in rpi firmware for SD-card corruption is this one ;-)
What firmware you run ?
What firmware you run ?
22nd Dec, 2013, 06:48 PM
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)
22nd Dec, 2013, 11:58 PM
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?
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?
23rd Dec, 2013, 12:23 AM
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).
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).
23rd Dec, 2013, 01:13 AM
Any ideas to my problems?
23rd Dec, 2013, 02:01 AM
@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.
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.
23rd Dec, 2013, 07:27 AM
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.
24th Dec, 2013, 06:09 PM
@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.
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.