Comment 14 for bug 1755863

I keep doing some experiments (with Dell/HP laptops) and there are some conclusions currently:

1. why does the issue happen (not real root cause)
Due to local-fs.target, the fstab-generator automatically adds dependencies of type Before= to all mount units that refer to local mount points for this target unit. 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[1].
Therefore, the emergency shell is triggered by local-fs.target which is dependent on failures of several systemd mounts.

2. provides 2 approaches for workaround fix

1) append "systemd.mask=dev-hugepages.mount systemd.mask=dev-mqueue.mount systemd.mask=sys-fs-fuse-connections.mount systemd.mask=sys-kernel-config.mount systemd.mask=sys-kernel-debug.mount systemd.mask=tmp.mount" into kernel boot options.

2) add "toram" into kernel boot options.
it would completely decompress the filesystem into RAM, which requires 3-4x more RAM, and is hence undesired[2].

3. trade-off between workarounds
Until we find the solution, the better way to workaround is to use "toram" to fix the issue. The reason behind it is we not only get speed-up the installation but also avoid the unstable network with nfs, despite requiring more RAM.

4. The real solution concern
I think the solution may be more complicated if we really want to fix, and ideally we have to consider the cases of normal (e.g. from usb stick) and nfs mount to satisfy the conditions to avoid systemd failure with dependencies or protocol.

[1] https://www.freedesktop.org/software/systemd/man/systemd.special.html
[2] https://wiki.ubuntu.com/BootToRAM