My brother's had a bit of a disaster and his RPi won't boot. He's using a SD/USB boot and I've recopied the files to the FAT partition on the SD and it still doesn't boot, so it must be the USB that's corrupt but as Windows can't read the Linux partition on that, I'm not sure how to fix it.
I managed to get him running temporarily by changing to a SD-only boot, as I kept the second partition on there for such emergencies but I had to spend hours talking him through how to setup his media folders and so on, as I can't connect to it with Putty or WinSCP. I've definitely got the right IP address but both programs just fail to connect, with no error from the Pi to indicate where the problem might be.
If I could connect, I could take a look at the USB partition via WinSCP and copy across the files we backed up in August if necessary but without any way to connect, I obviously can't do that.
I did try booting Damn Small Linux in Virtualbox with the SD card in a USB adapter attached to the VM but it didn't seem to mount it anywhere, so I don't think I'll be able to access the USB stick that way either.
Can anyone please advise how I can sort this out? Once it's working again, I'll make an image of the SD card and USB in case it happens again, which I thought we'd already done but I can't see them anywhere on his PC, so I guess we didn't!
Have you confirmed it's picking up the same IP address? Network address details can be viewed on the Information page.
After you switched to /storage on the SD card, ssh may have been disabled (your settings are in the /storage partition, so you'll be using completely different settings). Re-enable ssh in the OpenELEC Settgins addon (or add "ssh" to the end of your line in /flash/cmdline.txt).
Yep, I checked at the router and from the Information page and was able to ping it on 192.168.1.83, which is the address that's already set in WinSCP and Putty.
I had a look in the OE Settings addon but can't see anywhere to enable SSH, only a "Disable SSH Password" option. I'll double-check but I'm pretty sure my brother's got the same cmdline.txt as me, as I no doubt just used the files I'd created for my own build when I setup his and my SD-boot file has "boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 ssh quiet".
I recall in the past I had trouble connecting to my system which turned out to be caused by corrupt SSH keys but I think when that happened Putty at least got part-way into the login process before failing, so this seems rather different.
Perhaps an option might be to SD/NFS boot and then if that gets WinSCP working, I might be able to fix the files on the USB.
I haven't done this for a while and I don't seem to have kept a backup of my cmdline.txt for NFS booting. I found this thread
http://forum.xbmc.org/showthread.php?tid=149607 which suggests that I need to put folders SYSTEM (containing just the SYSTEM file) and STORAGE in my NFS Share and cmdline.txt would be:
ip=dhcp boot=NFS=192.168.1.64:/NFS/rpi#1 disk=NFS=192.168.1.64:/NFS/rpi#1 ssh
where NFS is the share name as setup in HanewinNFS with this export line:
e:\RPI -public -maproot:0:0 -mapall:0:0 -alldirs -name:NFS
but the rpi#1 bit looks a bit strange and unfamiliar to me.
It's been a long time since I looked at the Settings addon, I always thought it enabled/disabled sshd rather than just the password!
Why not just mount the USB in the DSL VM?
If you're going to try using disk=NFS, at least keep boot=/dev/mmcblk0p1 - there's no real benefit (but plenty of downside) when accessing SYSTEM over NFS. Mounting /storage over NFS is fine though. In which case your cmdline.txt should be:
Code:
ip=dhcp boot=/dev/mmcblk0p1 disk=NFS=192.168.1.64:/NFS/rpi#1 ssh
where the rpi#1 folder on your NAS will be seen as the /storage folder on your Pi.
(2014-10-13, 01:36)Milhouse Wrote: [ -> ]It's been a long time since I looked at the Settings addon, I always thought it enabled/disabled sshd rather than just the password!
Why not just mount the USB in the DSL VM?
I'll try but as I couldn't see the SD card in the VM, I'm not sure I'll be able to see the USB either. I'm not exactly very experienced with Linux though, so I'm probably just not doing something that I need to do to mount it.
Quote:If you're going to try using disk=NFS, at least keep boot=/dev/mmcblk0p1 - there's no real benefit (but plenty of downside) when accessing SYSTEM over NFS. Mounting /storage over NFS is fine though. In which case your cmdline.txt should be:
Code:
ip=dhcp boot=/dev/mmcblk0p1 disk=NFS=192.168.1.64:/NFS/rpi#1 ssh
where the rpi#1 folder on your NAS will be seen as the /storage folder on your Pi.
OK, yeah it makes more sense to boot SYSTEM from SD and I think is what I used to do. So are you saying I need to create a folder under my NFS share called rpi#1 in which I should put the files that go in /storage? It's confusing as that thread uses SYSTEM/rpi#1 and STORAGE/rpi#1 (I miscopied the line in my previous post and left out SYSTEM/ and STORAGE/ by mistake, sorry) and I don't see why I'd want an rpi#1 subfolder under each. So can I just have /NFS/Storage with the /storage files in and forget about this rpi#1?
(2014-10-13, 01:47)doveman2 Wrote: [ -> ]So are you saying I need to create a folder under my NFS share called rpi#1 in which I should put the files that go in /storage?
Yes, you'll need a folder called "rpi#1" in your "NFS" export (ie. e:\RPI\rpi#1) using the cmdline.txt you posted.
(2014-10-13, 01:47)doveman2 Wrote: [ -> ]It's confusing as that thread uses SYSTEM/rpi#1 and STORAGE/rpi#1 (I miscopied the line in my previous post and left out SYSTEM/ and STORAGE/ by mistake, sorry) and I don't see why I'd want an rpi#1 subfolder under each. So can I just have /NFS/Storage with the /storage files in and forget about this rpi#1?
The thread you copied from is proposing a more generic solution, with separate System and Storage folders for each Pi client (of which you may have several).
You could even use just "disk=NFS=192.168.1.64:/NFS" which would mean your /storage folder is mounted from the "NFS" share/folder (ie. e:\RPI directory on the server).
Thanks, I understand now.
I'll setup the NFS as a stopgap to get him running with his previous setup.
I still need to work out how to mount the USB to access it in DSL and also mount a Shared Folder on the real HDD so that I can copy files to/from the USB. It doesn't mount any USB that's connected to the VM automatically and it needs the Virtualbox additions installed to access Shared Folders and I can't mount that ISO to install them as DSL is running from a mounted ISO. I might be able to use FTP for the file transfer though, if I can just get the USB mounted.
A easier option though might be to use this program to read Linux partitions in Windows, which apparently works with ext4 (which I think is what OE uses) for both read and write:
http://www.paragon-drivers.com/extfs-windows/
OK, in HanewinNFS I've got the mount point set as:
d:\RPI -public -maproot:0:0 -mapall:0:0 -alldirs -name:NFS
and there's a folder d:\RPI\storage which has the contents of /storage in it.
The cmdline.txt is set to:
ip=dhcp boot=/dev/mmcblk0p1 disk=NFS=192.168.1.64:/NFS/storage/ ssh
but trying to boot, it throws up errors which include (roughly, as I'm going by what my brother told me) "can't access pty", "Job control turned off" and "mount failed".
I managed to access the linux partition on the SD card with that paragon driver, so I copied the contents of d:\rpi\storage to the sd card and it boots from that (using the OpenELEC Helix build: #1012) and has the right skin (xTV-SAF) and some of his video folders but keeps crashing/locking up shortly after (it throws up a lot of "Do you want to disable this addon" messages, at least on the first boot but I can't really talk my brother through going through each addon category and reading them all out to me so that I can tell him which he should try disabling) and all my brother can do is open the shutdown menu and reboot. I also still can't connect via WinSCP or Putty, although it gets a bit further than before but Putty throws up "couldn't agree a host key algorithm".
Also, when going to Videos - Add Videos or File Manager - Add Source, browsing the NFS share only shows 192.168.1.69, when it should be 192.168.1.64 (there's no machine running on 1.69) and I'm not sure where to change that.
The USB stick in the PC doesn't get recognised at all, although the light on it blips briefly when it's plugged in, so that might be completely dead now but if I can just get it working via NFS or the SD card with SSH access, I can sort out a new USB stick later.
Where are the ssh files located in storage anyway? I was wondering if I could copy them from my RPi, which has working SSH/WinSCP access and put them on my brother's /storage (with the SD connected to the PC) to get it working?
Once that's working, I might just rename .xbmc to .xbmc.bak, to let it create a new .xbmc from scratch, then copy over some stuff from userdata (.xml files, keymaps/, Database/, Thumbnails/ and then from addons/ just the skin.xtv-saf.svn as it's difficult installing that from scratch as it tends to throw up incompatible/dependency errors but it works fine once installed).
EDIT: To get SSH working, can I just copy and paste the files from my cache/ssh/ ? For NFS, do I have to edit a file somewhere to preset the address of the server or should it automatically just show the available servers on the network, as it's not doing that at the moment and is just showing this phantom 192.168.1.69? On my own RPi, it shows both my PCs at 192.168.1.64 and 192.168.1.66, so I'm guessing it should be automatic unless I manually set those two already in a file somewhere.
Just as a curiosity, you know that re-installing Openelec would likely take less than an hour to accomplish and have a booting system back right? If you can't connect from your location, surely you can just create and send him a sources.xml and easily walk him through scp'ing the file over? Just seems like you are spending an inordinate amount of time trying to salvage something that is more easily built from scratch...
(2014-10-14, 19:57)ActionA Wrote: [ -> ]Just as a curiosity, you know that re-installing Openelec would likely take less than an hour to accomplish and have a booting system back right? If you can't connect from your location, surely you can just create and send him a sources.xml and easily walk him through scp'ing the file over? Just seems like you are spending an inordinate amount of time trying to salvage something that is more easily built from scratch...
It wouldn't really be that simple as I'd have to get xTV-SAF installed and setup again, go through all the settings with him to make sure they're OK (I was just looking at his guisettings.xml and noticed it has
<audiodevice default="true">PI:HDMI</audiodevice> even though he can only use analog output and it's working OK), then there's all the keymaps and lirc stuff, addons like iplayer, streaming radio, scrapers that would need to be reinstalled.
I just tried copying my cache/SSH files to his SD card but that just made things worse and it's gone back to not connecting at all with putty or WinSCP now, not even showing any attempt or error.
I'm ashamed to admit that it turns out his PC is actually 192.168.1.69, so that is correct. I could have sworn I checked it the other day but obviously I was tired and got confused.
Anyway, he says it's been running OK since yesterday, so the crashing appears to have stopped for whatever reason. He'd added his sources via the GUI but as SMB, so I edited his sources.xml on the PC to add them as NFS sources and he says they're all showing now, so I told him to delete the SMB ones once he's checked the NFS ones are working OK.
I've made an image of the SD card now so that I can restore that if it goes funny again but I do still need to get the SSH working so that I can tweak things if necessary without him having to keep removing the SD card, which risks damaging the slot, so if anyone can tell me how to do that, I'd be very grateful.
So, can anyone tell me how to fix the SSH access? Everything else seems to be working OK now according to my brother, so I don't really want to have to wipe the SD card and start from scratch just to fix this issue.
OK, I'll see if anyone at the OE forum knows.