1

(Edit: leaving the original question for background; skip down to below the divider if you aren't interested.)

My residence recently experienced a power outage. Unfortunately, as I was out at the time, I was not able to cleanly shut down my system before the UPS ran out of battery.

My Linux machine seems fine, but my FreeBSD (12.1) machine won't boot. Instead of a login prompt, it drops me straight into an unprivaleged shell that won't even let me su.

I have inspected both the tty boot messages (as best I can, given that they scroll away) as well as /var/log/messages, but the only potential indications of a problem are:

  • An angry beep (lower and slightly longer than the POST beep)
  • An error message about "MSI-X tables"
  • / is mounted read-only

I've manually run fsck (booting in single-user mode seems to work okay, except the system isn't really usable like that) is clean. I'm running a zpool scrub on the storage array (the OS is on UFS, but this box is essentially a NAS) but don't anticipate any errors. Other than some open sshfs connections, the system would not have been doing anything at the time it lost power.

Other notes:

  • The system was originally installed as FreeBSD 12.0, and it's quite possible it has never been booted since upgrading.
  • The root FS mounts and "looks" intact. (Read: I ran ls on a couple directories and expected files seem to be present.
  • I've installed some stuff from ports (mostly GNU CLI tools), but AFAIK no kmods or anything like that. The system is a fairly basic budget AMD+APU.
  • It appears that all physical keypresses are being recorded in /var/log/messages?

What could be wrong?

Edit: Well... I'm sort of an idiot, although this is still a WTF? situation. However, I'm now less certain the machine hasn't been doing this since installation; now that I realize what's happening, I think I've seen this before, so it probably has nothing to do with the power loss. (Did I mention it doesn't get rebooted often?)

I finally noticed something funny about the shell I was getting dumped in. Can you spot it? Here's the last few lines after boot:

Updating motd:. Mounting late filesystems:. Security policy loaded: MAC/ntpd (mac_ntpd) Starting ntpd. [ntpd@<redacted> /]$ █

...and that's it; no login, no errors, no network, just the completely nerfed command prompt shown above.

So why the heck is it doing this? (Hint: ^D "fixes" it, as you might expect if you've noticed what's wrong, but why does it do this? I'd like my system to boot up without needing its hand held! I suspect this also means I have a non-working daemon 😢.)

Improve this question
4
  • Usually you can press scroll lock and then page up/down to inspect all the messages. FreeBSD does not drop to emergency shell without a proper hint what's going on. Commented Feb 8, 2020 at 21:50
  • @MartinSugioarto, "does not drop to emergency shell without a proper hint", want to bet? 😉 Okay, well, the hint is subtle, and it's technically not an emergency shell... I sort of figured out what's going on. Stay tuned for an update. (BTW, thanks for the scroll-lock tip!) Commented Feb 9, 2020 at 2:21
  • 2
    It looks weird. Did you change the ntpd startup script or used weird parameters? It looks like somewhere an interactive shell is started with ntpd as user. Commented Feb 9, 2020 at 7:18
  • Right, I finally figured out the second part. As for the first, not to my knowledge. The only thing I can think of that might be weird is that I have a bunch of BSD programs path-replaced with GNU equivalents. Commented Feb 9, 2020 at 15:41

2 Answers 2

Reset to default
0

There are various ways to achieve this, but one of the simplest is to botch the ntpd_flags setting in /etc/rc.conf and effectively perform a command injection attack upon onesself.

This is why rc systems based upon shell script are so hard to get right. It is very difficult to thoroughly defend against all of the ways in which extra shell commands can be (accidentally) injected, especially when printf lacks a %q format specifier.

FreeBSD's Mewburn rc scripts have not been defensively coded against such accidents pretty much at all. Notice that a ntpd_config filename won't work if it contains whitespace, for example. That's a fairly trivial piece of quoting compared to some.

And yes, this is not an emergency shell.

Improve this answer
2
  • The only ntdp-related thing in /etc/rc.conf is ntpd_enable="YES"... AFAIK, I haven't done anything whatsoever to fiddle with the config. Commented Feb 9, 2020 at 15:46
  • The problem is in this command: limits -C daemon su -m ntpd -c 'sh -c "/usr/sbin/ntpd -p /var/db/ntp/ntpd.pid -c /etc/ntp.conf -f /var/db/ntp/ntpd.drift"'. Same effect running that at a shell. Doesn't look obviously fishy; any guesses? Commented Feb 9, 2020 at 15:49
-1

Ah, esoterica (also, things I loathe about BSD).

The default shell on FreeBSD is (t?)csh. I hate [t]csh. So, I stuck a line in .cshrc to exec to bash instead.

Problem: now any shell run "as" root (n.b. su -m) is incapable of accepting a command argument; it will just exec (an interactive!) bash instead.

Solution: exec bash in .login (which is apparently csh-specific) instead.

Improve this answer
2
  • 1
    You should have read about the command chsh and also why never change the root shell to anything else than sh. Please use an unprivileged user for optional shells. Commented Feb 9, 2020 at 17:00
  • 1
    And if you still insist on have a super user (root) with a different shell then do it for the toor user. It still has uid 0 and can then keep root clean. Commented Feb 9, 2020 at 21:05

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.