What changes needed to run netbsd headless?

mpadilla2

What I'm trying to do is get netbsd configured on my odroidc1+ and then run it headless. I'll ssh in for any administration. Everything went great from the initial flashing to sdcard to booting with serial connection. I can ssh into the device fine.

The problem arises when I disconnect my serial connection and restart the device. I can no longer connect over ssh. The device no longer responds to pings. I've tried multiple hard restarts without serial connection.

So I reviewed rc.conf and saw that wscons is set in such a way to check for a display to set the boolean value either to YES or NO based on if the display is indeed there. So it seems that if serial is not connected wscons gets NO. I commented that out and just set wscons=YES thinking this would resolve it but it didn't.

I'm not sure if I'm going down the right path so I thought I'd pop in and ask for direction. I've done a lot of searching and reading of documentation but cannot seem to locate the correct information.

Am I on the right path? Am I missing something? What changes do I need to make to run headless? Any help/guidance would be greatly appreciated!

rvp

mpadilla2 Have you tried putting back the console=fb in boot.ini?

JuvenalUrbino

Stupid question: is sshd enabled? What does the client return? What's in /var/log/authlog?

mpadilla2

Ssh works fine as long I first boot while serial is connected and then disconnect serial and ssh in. It is enabled in rc.conf. /var/log/authlog shows sshd listening on port 22 and my various different logins to ssh.

This of course being from how i boot the device while physically connected over serial then disconnect, it remains up to be able to ssh in. If I were to restart the device while NOT physically connected over serial nothing responds, not even ping. To me (novice in bsd) it seems as though the boot is not completing when not physically connected to serial.

Thank you so much for helping me out!

Let me restart it without serial and see if ssh -vvv outputs anything useful in the client.

kfmut

mpadilla2 Every startup is logged to /var/log/messages

mpadilla2 physically connected over serial

Just curious what does that means in odroid context?

mpadilla2

"no route to host" when restarted without serial. This is in keeping with ping not responding either.

mpadilla2

Another interesting thing to note is that I also have a rpi3 and I do not see this behavior. I am able to boot without a physical serial connection and then am able to ssh in.

mpadilla2

console=fb has to be removed for serial connection. Here's the link for connecting over uart: https://wiki.odroid.com/odroid-c1/application_note/gpio/uart

The logs don't show anything out of the ordinary besides a delayed boot due to me waiting and then finally connecting uart. Basically the boot waits until there is a physical connection to uart and then continues. If I never connect the wires to uart, 9.1 never finishes booting.

Anyway, I am able to get netbsd 8.2 to boot without physical connection to uart by:

removing console=fb from boot.ini and cmdline.txt
adding softcar to the console line in /etc/ttys

There was a change from 8.2 to 9.1 where ttys defaults to constty instead of console. rc.conf is also different from 8.2 to 9.1 in terms of wscons. I just cannot seem to get the correct settings in netbsd 9.1 so that I can boot without a physical connection to uart.

Anyway, at this point I've been fighting with this for a while now and decided just to keep 8.2. 8.2 works flawlessly, rebooting without a physical connection to uart with just a couple of config changes.

If someone here has some insight into 9.1, can you please share why the config changes I noted above that work for 8.2 won't work for 9.1? I'm happy to hear them and try the suggestions out.

rvp

mpadilla2 Anyway, I am able to get netbsd 8.2 to boot without physical connection to uart

I have to ask: this isn't caused by the bootloader or the OS waiting at for a key at a menu or prompt or something, right? Because, if that isn't it, then its a regression and you should report it on the port-arm mailing list.