systemd fails to provide a proper rescue prompt

[pgreening]

I'm not really sure how this happened. My machine failed to boot because of a minor error running fsck on /var. As expected, systemd asked for the root password and dropped me to a prompt. From here, I attempted to fsck /var, and failed! It was already mounted. Further investigation revealed that not only was /var mounted despite failing fsck, and mounted read-write, but the system had actually continued past the mounting of file systems and had started rpc.statd, which was now holding a file open on /var. I had to stop rpc.statd and unmount /var in order to fsck it. This behavior is seriously troublesome for two reasons:

• If the file system has errors to the point that systemd invokes the user to correct the situation, it should not be mounted read-write until after the system admin can fsck it.
• If the file system in question, or any file system on the machine is unable to start up, proceeding to export said file systems over NFS should be avoided until the system is restored to proper health.

[pgreening]

I believe this is due to the documented behavior of local-fs.target failing to properly handle passno numbers in fstab. According to the documentation:
In addition, it adds dependencies of type Wants= to this target unit for those mounts listed in /etc/fstab that have the auto mount option set.

When in fact the dependencies should be added of type Requires= if the passno field for that fstab entry is non-zero.

[poettering]

Could you please provide us with a the verbose logs of this case, to figure out what is going on here? Or at least the precise error from fsck you got?

Normally, all mounts that are not listed "nofail" in fstab should cause boot to stop when they cannot be fsck'ed or mounted.

[poettering]

Closing due to lack of response.

[pgreening]

lack of response from who?

On 11/02/2015 11:51 AM, Lennart Poettering wrote:

Closing due to lack of response.

—
Reply to this email directly or view it on GitHub
#1205 (comment).

[pgreening]

unfortunately i am unable to generate any logs regarding this issue because:
the issue occurred in single-user mode - no logs were saved
sysD has been violently removed from all my machines due to poor
reliability and support issues. I have reverted to sys V. no further
assistance will be provided from me.

On 11/02/2015 11:51 AM, Lennart Poettering wrote:

Closing due to lack of response.

—
Reply to this email directly or view it on GitHub
#1205 (comment).