2

I dropped a new script into /etc/init.d, and used update-rc.d to install it into the other rc#.d subdirectories. Unfortunately I made two stupid mistakes:

  • The script runs a long-running command (netcat), but I forgot to put & after it
  • The script got installed early in the boot order (S10).

And now I can't ssh in. I think the problem is that my script is blocking the boot (since I forgot &), so the rc script that starts sshd never runs.

But I'm stuck, because ssh is normally the only way I have of logging in to this board. I've tried connecting a USB keyboard and an HDMI monitor, but I never get anything on the display and can't log in. I think this board may have been configured to not even try to drive the display.

Anybody have any suggestions? Options that I can think of are:

  1. Re-image the board. (I don't want to do that.)
  2. Use an FTDI serial cable. (I don't have that cable, but I've ordered one from Digi-Key.)
  3. Mount the board as a USB filesystem on another machine, and remove the offending symlinks from /etc/rcS.d/. (This doesn't seem to work; I suspect this board is not configured for OTG.)
  4. Get the board to boot into single-user mode, bypassing rc scripts like mine. (Not at all sure how to do this, though.)

Anybody have any other suggestions? Anybody know if logging in over FTDI is likely to work, even though the boot hasn't completed?

2
  • I'm not sure how this is an Ubuntu question... – Thomas Ward Jul 7 '17 at 21:31
  • @ThomasWard At this point it's a u-boot question, but possibly specific to the way Ubuntu has set up u-boot. – Steve Summit Jul 7 '17 at 21:39
1

Answering my own question: Yes, the FTDI serial cable works, to access things like the bootloader and (potentially) single-user mode.

(In my case, just connecting with the FTDI cable wasn't sufficient to fix my bad rc script, because my bad rc script was so bad that it was running even on the path into single-user mode, so it was keeping me from getting into single-user mode. Fortunately I was able to view, and destroy, the offending file from u-boot itself, which fixed the problem, and now the system is booting again. And I will never, ever make this mistake again.)

2
  • There are two modes, emergency and rescue mode. The former should have been capable of this even when the latter is not. – JdeBP Jul 8 '17 at 9:27
  • @JdeBP Thanks for the tip. Will check that out next time. – Steve Summit Jul 10 '17 at 13:09
-2

If you can not wait for option 2, choose option 1

3
  • This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post. - From Review – Anthon Jul 7 '17 at 22:02
  • it does: you have no option if you can neither reach it with connected hardware nor via net. – Jaleks Jul 7 '17 at 22:16
  • @Jaleks I think the complaint was that you didn't tell me anything I didn't know. (But no worries.) – Steve Summit Jul 7 '17 at 23:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.