4 ms·

As far as I can see, they all mention "fsck.mode=force, as a kernel parameter", which is what I was complaining about.

by esaym 11y ago

kbenson 11y ago
Here's the TL;DR 1) It's actually super easy to get to a read-only root mode. 2) It actually is a problem of carrying over obsolete conventions from prior init systems. 3) It's not your fault because systemd has extremely poor documentation on this AFAICT, to the point that people searching for this problem can't even get answers from others that know how to do it, or at least those answers don't rate very high. 4) Just boot with kernel param "emergency" instead of "single" (or "rescue" which is an alias for "single") and you will get a single user mode with root already mounted read-only for you. And now for the longer rambling version. Okay, so I spent a little time on this since I happen to have a virt for Fedora 20, and I finally found a couple of solutions that work. First, the systemd solution, which is emergency mode. It's correct that the journal will cause problems here, but that's because the journal was already running and apparently systemd doesn't want to, or is unable to stop it. The solution is to reboot into emergency mode. This can be accomplished by using the kernel param "systemd.unit=emergency.target", or just the param "emergency". This will not only boot you into a single user mode, but will default to having root mounted read-only. To clarify, this appears to be a new mode in addition to single user mode. Single user mode can still be reached with the kernel param "single" or "rescue" or "systemd.unit=rescue.target". I finally stumbled on this when I decided to look at the directions for what I wanted to accomplish for the distro I was using[1] and not for systemd specifically. Which makes sense, but I think we are all to stuck on "systemd is different, how do I do this in systemd" rather than "how does my distro say I should accomplish this now, given the changes they've instituted." 1: https://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/ap-rescuemode.html#s1-rescuemode-booting-emergency https://docs.fedoraproject.org/en-US/Fedora/18/html/Installa...
- JdeBP 11y ago
  2) It actually is a problem of carrying over obsolete conventions from prior init systems. It actually is not. It's a problem of not knowing the conventions from prior init systems. emergency mode did not originate with systemd. It has been around since 1995-12-03 (Miquel van Smoorenburg's System 5 init clone, version 2.57d).
  - kbenson 11y ago
    It was possible to boot to single user mode and remount root as read-only prior to systemd, Whether this was the optimal method for achieving this is irrelevant, it was possible, and popular. That specific method no longer works easily as before, while the optimal method does. The commentor was using their preferred (if suboptimal) convention from the prior init system and running into problems. I think that perfectly matches the statement "It actually is a problem of carrying over obsolete conventions from prior init systems." It is also a case of not knowing the correct/optimal prior convention, but that doesn't make the original statement untrue.

As far as I can see, they all mention "fsck.mode=force, as a kernel parameter", which is what I was complaining about.

by esaym 11y ago

As far as I can see, they all mention "fsck.mode=force, as a kernel parameter", which is what I was complaining about.

Here's the TL;DR 1) It's actually super easy to get to a read-only root mode. 2) It actually is a problem of carrying over obsolete conventions from prior init systems. 3) It's not your fault because systemd has extremely poor documentation on this AFAICT, to the point that people searching for this problem can't even get answers from others that know how to do it, or at least those answers don't rate very high. 4) Just boot with kernel param "emergency" instead of "single" (or "rescue" which is an alias for "single") and you will get a single user mode with root already mounted read-only for you. And now for the longer rambling version. Okay, so I spent a little time on this since I happen to have a virt for Fedora 20, and I finally found a couple of solutions that work. First, the systemd solution, which is emergency mode. It's correct that the journal will cause problems here, but that's because the journal was already running and apparently systemd doesn't want to, or is unable to stop it. The solution is to reboot into emergency mode. This can be accomplished by using the kernel param "systemd.unit=emergency.target", or just the param "emergency". This will not only boot you into a single user mode, but will default to having root mounted read-only. To clarify, this appears to be a new mode in addition to single user mode. Single user mode can still be reached with the kernel param "single" or "rescue" or "systemd.unit=rescue.target". I finally stumbled on this when I decided to look at the directions for what I wanted to accomplish for the distro I was using[1] and not for systemd specifically. Which makes sense, but I think we are all to stuck on "systemd is different, how do I do this in systemd" rather than "how does my distro say I should accomplish this now, given the changes they've instituted." 1: https://docs.fedoraproject.org/en-US/Fedora/18/html/Installation_Guide/ap-rescuemode.html#s1-rescuemode-booting-emergency https://docs.fedoraproject.org/en-US/Fedora/18/html/Installa...

JdeBP 11y ago
2) It actually is a problem of carrying over obsolete conventions from prior init systems. It actually is not. It's a problem of not knowing the conventions from prior init systems. emergency mode did not originate with systemd. It has been around since 1995-12-03 (Miquel van Smoorenburg's System 5 init clone, version 2.57d).
- kbenson 11y ago
  It was possible to boot to single user mode and remount root as read-only prior to systemd, Whether this was the optimal method for achieving this is irrelevant, it was possible, and popular. That specific method no longer works easily as before, while the optimal method does. The commentor was using their preferred (if suboptimal) convention from the prior init system and running into problems. I think that perfectly matches the statement "It actually is a problem of carrying over obsolete conventions from prior init systems." It is also a case of not knowing the correct/optimal prior convention, but that doesn't make the original statement untrue.