violagirl23
Posts: 7
Joined: Tue Sep 24, 2013 5:47 pm

How to ensure SSH ALWAYS available?

Tue Sep 24, 2013 6:26 pm

First, a little background: I am using the newest Raspbian and booting my Pi from a USB drive (per the extended procedure in this tutorial: http://www.raspberrypi.org/phpBB3/viewt ... 29&t=44177) and I also have a 4T self-powered Seagate external hard drive that I share over the network that automatically mounts at boot. I have myself automatically logged into tty1 on boot-up so I can run completely headless (per this tutorial: http://raspisimon.no-ip.org/rpi_autologin.php) and just SSH into the machine when necessary.

Originally I had my flash drive and a powered USB hub plugged directly into the Pi, and then my hard drive plugged into the USB hub, so that I would have extra USB ports available should I need to plug in a keyboard for any reason. However, I finally realized the hub was causing problems, and I was having problems similar to this post: http://www.raspberrypi.org/phpBB3/viewt ... 9&p=373974 and I would get messages like this on boot-up (device number 6 refers to my external hard drive):

Code: Select all

[    3.655985] usb 1-1.2.1: new high-speed USB device number 6 using dwc_otg
[   42.456535] sd 1:0:0:0: [sdb] 976754645 4096-byte logical blocks: (4.00 TB/3.63 TiB)
[   42.469645] sd 1:0:0:0: [sdb] Attached SCSI disk
[   77.345887] usb 1-1.2.1: reset high-speed USB device number 6 using dwc_otg
[  115.346084] usb 1-1.2.1: reset high-speed USB device number 6 using dwc_otg
[  146.306013] usb 1-1.2.1: reset high-speed USB device number 6 using dwc_otg
[  177.345978] usb 1-1.2.1: reset high-speed USB device number 6 using dwc_otg
[  208.305948] usb 1-1.2.1: reset high-speed USB device number 6 using dwc_otg
[  210.581991] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
Sometimes it would just keep resetting the device on reboot and the hard drive wouldn't register at all and thus would fail the boot-time file system check, and I would get booted into a maintenance shell. When this happened, SSH would be unavailable so I would have to plug a keyboard into the hub to safely reboot the Pi. (It would say something along the lines of "A maintenence shell will now be started. After performing system maintenance, please CONTROL-D to terminate the maintenance shell and restart the system. ...".)

Now that I've realized this is the hub's fault, I'm plugging my hard drive directly into the Pi and everything is working. This is fine, since I want to run it headless anyway, but I have a question: is there any way to ensure that even if I get dumped back into that maintenance shell again for any reason that SSH is available? Because if the Pi ends up dumping me into a maintenance shell again I won't be able to SSH into the machine, but without the hub I have no extra USB ports, and without any way to plug in a keyboard I won't be able to shut the Pi down safely. I would have to either unplug my hard drive without unmounting it to free up a USB port for my keyboard, or just pull the plug on the Pi itself, neither of which is good for either the Pi or my hard drive. Is there any settings I can modify, either in fstab or elsewhere, to ensure that no matter what I will always have SSH available to me as long as my LAN is functioning, especially even if my hard drive fails the fsck for any reason (since it's just storage anyway, it's not a huge deal if it can't mount at boot for some reason, though I'd still like it to do so automatically if possible).

This is my current fstab for reference:

Code: Select all

proc             /proc  proc  defaults          0 0
/dev/mmcblk0p1   /boot  vfat  defaults          0 2
#/dev/mmcblk0p2  /      ext4  defaults,noatime  0 1
/dev/disk/by-uuid/3bcc8e11-359e-4e5b-b028-c530a201f0db / ext4 defaults,noatime 0 0
/dev/disk/by-uuid/930b3cae-d060-4ff3-923b-4c918885bb00 /media/USBHDD1 ext4 defaults,noatime 0 2
The UUID mounting at / is my flash drive, and the UUID mounting at /media/USBHDD1 is my external hard drive. The commented-out /dev/mmcblk0p2 refers to my SD card, which I am no longer booting from.

confuseling
Posts: 144
Joined: Mon Aug 26, 2013 1:41 pm

Re: How to ensure SSH ALWAYS available?

Wed Sep 25, 2013 2:17 am

Take this with a pinch of salt, I'm not an expert.

If you're in the maintenance shell, you're in single user mode, and the file systems aren't mounted read / write yet.

https://wiki.debian.org/BootProcess
http://www.debian.org/doc/manuals/debia ... ian_system

Hence it should be safe to pull the power.

I guess it might work if you added networking and ssh to runlevel s, but it also might well not. And it might refuse to boot at all, or do something really weird. If you're in the mood for experimenting, sysv-rc-conf is the easiest way to do that. And it's not my fault, whatever happens :-)

Personally, I'd just keep backups (which you should be doing anyway) and pull the plug if it doesn't boot.
http://forums.debian.net

User avatar
jojopi
Posts: 3085
Joined: Tue Oct 11, 2011 8:38 pm

Re: How to ensure SSH ALWAYS available?

Wed Sep 25, 2013 5:39 am

violagirl23 wrote:I have myself automatically logged into tty1 on boot-up so I can run completely headless (per this tutorial: http://raspisimon.no-ip.org/rpi_autologin.php) and just SSH into the machine when necessary.
If the machine is headless then it is a waste of memory to have anyone logged in on tty1, which you cannot see.
This is my current fstab for reference:

Code: Select all

proc             /proc  proc  defaults          0 0
/dev/mmcblk0p1   /boot  vfat  defaults          0 2
#/dev/mmcblk0p2  /      ext4  defaults,noatime  0 1
/dev/disk/by-uuid/3bcc8e11-359e-4e5b-b028-c530a201f0db / ext4 defaults,noatime 0 0
/dev/disk/by-uuid/930b3cae-d060-4ff3-923b-4c918885bb00 /media/USBHDD1 ext4 defaults,noatime 0 2
The last field on each line is the fsck pass number. This should normally be 0 for virtual filesystems, 1 for /, and 2 for all other filesystems mounted at boot.

You should correct the pass number for / to 1. You may want to change the pass number for your storage drive to 0. This will prevent fsck from examining it automatically. The system should boot acceptably even if it is absent, read-only, or has uncorrected errors. You may occasionally need to umount and fsck it manually over ssh (which will be awkward if any processes that start automatically are accessing it).

If it is not absolutely required at boot, I would be tempted to put "noauto" in its options field. Then you can fsck and mount it manually, or in the script that starts whatever processes access its contents.

violagirl23
Posts: 7
Joined: Tue Sep 24, 2013 5:47 pm

Re: How to ensure SSH ALWAYS available?

Thu Sep 26, 2013 6:48 pm

jojopi wrote:If the machine is headless then it is a waste of memory to have anyone logged in on tty1, which you cannot see.
For some reason I thought that in order to use the machine via SSH you needed someone logged into tty1. I'm glad to know otherwise!
jojopi wrote:The last field on each line is the fsck pass number. This should normally be 0 for virtual filesystems, 1 for /, and 2 for all other filesystems mounted at boot.

You should correct the pass number for / to 1. You may want to change the pass number for your storage drive to 0. This will prevent fsck from examining it automatically. The system should boot acceptably even if it is absent, read-only, or has uncorrected errors. You may occasionally need to umount and fsck it manually over ssh (which will be awkward if any processes that start automatically are accessing it).

If it is not absolutely required at boot, I would be tempted to put "noauto" in its options field. Then you can fsck and mount it manually, or in the script that starts whatever processes access its contents.
Thanks for the advice about the pass number on /. I just followed the tutorial verbatim and assumed they set the pass number to 0 for a reason. In case it was just an error, I commented on their post to alert them of this so they can fix their tutorial if need be.

I corrected the pass number for my external HDD to 0. I'll have to think about if I want to put "noauto" in the options field; it's just so nice that when I have my Pi shut down and plug it in, that my drive will automatically be available over the network without me needing to SSH in and mount it.
confuseling wrote:If you're in the maintenance shell, you're in single user mode, and the file systems aren't mounted read / write yet. Hence it should be safe to pull the power.

I guess it might work if you added networking and ssh to runlevel s, but it also might well not. And it might refuse to boot at all, or do something really weird. If you're in the mood for experimenting, sysv-rc-conf is the easiest way to do that. And it's not my fault, whatever happens :-)

Personally, I'd just keep backups (which you should be doing anyway) and pull the plug if it doesn't boot.
Thanks for that; you're right, it'd probably just be easiest to pull the plug, especially if the risk of data corruption would be relatively low.

Return to “Raspbian”