Headless diagnosis of faulty Raspbian

After an upgrade and reboot, my Pi (running Raspbian) shows activity
(the lights come on) but the router to which it is wired no longer
recognises it. I have no suitable standalone monitor and have to
diagnose it by reading the memory card in my laptop.
The latest logs in /var/log are from the last shutdown before the
problem arose and show nothing wrong.
Is there anything else which might give some clue as to why the network
no longer comes up?
And if I have to reformat the card and reinstall everything, is it
possible to find the cron data to copy over?
Reply to
Hils
Loading thread data ...
These questions sort of both have the same answer.
/var/spool/cron/crontabs contains, well, crontabs. So you can copy those out.
But you can also put stuff _in_ -- for example, in root's crontab,
@reboot /sbin/ifconfig -a >/root/ifconfig.log
then fire up the pi, shut it down again, and see what you've got.
Reply to
Roger Bell_West
Normally it would first light the red LED, then the yellow LED should come up for some time (flashing a bit) and after a couple of seconds the three other LEDs will start coming up. Does it still act that way, or are only the red and yellow LEDs doing something?
My experience with upgrading on recent versions of Raspbmc was that it easily corrupted the boot partition, writing incomplete files. This was caused by the online update procedure. In that case it would stop dead before it activated the network. However this procedure is added by Raspbmc, and is not used by Raspbian (which uses apt-get etc). It was easy to fix this problem by just copying the boot partition from another card that still booted (the files on the boot partition can be copied on any PC)
When the 3 network LEDs do come up
The cron schedules can live in a number of places, dending on how you added them:
/var/spool/cron/crontabs/ /etc/cron.*/
When you put the card in a system that can read the Linux partition you can copy those files, at least the ones you added yourself, to the PC and copy them back after the reloading of the card.
Reply to
Rob
Not even a TV? Crap picture but might get you out of a hole.
--
Regards 
Dave Saville
Reply to
Dave Saville
The LEDs light up as you describe, including the ACT LED, which flashes for a while before going out. I've wired the Pi to my laptop's ethernet port and the laptop can't find anything to connect to either.
It's looking rather ominous that it seems to get a long way into the boot process without writing anything to the card. I've often thought I could do with a second Pi, I might have to get one now. :-(
Ah, thanks. All of my cron entries are explicitly timed so everything I need is in /var/spool/cron/crontabs/hils
Reply to
Hils
That in fact is quite normal. In default configuration it would look for a DHCP server to get an address. When you connect it to your home network that includes a NAT router, it will get an address from there. When you connect it point-to-point to a user system, there will be no DHCP server and it cannot get an address. (it should continue to use the last address it got from the router at least for a while, though)
When it gets as far as bringing up the network interface, you should look in /var/log for the file that has been modified last. There should be some info in there.
Reply to
Rob
With the Pi and the PC connected to your router or a switch so they can talk, try running Wireshark on the PC. That may tell you something: Wireshark should display all the traffic on the subnet.
--
martin@   | Martin Gregorie 
gregorie. | Essex, UK 
 Click to see the full signature
Reply to
Martin Gregorie
What about the serial connection?
formatting link
Reply to
Stefan Enzinger
I've splashed out on a new memory card, dd'd a pristine new Raspbian onto it and tried to boot it. The same sequence described earlier happens, with no new messages in /var/logs. It looks as though the Pi has lost its ability to write data to the card. There's nothing visibly amiss with the card socket. Bummer.
The USB-TTL console cable looks as though it could be a useful addition to my toolbox, I'll get one with the next Pi. (Thanks to Stefan Enzinger for that suggestion.)
Reply to
Hils

i would like to comment that in such a situation I would try quite hard to find a way to get a screen display going. The pi has a composite video output, and even if your TV doesn't have composite video inputs, a video recorder usually does. Connecting to the recorder, and selecting the appropriate AV source as input should let you see whether the pi is producing any output.
Anything produced during this process would probably help with diagnosis.
--
Alan Adams, from Northamptonshire 
alan@adamshome.org.uk 
 Click to see the full signature
Reply to
Alan Adams
It's sometimes present on a SCART even if there's no yellow socket on the TV - a simple adapter
formatting link
provides one.
Reply to
Rob Morley
There are various composite/HDMI -> VGA/HDMI etc. converter gizmos, generally dongle-sized, available from various places including Hong Kong.
Useful, I find.
--
Windmill, TiltNot@NoneHome.com       Use  t m i l l 
J.R.R. Tolkien:-                            @ S c o t s h o m e . c o m 
 Click to see the full signature
Reply to
Windmill
I stopped watching broadcast TV several years ago. I've occasionally contemplated getting an additional monitor but I get by with a laptop with virtual desktops.
By way of an update, I seem to have brought the Pi back to life by removing a reference in /etc/fstab to a HDD which is no longer connected (and whose failure may have caused the initial failure). I now wonder if the Pi might have eventually got over the failed mount and reached the stage of writing to the card, had I waited long enough, though I gave it several minutes on one occasion and it still remained frozen. I have a recollection from tinkering with Linux some years back of unpredictable behaviour if devices such as HDDs disappear.
The bad news is that I bought a second Pi and memory card on the way to this point. The good news is that I now have two Pis. :-)
The TTL-USB serial cable is a marvellous tool for diagnosis and hacking, though its connection to the Pi's GPIO pins needs some care.
Reply to
Hils
less unpredictable than undocumented.
Mount tends to hang the boot process if it cant find a drive..unless its 'soft mounted' or some such.
I do know that the only thing that absolutely crashes this machine here is if NFS mounted stuff vanishes.
It rarely does happen though.
--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
 Click to see the full signature
Reply to
The Natural Philosopher
On Fri, 29 Nov 2013 11:41:16 +0000, Hils declaimed the following:
Does that mean you've now come full circle?
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
For a Friday, that is actually passably good.
Now register the trademark for a twin processor PI.
--
Ineptocracy 

(in-ep-toc?-ra-cy) ? a system of government where the least capable to  
 Click to see the full signature
Reply to
The Natural Philosopher
On Fri, 29 Nov 2013 16:44:38 +0000, The Natural Philosopher declaimed the following:
Wouldn't that be a PI*R^2 for short?
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
Why? Where does the radius squared suddenly come from? It'd be a Raspberry Tau shirley :)
Reply to
Guesser
On Sat, 30 Nov 2013 09:52:53 GMT, Alan Adams declaimed the following:
Yes, and my subsequent post was in response to the concept of a dual core (though it really would word better with a quad core for the ^2)
--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
    wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/
Reply to
Dennis Lee Bieber
OK, if you're prepared to go 'down' there, let's do as 'below'.
Serial has got a whole lot of its own requirement. In the thread 'Unreliable boot behaviour' there are good leads to * switch on 'ACT' LED * pulse 'ACT' LED * send via 'ACT' LED * do something with the display...
I've proposed that we have access to these tiny byte-string-testers, without even bothering with the tool-chain -- initially.
We just need to:
# mv knl.imgBak # dd if=AcTest1 of=
Where AcTest1, as described above is merely the hex-bytes of: -> set the relevant port-line to output-mode -> set the relevant 1 or 0 to the relevant mem: port-line -> Branch -1: infinite-loop to avoid running into further-code
Power-off and dd:restore the when done.
We need to collaborate in building tools, rather than just solving short term individual problems.
PS. the Cambridge university article cited in the other thread is an over-the-top tutorial for scholars.
Reply to
Unknown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.