I've thought about this some more, and while the /bin/readlink /usr/bin/readlink in busybox is a bug, fixing this is definitely not going to fix the problem in the installer. In the installer, /etc/udev/rules.d/80-net-setup-link.rules will never exist since this is an admin override; so the readlink command - if it existed - would still return false. I'm reasonably sure the lack of /bin/readlink is not causing the udev rule to behave differently; so it's sufficient to fix this particular issue for 16.10 and later and not SRU it.
What is *more* of an issue is that the structure of /lib/udev/rules.d/73 -usb-net-by-mac.rules causes a separate call out to readlink for every single udev event, because the readlink check happens *before* checking the ACTION/SUBSYSTEM/SUBSYSTEMS attributes of the event, unless net.ifnames=0 is set. So regardless of whether this is the root cause of the install failure, this udev rule is causing hundreds of thousands of extra calls out to /bin/readlink on boot, which should definitely be fixed by reordering these checks. Martin, can you please look into fixing this for xenial+yakkety? ** Changed in: systemd (Ubuntu) Status: New => Triaged ** Changed in: systemd (Ubuntu) Assignee: (unassigned) => Martin Pitt (pitti) ** Also affects: debian-installer (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: busybox (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: debian-installer (Ubuntu Yakkety) Importance: Undecided Assignee: Taco Screen team (taco-screen-team) Status: Confirmed ** Also affects: busybox (Ubuntu Yakkety) Importance: Undecided Status: New ** Also affects: systemd (Ubuntu Yakkety) Importance: Undecided Assignee: Martin Pitt (pitti) Status: Triaged ** Changed in: busybox (Ubuntu Xenial) Status: New => Won't Fix ** Changed in: busybox (Ubuntu Yakkety) Status: New => Fix Committed ** Changed in: debian-installer (Ubuntu Xenial) Status: New => Triaged ** Changed in: debian-installer (Ubuntu Yakkety) Status: Confirmed => Triaged ** Changed in: systemd (Ubuntu Xenial) Status: New => Triaged ** Changed in: systemd (Ubuntu Xenial) Assignee: (unassigned) => Martin Pitt (pitti) -- 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/1615021 Title: Unable to network boot Ubuntu 16.04 installer normally on Briggs Status in busybox package in Ubuntu: Fix Committed Status in debian-installer package in Ubuntu: Triaged Status in systemd package in Ubuntu: Triaged Status in busybox source package in Xenial: Won't Fix Status in debian-installer source package in Xenial: Triaged Status in systemd source package in Xenial: Triaged Status in busybox source package in Yakkety: Fix Committed Status in debian-installer source package in Yakkety: Triaged Status in systemd source package in Yakkety: Triaged Bug description: == Comment: #7 - Guilherme Guaglianoni Piccoli <gpicc...@br.ibm.com> - 2016-08-19 10:08:07 == The normal procedure to perform a Netboot installation of Ubuntu 16.04 is to download the latest vmlinux and initrd.gz files available, and kexec them with no parameters (at least in ppc64el). We're experiencing a strange issue in which the installer freezes before menus are showed. The system hangs in the point specified below, right after the i40e driver initialization: [ 11.052832] i40e 0002:01:00.0 enP2p1s0f0: renamed from eth0 [ 11.073976] i40e 0002:01:00.1 enP2p1s0f1: renamed from eth1 [ 11.117799] i40e 0002:01:00.2 enP2p1s0f2: renamed from eth2 [ 11.225745] i40e 0002:01:00.3 enP2p1s0f3: renamed from eth3 ***HANG*** The most difficult part in this issue is that it seems to be a timing issue/race condition, and many debug trials end up by avoiding the issue reproduction (heisenbug). We were successful though in getting logs by booting the kernel with the command-line "BOOT_DEBUG=2" and by changing the initrd in order to enable systemd debug; only the files "init" and "start-udev" were changed in initrd, both attached here. We've attached here a saved screen session that shows the entire boot process until it gets flooded with lots of messages like: "starting '/bin/readlink /etc/udev/rules.d/80-net-setup-link.rules' '/bin/readlink /etc/udev/rules.d/80-net-setup-link.rules'(err) 'failed to execute '/bin/readlink' '/bin/readlink /etc/ udev/rules.d/80-net-setup-link.rules': No such file or directory' seq 3244 queued, 'add' 'pci_bus' starting '/bin/readlink /etc/udev/rules.d/80-net-setup-link.rules' passed 408 byte device to netlink monitor 0x1003cfe8020seq 3236 running'/bin/readlink /etc/udev/rules.d/80-net-setup-l ink.rules'(err) 'failed to execute '/bin/readlink' '/bin/readlink /etc/udev/rules.d/80-net-setup-link.rules': No such file or directory' '/bin/readlink /etc/udev/rules.d/80-net-setup-link.rules'(err) 'failed to execute '/bin/readlink' '/bin/readlink /etc/ udev/rules.d/80-net-setup-link.rules': No such file or directory' Process '/bin/readlink /etc/udev/rules.d/80-net-setup-link.rules' failed with exit code 2. PROGRAM '/bin/readlink /etc/udev/rules.d/80-net-setup-link.rules' /lib/udev/rules.d/73-usb-net-by-mac.rules:6 passed device to netlink monitor 0x1003d01f730 " Then it keeps hanged in this stage. We re-tested it by changing the file 73-usb-net-by-mac.rules in initrd, replacing " /etc/udev/rules.d/80-net-setup-link.rules" to "/lib/udev/rules.d/80-net-setup-link.rules", since the former does not exist whereas the latter does. Same issue were observed! Notice that if we boot the installer with command-line "net.ifnames=0" or "net.ifnames=1", the problem does not reproduces anymore. We want to ask Canonical's help in investigating this issue. Thanks, Guilherme == Comment: #8 - Guilherme Guaglianoni Piccoli <gpicc...@br.ibm.com> - 2016-08-19 10:09:51 == == Comment: #9 - Guilherme Guaglianoni Piccoli <gpicc...@br.ibm.com> - 2016-08-19 10:10:31 == == Comment: #10 - Guilherme Guaglianoni Piccoli <gpicc...@br.ibm.com> - 2016-08-19 10:11:49 == To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1615021/+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