[mk01]

due to some issues with usb disks and hdparm "tuning", nohdparm is in cmdline.txt, thus disabling hdparm control over the disks. try taking it out, reboot. report back.

[xraxor]

mk01 thanks so much, that worked. will it be added to the update?

Thanks so much again!!

(17th Jul, 2013 07:54 AM)mk01 Wrote:  due to some issues with usb disks and hdparm "tuning", nohdparm is in cmdline.txt, thus disabling hdparm control over the disks. try taking it out, reboot. report back.

[mk01]

(17th Jul, 2013 08:25 AM)xraxor Wrote:  mk01 thanks so much, that worked. will it be added to the update?

I would say the other way around, the nohdparm was the cause.

personally i will stay with nohdparm, but we can take it out for beta2.

mk

[xraxor]

hi guys, my hdd wont be found by xbmc again. I cannot find it under filemanager or videos. cant play any library videos.

can anyone help me please?

[IriDium]

(26th Aug, 2013 05:12 AM)xraxor Wrote:  hi guys, my hdd wont be found by xbmc again. I cannot find it under filemanager or videos. cant play any library videos.

can anyone help me please?

ssh - sudo start dbus, Restart xbmc - all ok.

Or you can do it via XBMC ->xbian-config -> services

It's a known problem

[mk01]

btw: there is another issue with allowing hdparm to set spin downs. for some SD/USB sticks it thinks it is rotational disks and tries to set spin down. this later (minutes / hours / days) leeds to freeze / or sd/usb data corruption.

so for beta2 is solved as:
1) nohdparm will be part of cmdline.txt
2) spindown setup is part of usbmount (/etc/usbmount/usbmount.conf) - it can be enabled/disabled and even set timing
3) before usbmount tries to set spin down, it double checks if the disk rotational and even if reported like that, it uses hdparm to request APM capabilities first (before try to set spin down)

hopefully this will be ok.

[xraxor]

thanks guys, I had nohdparm removed from my cmdline.txt did start dbus and it works, only till I restart xbian, dbus wont autostart. but thanks guys.

[mk01]

xraxor

until beta2 is released:
http://forum.xbian.org/thread-1270-post-14564.html#pid14564

[C.S.]

Hi all,
after my successful upgrade to beta 1.1 from beta 1, my raspberry pi hangs/crashes and is not stable anymore. It stops responding after some time and it doesn't even respond to ping. By the way I am using the default theme and I don't use overclocking. I tried without any HDMI/USB cables plugged in and it still crashes. I installed latest XBian from scratch on the same SD card and I removed the case to avoid possible overheating but the problem still remains.
When I stop XBMC service, raspberry is up and running for days without problem so it might be something related to XBMC.
Do you have any idea? I had no similar issues before...

[numanoids]

(20th Sep, 2013 07:51 PM)C.S. Wrote:  Hi all,
after my successful upgrade to beta 1.1 from beta 1, my raspberry pi hangs/crashes and is not stable anymore. It stops responding after some time and it doesn't even respond to ping. By the way I am using the default theme and I don't use overclocking. I tried without any HDMI/USB cables plugged in and it still crashes. I installed latest XBian from scratch on the same SD card and I removed the case to avoid possible overheating but the problem still remains.
When I stop XBMC service, raspberry is up and running for days without problem so it might be something related to XBMC.
Do you have any idea? I had no similar issues before...

I'm finding this also on a 256MB Pi. I thought it might have been the card at first so swapped it with one running on a 512MB Pi but the behaviour seems to persist. At first its fast and responsive btu after a while it grinds to a halt.

I'll try to capture some stats if I can regarding performance.

[f1vefour]

What is your power supply rating?

[C.S.]

I upgraded to beta2 and now it works just fine!

[mk01]

(11th Oct, 2013 01:58 AM)numanoids Wrote:  I'm finding this also on a 256MB Pi. I thought it might have been the card at first so swapped it with one running on a 512MB Pi but the behaviour seems to persist. At first its fast and responsive btu after a while it grinds to a halt.

1) edit /etc/default/zram-swap and change SIZE=128 to let's say SIZE=50. this was a very stupid bug (not considering 256 model with split 128/128. actually what happened is that from 126xxx kb system memory available to system was !! 128xxx !! allocated to in-mem zram swap. consequences are clear (OOM).

2) there was a patched zram-swap package but current version (as devel Beta2) is far away. and dependencies would probably force your system to upgrade to Beta2.

3) anyhow, this should avoid OOM, but still beta1X was swapping to file by default which is not ultra fast solution on btrfs filesystem. if you are skilled enough, shrink btrfs filesystem and create a swap partition at the end of your storage device.

finally, if you don't have bulletproof reasons to keep B1X you are running, just upgrade to B2. B2 handles all this automatically.

... but again, option 1) should help ...

[He4dShOt]

Hi all, afeter updating this morning I got this:

Code:

Setting up initscripts (2.88dsf-41+deb7u1) ...
insserv: Service checkfs has to be enabled to start service mountall
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing initscripts (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
initscripts
E: Sub-process /usr/bin/dpkg returned an error code (1)

[mk01]

@He4dShOt

do a

Code:

sudo -i
cp -av /etc/init.d /etc/init.d.bck
rm /etc/init.d/mountall*
insserv -f
dpkg --configure initscripts

reboot

should help.