Forum

Hi,

I've successfully installed XBian, and it ras perfectly. Then, after a few days, it didn't boot after a restart, and got stuck saying "Moving root", and then "Switching root" (HDMI output).

I found out that pressing CTRL+ALT+DEL would terminate whatever it was doing and caused a reboot.

The first line that shows after rebooting says that I can press and hold SHIFT to get a shell, but doing that changes nothing. It could be that my TV is too slow restoring the picture after the reboot (it takes a few seconds with "no input detected" until it detects the Pi's output), so I tried pressing SHIFT at various times during boot but without success.

I flashed the SD card with a new image, but it didn't boot, got stuck in the same situation. I continued trying CTRL+ALT+DEL again a few times to see if I could make something new happen while rebooting.

I then remembered it could be my external USB disk causing the problem, as the periodic disk checks sometimes take days to complete and I hadn't disabled that in the USB disk yet (although only a few days had passed, not the typical 25 days). I removed the disk altogether, but no luck.

I removed every USB peripheral, including keyboard, but nothing changed. Then I put back the USB keyboard and, on one of the CTRL+ALT+DEL attempts, the sequence resulted in XBMC starting instead of rebooting, and everything seemed fine after that.

The first thing I did was change the fstab file to disable automatic disk checks, by replacing the final "1" with a "0".

Then I removed the splash, set it not to be quiet, and included "loglevel" (although I'm not sure anything changed with this last option).

I disabled overclocking (I always do).

I have no reason to suspect the hardware, as inserting a new card works perfectly. Also, the card I'm trying to boot from on another Pi results in exactly the same behaviour.

Anyway, everything worked just fine after that for a few days, I rebooted many times, I have the USB disk had everything else connected to it as usual, and it always moved past the "Switching root" line.

Today, after a normal reboot, there it is again: stuck "switching root". Removing the USB external disk didn't solve anything, and it has been stuck there for well over an hour now.

Any ideas on what I should do to recover from this? And how to make it not happen again?

Thanks!

1) put "debug" into cmdline and let's see, how far you get.

2) put "init=/bin/bash" into cmdline to start a shell immediately after switch root. if you get shell, then it's stuck somewhere on processing /sbin/init and you should be able to see something with 1)

if you don't get shell with 2), something is messing your SD card.

how does your /etc/fstab look like? and please check for "nohdparm" option in cmdline, if it is not there, put it there.

(26th Aug, 2013 10:42 PM)mk01 Wrote: [ -> ]1) put "debug" into cmdline and let's see, how far you get.

2) put "init=/bin/bash" into cmdline to start a shell immediately after switch root. if you get shell, then it's stuck somewhere on processing /sbin/init and you should be able to see something with 1)

if you don't get shell with 2), something is messing your SD card.

how does your /etc/fstab look like? and please check for "nohdparm" option in cmdline, if it is not there, put it there.

Thanks for your quick reply. Unfortunately my Linux skills are very limited. What is the "command line"? I did a quick Google but it seems to be a complex subject... is it something in "config.txt"?

I can't remember all of fstab (and I can't see it now that it is not booting), but the line I added (to the 4 or 5 lines of the fstab file that already existed) was:

UUID=5916829a-80bd-4add-8884-cb06ced01442 /RILHAS-SRV ext3 defaults,exec,errors=remount-ro 0 0

I think I saw this disk already mounted on /media, but mounting it again at /RILHAS-SRV didn't seem to cause any issues, so I've been using it like this for a long time now. I remember having something to do with me not being able to execute applications from the USB disk, so I added this new mount to allow me to do that.

BTW: Is there any way for me to access the SD card contents from Windows? My laptop's card reader is not recognized as a device that I can simply pass along to my VirtualBox Ubuntu, and file sharing will not work because Windows doesn't recognize the file system.

Thanks again!

with cmdline I meant /boot/cmdline.txt. you was changing parameters there already.

when you do the 2) and you get prompt, run "nano /etc/fstab" and edit the line with your RILHAS-SRV record - add "nobootwait" parameter to it. so it would look like:

UUID=5916829a-80bd-4add-8884-cb06ced01442 /RILHAS-SRV ext3 defaults,exec,errors=remount-ro,nobootwait 0 0

---

if you can't pass the sd to your virtualbox linux, you will not able to access the filesystem.

but with the init=/bin/bash in cmdline.txt you should get the prompt (as with ssh) and be able to perform commands. at least those which we will tell you - if you are not skilled with linux.

(26th Aug, 2013 11:16 PM)mk01 Wrote: [ -> ]with cmdline I meant /boot/cmdline.txt. you was changing parameters there already.

when you do the 2) and you get prompt, run "nano /etc/fstab" and edit the line with your RILHAS-SRV record - add "nobootwait" parameter to it. so it would look like:

UUID=5916829a-80bd-4add-8884-cb06ced01442 /RILHAS-SRV ext3 defaults,exec,errors=remount-ro,nobootwait 0 0

---

if you can't pass the sd to your virtualbox linux, you will not able to access the filesystem.

but with the init=/bin/bash in cmdline.txt you should get the prompt (as with ssh) and be able to perform commands. at least those which we will tell you - if you are not skilled with linux.

My first task then is to try to access the SD card's file system to make the required changes to the command line (maybe with some external USB card reader that I can pass to Ubuntu as a device). I'll come back after that and after completing your instructions.

Thanks for all your help!

Rilhas, sorry, I didn't get you right.

you will access the /boot from windows. it is FAT filesystem.

what I meant is you can't access the XBIAN filesystems from windows.

again. /boot is fine.

(27th Aug, 2013 12:02 AM)mk01 Wrote: [ -> ]Rilhas, sorry, I didn't get you right.

you will access the /boot from windows. it is FAT filesystem.

what I meant is you can't access the XBIAN filesystems from windows.

again. /boot is fine.

Ah, great!!

The "cmdline.txt" had the following:

sdhci-bcm2708.sync_after_dma=0 dwc_otg.lpm_enable=0 console=tty1 root=LABEL=xbian-root-btrfs rootfsopts=subvol=root/@,noatime,compress=lzo,thread_pool=1,space_cache,autodefrag rootfstype=btrfs rootwait=10 smsc95xx.turbo_mode=N elevator=noop nohdparm loglevel=0 noswap mod_scsi.scan=async

I didn't find any reference to "switch root" in there, so I was unable to place the init=/bin/bash immediately after it. I added it to the end of the file, together with "debug". Here is the resulting file:

sdhci-bcm2708.sync_after_dma=0 dwc_otg.lpm_enable=0 console=tty1 root=LABEL=xbian-root-btrfs rootfsopts=subvol=root/@,noatime,compress=lzo,thread_pool=1,space_cache,autodefrag rootfstype=btrfs rootwait=10 smsc95xx.turbo_mode=N elevator=noop nohdparm loglevel=0 noswap mod_scsi.scan=async debug init=/bin/bash

(there was also a "cmdline.txt.old" with this:
sdhci-bcm2708.sync_after_dma=0 dwc_otg.lpm_enable=0 console=tty1 root=LABEL=xbian-root-btrfs rootfsopts=subvol=root/@,noatime,compress=lzo,thread_pool=1,space_cache,autodefrag rootfstype=btrfs rootwait=10 smsc95xx.turbo_mode=N elevator=noop nohdparm splash logo.nologo quiet loglevel=0 noswap mod_scsi.scan=async
)

The shell showed up, and I was able to edit fstab to add the "nobootwait", just like you said. The "fstab" was then like this:

#
#
#
proc /proc proc defaults 0 0
LABEL=xbian-root-btrfs / btrfs subvol=root/@,thread_pool=1,rw,compress=lzo,noatime,autodefrag 0 0
LABEL=xbian-root-btrfs /home btrfs subvol=home/@,thread_pool=1,rw,compress=lzo,noatime,autodefrag 0 0
UUID=8B12-9112 /boot vfat defaults 0 0
UUID=5916829a-80bd-4add-8884-cb06ced01442 /RILHAS-SRV ext3 defaults,exec,errors=remount-ro,nobootwait 0 0


Then I tried editting the command line to remove the shell, but /boot was empty (is this normal??). So I editted it back on my laptop (by removing the bash and leaving the debug) and tried again (without any USB peripherals except for the keyboard and mouse).

The system booted, but XBMC was not started automatically, and a login prompt appeared instead. I logged in and confirmed "xbmc.bin" was not running.

I removed the "debug" in the command line and tried again, but the result was the same and XBMC did not start. I started it manually and it started without any problems.

Then I added "debug" to the command line again (just in case) and tried adding all the USB peripherals, and the system booted. And, surprisingly, so did XBMC.

So I guess it was the "nobootwait" thing in fstab (and maybe XBMC was not booting because I have added media sources from the external USB disk). This solution works well for me because I already had a script waiting for the USB disk to get mounted before starting all the applications in it (legacy from another embedded computer I used before the Pi came along), so it is working just fine.

As for the reason why it worked so many times before and then suddenly stopped booting? No idea. And as for the reason why it always worked without the USB disk and then, after encountering the problem once, it didn't boot even if the disk wasn't there? Also, no idea.

... anyway, I think I remember having to do something else to disable the periodic disk checks, I would not be surprised if all of this was being caused by something related to that. I seem to remember that one component of it was the fstab "trailing zero", but I think there were other components related to the number of days or the number of mounts or something like that. I'll check my notes, I'm sure I've written it down somewhere.

Thanks for your help! :-)

you are welcome.

the xbmc not starting will be part of the "freeze", attached / non-attached this particular disk (being written in fstab) and whether it was or wasn't mounted during boot.

if I remember correctly, /etc/init/xbmc.conf holds dependency for "local-filesystems".

as the usb will be mounted with usbmount, when recognized by udevd during boot, maybe better would be "noauto" instead of "nobootwait".

with noauto the disk won't be counted to as needed for "local-filesystems" condition to be fulfilled so the xbmc should start regardless of it. try.

(27th Aug, 2013 01:48 AM)mk01 Wrote: [ -> ]you are welcome.

the xbmc not starting will be part of the "freeze", attached / non-attached this particular disk (being written in fstab) and whether it was or wasn't mounted during boot.

if I remember correctly, /etc/init/xbmc.conf holds dependency for "local-filesystems".

as the usb will be mounted with usbmount, when recognized by udevd during boot, maybe better would be "noauto" instead of "nobootwait".

with noauto the disk won't be counted to as needed for "local-filesystems" condition to be fulfilled so the xbmc should start regardless of it. try.

I want to use the "nobootwait" option, because if the USB disk fails I can then still fallback to running critical applications from the SD card (the domotics has rsync'ed folders on the card), which is way better than the system hanging forever.

Can the "nobootwait" be used at the same time as "noauto"? I think this would be ideal for me.

Thanks for the explanation!