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

Bug #1754777 reported by Taras Prokopenko
128
This bug affects 25 people
Affects Status Importance Assigned to Milestone
casper (Ubuntu)
Confirmed
High
Unassigned
systemd (Ubuntu)
Fix Released
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)
Changed in casper (Ubuntu):
importance: Undecided → High
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in casper (Ubuntu):
status: New → Confirmed
Revision history for this message
beta-tester (alpha-beta-release) wrote :

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

Revision history for this message
beta-tester (alpha-beta-release) wrote :

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?

Revision history for this message
Jay (mysticjayubone2018) wrote :

Yes, confirmed - happens to me as well.

Revision history for this message
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

Revision history for this message
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.

Revision history for this message
beta-tester (alpha-beta-release) wrote :

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.

Revision history for this message
beta-tester (alpha-beta-release) wrote :

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

Revision history for this message
beta-tester (alpha-beta-release) wrote :

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

Revision history for this message
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.

Revision history for this message
Woodrow Shen (woodrow-shen) wrote :
Revision history for this message
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.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
Fabian C (fcolmegna)
Changed in systemd (Ubuntu):
status: Confirmed → Fix Released
Revision history for this message
Fabian C (fcolmegna) wrote :

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

Revision history for this message
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  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.