Serial Console stuck at Bootup Complete after factory reset
Journer last edited by
I have an RCC-VE-4860 running 2.3.4-RELEASE (2017-05-04; not the p1 latest release).
After performing a factory reset, the serial console gets stuck at "bootup complete" and does not display the pfsense menu.
I went through these threads and a couple other places looking for solutions. While I did find some useful info, I was unable to resolve the issue. The purpose of this thread is to try and shed some more light to see if the root cause can be uncovered, or at least provide folks in the future with some more info.
The problem in my case appeared to be the /etc/ttys file is reset and ttyu0 is set to "no"
So I tired this:
That's why you're not getting a console menu. No gettys spawned.
You can try this:
Boot single user (console boot menu option 2)
mount -a -t ufs
mv /etc/ttys /root/ttys.old
tar xv -C / -f /usr/local/share/pfSense/base.txz ./etc/ttys
As always, be ready to reinstall and restore when you do this sort of thing.
Not sure why /etc/ttys falls victim to this but it also appears to be related to unclean shutdowns. I have not seen any other files that do this but I am not sure if I would trust it and might just reinstall/restore since it only takes a couple of minutes and you're rebooting anyway.
The first problem I encountered was I could not mount the volume because it had "no been shutdown properly". So I ran fsck and then was able to mount it.
However, the fix there did not work.
I then tried the same thing, except instead of restoring from the base.txz, I just edited /etc/ttys and manually set ttyu0 to yes. However, every time I rebooted back into single user mode, the file was back to its original state (without my edits), so this fix did not work either.
In the end, I gave up and just re-installed from scratch - problem resolved of course :)
Some questions though:
- Is there something special that needs to be done to ensure the changes to files made in single user mode get permanently written to disk? I suspect if I could have figured this out, it would have worked.
- Is there a bug in the way the factory reset works that sets ttyu0 to "no"? I suspect this is the actual problem here given that the setting in the base.txz is "no"…
No, that procedure works. You might have been experiencing some extra-special fs corruption.