I can reproduce this on multiple units - including a Pi 2 and a Pi 3. I'm using a clean install of "2016-05-27-raspbian-jessie-lite.img" (just re-rested with "2017-04-10-raspbian-jessie-lite.img") - and can reproduce without any updates, as well as with all updates applied.
I was / still am suspecting a systemd-related issue here. I've tried repeating the same with both Debian Jessie and CentOS 7 within VirtualBox, and have not been able to reproduce - so this appears to be Raspbian-specific.
Can anyone else at least reproduce the following?
- Use of a Raspberry Pi 2 or 3 Model B, using the May 2016 or later version of Raspbian Jessie Lite.
- The serial console enabled and connected, as per http://elinux.org/RPi_Serial_Connection. Note that the Pi 3 requires adding enable_uart=1 at the end of /boot/config.txt.
- Using a separate SSH or tty0 (keyboard/monitor) console, validate that any or all of the following complete successfully and immediately:
Code: Select all
/sbin/agetty --keep-baud 115200 38400 9600 ttyS0 vt102
- Using the serial console (ttyS0):
- Log-in and out ("exit") repeatedly, observing no changes in the above.
- Log-in, then issue the "reset" command. Observe still no changes in system status / operation.
- "exit". Observe that the command hangs indefinitely and never returns.
- Using a separate SSH or tty0 console (still open from above), attempt to repeat any of the above systemctl status commands. Observe that all queries to systemctl now fail after timing out:
Also observe that any new login attempts also time out.
Code: Select all
[email protected]:~ $ systemctl status --no-pager Failed to read server status: Connection timed out [email protected]:~ $ systemctl --no-pager Failed to list units: Connection timed out [email protected]:~ $ systemctl status [email protected] Failed to get properties: Connection timed out
Why is this happening, and how can this be fixed? Sure, I could just refrain from running reset from a serial console - but I don't see any reason why this should be causing a problem, and it is rather disastrous to the system when executed (as demonstrated above). I'm not exactly sure what the next debugging steps would be for this, but will certainly provide any additional outputs or test results that may be requested.