bionic casper nfsboot not reaching desktop env, failure to mount various kernel filesystems and /tmp

Bug #1754777 reported by Taras Prokopenko on 2018-03-09
128
This bug affects 25 people
Affects Status Importance Assigned to Milestone
casper (Ubuntu)
High
Unassigned
systemd (Ubuntu)
Undecided
Unassigned

Bug Description

1st of all, i am successfully using casper netboot with this distros:
  menu label Ubuntu 13.10 "Saucy Salamander" - Release i386
  menu label Ubuntu 14.04.3 LTS "Trusty Tahr" - Beta amd64
  menu label Ubuntu 14.04.4 LTS "Trusty Tahr" - Release amd64
  menu label Ubuntu 16.04.3 LTS "Xenial Xerus" - Release i386
but not with
  menu label Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64

boot process gets to the point of running this services
  dev-hugepages.mount
  dev-mqueue.mount
  sys-fs-fuse-connections.mount
  sys-kernel-config.mount
  sys-kernel-debug.mount
  tmp.mount

and it stops in emergency console.

Too run further to gnome session i've need to do

#systemctl mask dev-hugepages.mount
#systemctl mask dev-mqueue.mount
#systemctl mask sys-fs-fuse-connections.mount
#systemctl mask sys-kernel-config.mount
#systemctl mask sys-kernel-debug.mount
#systemctl mask tmp.mount
#ctrl-d

after this i get normal live session except wrong dns setting, which is fixed by setting my router's
dns as resolver
#echo "nameserver 192.168.1.1" > /etc/resolv.conf

Please fix boot process.

Eric Desrochers (slashd) on 2018-03-20
Changed in casper (Ubuntu):
importance: Undecided → High
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in casper (Ubuntu):
status: New → Confirmed

i have the same issue #1754828
thank you for the temporary workaround

you wrote:
"after this i get normal live session except wrong dns setting, which is fixed by setting my router's
dns as resolver
#echo "nameserver 192.168.1.1" > /etc/resolv.conf"

the issue with resolv.conf i have since ubuntu 17.10, when i nfsboot the live system. ubuntu 17.04 was the last version, where internet addresses were resolved out-of-the-box.

is that already reported somewhere?
or is there a fix in the queue?

Jay (mysticjayubone2018) wrote :

Yes, confirmed - happens to me as well.

Maxime Besson (mabes) wrote :

Also affected, I was able to get the system to boot by adding systemd.mask=tmp.mount to the kernel command line, but I have no DNS once the desktop environment boots, and shutdown hangs

Jeff Sereno (jsereno) wrote :

Same issue here. Using a combo of the OP's and mabes' info, I was able to successfully PXE boot using the following kernel line:

kernel path/to/tftp/bionic/vmlinuz 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

I was unable to use just systemd.mask=tmp.mount alone as suggested by mabes.

To get DNS going, I just changed the nameserver IP in /etc/resolv.conf to 8.8.8.8 and I was good (I also have this particular issue under 17.10 when PXE booted).

Shutdown (and reboot) does NOT hang in my case.

1. for pxe/nfs boot, there is stated, that there is a fix released, but i guess it will released in the first point release 18.04.1.
see
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1755863
"netbooting the bionic live CD over NFS goes straight to maintenance mode"

2. for the resolve issue i opened a separate bug report, but there is no activity yet...
see
https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1765765
"on nfsboot 18.04 bionic, internet addresses arn't resolve properly"

3. yes, with option "systemd.mask=tmp" i am able to boot successfully into ubuntu desktop.
4. yes, when i shutdown or try to reboot, ubuntu hangs for ever.

oops...
3. should be "systemd.mask=tmp.mount"

oh nooo…
to 1. "Fix Released" was ticked by misstake. it is still not fixed.

Woodrow Shen (woodrow-shen) wrote :

I can confirm that the ubiquity can finish the installation via appending the string of systemd mask services "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" and enter normal Gnome session with user after reboot.

Lukas (lukas-wringer) wrote :

still no fix or assignee for this? Not working as of today,

possible duplicate addition to this: #1755863 still open and unassigned as well.

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in systemd (Ubuntu):
status: New → Confirmed
Fabian C (fcolmegna) on 2018-09-22
Changed in systemd (Ubuntu):
status: Confirmed → Fix Released
Fabian C (fcolmegna) wrote :

sorry, by mistake I put the tick "fix released" and I can not put it back in "confirmed".

Marcel Partap (empee584) wrote :

ok this seems to be caused by the tmp.mount unit, that is generated from /etc/fstab. Mounting a tmpfs over /tmp will make existing files inaccessible, so it has to be done as early as possible, i.e. `Before=basic.target`. It has to occur reliable before live-config.service invokes, so `WantedBy=live-config.service`. And the construct is activated by a symlink `/etc/systemd/system/live-config.service.wants/tmp.mount -> /etc/systemd/system/tmp.mount`.. that's my solution for now. : )

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers