Debian User Forums

I've been using Debian for a couple of years now and it was its stability that fixed me to its usage and makes me to recommend it to whoever is think on trying some distro. This is my first post.

THE ISSUE: Recently I've "updated" the Win7 that came in my machine to Win10 and yesterday I came across a pretty annoying situation: I powered up my PC, selected Debian, the kernel started loading the modules, all OK, and suddenly I'm prompted with "Welcome to Emergency Mode"! Welcome?!? Hahahahah! I even laughed of being welcomed to such a situation. Anyway, I'll cut short the story: I've got the hunch it would be something about fstab (guessing from the logs). I've commented out the lines related with my NTFS partition and rebooted. Everything worked fine. The real reason is that Win10 uses FastBoot by default, and by shutdown it flags the partition as "locked". I've decided to disable fastboot because I mostly don't use windows, but that's not even my issue.

The reason why I'm posting is because I think we should get the system to enter in emergency mode just because it couldn't mount some partition that is listed in fstab. Maybe it should be considered to future releases, or is there any strong reason to enter in emergency in such situation?

Regards,
JCBastos Portela

Rather than commenting out the line, you could instead add the "nofail" option.

See systemd.mount(5)

Just to note: the systemd developers consider this to be a feature rather than a bug -- the system administrator should *always* be aware of failing mount points.

Head_on_a_Stick wrote:Rather than commenting out the line, you could instead add the "nofail" option.

Hum... Didn't think about it! That's a good point! I'm gonna try it when I get back home.

Head_on_a_Stick wrote:Just to note: the systemd developers consider this to be a feature rather than a bug -- the system administrator should *always* be aware of failing mount points.

I didn't refer to it as a bug... I called it issue, but it isn't even that. For me is just an annoying characteristic.

Thank you for your tip!

I had the exact same thing happen to me 2 days ago!

Really annoying. It took quite some time, before I found out what the problem was, because I am still not very familiar with systemd..

I think, that the system shouldn't refuse to boot if some non-essential partition (=non-system-partition) fails to mount.
Before systemd, debian did boot when the same thing happened.
Booting just took much much longer, because it tried to do the mount many times, before giving up and finally booting the system.

aplistir wrote:I think, that the system shouldn't refuse to boot if some non-essential partition (=non-system-partition) fails to mount.

So how is a "non-system-partition" defined?
How should the mount process tell the difference?

Maye with some type of "this one isn't important" parameter like 'nofail'?

If the filesystems *explicitly* defined in fstab fail, the system should not carry on as if nothing is wrong - with the potential for service failures, data loss, and spewing data into an empty mountpoint on the host filesystem.

dilberts_left_nut wrote: Maye with some type of "this one isn't important" parameter like 'nofail'?

Yeah... It was my bad! The worst is that I knew about the usage of "nofail". It is exactly the way of saying: "this partition is secondary, so don't Emergency on me!!".

Thanks all for the comments, but in the end I've to admit that my point doesn't make much of sense. It was my fault while setting up the partition in fstab.

To be fair, this was a behavioural change between booting with sysvinit and systemd (which got me with an old swap in my fstab on first boot too ) but I do think it is a sensible behaviour.

Marking as SOLVED