[Touch-packages] [Bug 1765765] Re: on nfsboot 18.04 bionic, internet addresses arn't resolve properly
@Guillermo The OS shouldn't be trying to raise the interface as it's already configured during the boot process. You can't reconfigure the network interface while you're booting from the network :) You need to modify /etc/network/interfaces on your boot server to set the interface to manual. See step 5 under 'creating your NFS installation' on this page https://help.ubuntu.com/community/DisklessUbuntuHowto Related to this, I also set 'net.ifnames=0' in the kernel boot line so the network devices are always named ethX rather than hardware-specific names. That's personal preference though. @beta-tester Strange. Without specifying 'ip=dhcp' perhaps it was sometimes getting a bootp or rarp response without a DNS server settings? Just a guess. If 'ip=X' isn't set, it defaults to any autoconfig protocol. I'd suggest setting the ip option specifically to dhcp if that's what you expect it to use. https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1765765 Title: on nfsboot 18.04 bionic, internet addresses arn't resolve properly Status in systemd package in Ubuntu: Confirmed Bug description: since ubuntu 17.10, 18.04, when i nfsboot into ubuntu live an internet address isn't resolved properly. i always have to put a dns server to the /etc/resolv.conf file by hand to get address resolving to work again. it wasn't an issue in ubuntu 16.04 and not an issue in ubuntu 17.04. it began to be an issue starting with ubuntu 17.10 and ist still an issue now 18.04 daily-live. the different between /etc/resolv.conf of ubuntu <=17.04 and utuntu >=17.10 is, that now only one entry is in the resolv.conf file with IP 127.0.0.53 in the erlier version there was an additional entry on top with the IP of the local DNS server(router). when i nfsboot ubuntu 18.04, adjust the /etc/resolv.conf file by hand to get internet address resolving to work, when i then install ubuntu 18.04 from that environment to the local harddrive, the networksettings on the newly installed local harddisk is always setted up to "manual" IP in the /etc/network/interfaces - so it will not get a proper IP from the router. after a new installation, i always have to set it up "dhcp" to get the IP from the router as usual. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1765765/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
So I've found a complete work-around for this. I also found that this issue is NOT new in 18.04 as it also affects 16.x (and likely 15 and 17 too). However it is DIFFERENT in 18.04. More details below. TL;DR: You need to netboot with an initramfs that doesn't have 'scripts/casper-bottom/25disable_cdrom.mount' in it. This script masks the dynamically-generated cdrom.mount systemd unit (where the NFS mount goes). That causes all the issues described in this bug. >From whatever machine where netboot initramfs is created: # Disable/block the problem script mkdir -p /etc/initramfs-tools/scripts/casper-bottom touch /etc/initramfs-tools/scripts/casper-bottom/25disable_cdrom.mount # rebuild initramfs update-initramfs -u # Move/copy the new file to the netboot server The issue here is that systemd isn't able to update its mount status properly. In the case of 18.04, all of the 'failed' mounts are actually successfully mounted. This includes /tmp. BUT systemd doesn't recognize that fact and marks them all as red/failed. In 16.04 this issue is a bit different. When booting, all of the same mounts are again mounted successfully AND systemd shows them all as green/active. BUT if you try to stop/unmount any of them you will see a similar situation. The unmount will actually succeed, but systemd will report an unmount failure and continue to show the unit as green/active. Per the call trace thh noted in comment #21: >From what I can tell, mount_load_proc_self_mountinfo iterates through every >active mount on the system (some perhaps more than once). When it gets to the >nfs-mount on /cdrom, it does fail in unit_set_slice and generate the "Failed >to set up mount unit: Device or resource busy" error. For whatever reason, >that failure seems to completely bork systemd's ability to update its mount >status. Thus mounts get 'stuck' either mounted or not from systemd's >perspective. The failure seems to be caused by the fact that the cdrom.mount unit (NFS mount) is masked. Once it's unmasked the failure doesn't occur and all mounts work as expected. You can actually observe this from within a 'broken' boot at the emergency prompt: rm /lib/systemd/system/cdrom.mount systemctl daemon-reload umount /tmp (ensure it's gone, there may be multiple mounts) systemctl reset-failed tmp.mount systemctl start tmp.mount ..and it will succeed I did verify this issue by actually booting from a 'real' DVD and the problem doesn't happen there. It's something specific to having the image mounted over NFS and masking it's unit. For reference, the disable_cdrom.mount script was the solution for this bug https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1436715 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in casper package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Daemon' dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Metadata' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") fuse: device not found, try 'modprobe fuse' first dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Metadata' (gvfsd-metadata:580): GUdev-CRITICAL **: 16:28:56.270: g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed (gvfsd-metadata:580): GUdev-CRITICAL **: 16:28:56.270: g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed A connection to the bus can't be made done. Begin: Setting up init... ... done. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1755863/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1755863] Re: netbooting the bionic live CD over NFS goes straight to maintenance mode :
Eric, The 'recommendation' for masking dev-hugepages you site from that wiki page is clearly just an example of how you could disable one of the various mounts described there. I don't think it's a recommendation to fix anything in particular. FWIW: Masking dev-hugepages doesn't seem to help much for me. Masking tmp seems to let the system boot up, but still the other mount services fail and systemd status is red 'degraded.' I've ended up masking all affected mounts (per comment 12 and 14) with the addition of masking run-rpc_pipefs.mount too. This lets the systemd boot up to green 'running' state. I'm still having problems logging into Gnome with a user with NFS home. I'm not sure if that's related to this issue or something else though. Still looking at that. I think you're on the right track in comment 27. I get the feeling that somewhere along the line a result of 'this is already mounted' changed from a success to a failure in systemd, possibly due to the change in mount.c you pasted. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1755863 Title: netbooting the bionic live CD over NFS goes straight to maintenance mode : Status in casper package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Confirmed Bug description: netbooting the bionic live CD[1] over NFS goes straight to maintenance mode : [1] http://cdimage.ubuntu.com/daily-live/current/ # casper.log Begin: Adding live session user... ... dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Daemon' dbus-daemon[568]: [session uid=999 pid=568] Activating service name='org.gtk.vfs.Metadata' requested by ':1.0' (uid=999 pid=569 comm="" label="unconfined") fuse: device not found, try 'modprobe fuse' first dbus-daemon[568]: [session uid=999 pid=568] Successfully activated service 'org.gtk.vfs.Metadata' (gvfsd-metadata:580): GUdev-CRITICAL **: 16:28:56.270: g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed (gvfsd-metadata:580): GUdev-CRITICAL **: 16:28:56.270: g_udev_device_has_property: assertion 'G_UDEV_IS_DEVICE (device)' failed A connection to the bus can't be made done. Begin: Setting up init... ... done. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/casper/+bug/1755863/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
