group.of.nepali.translators team mailing list archive

[Steve Langasek <steve.langasek@xxxxxxxxxxxxx>]

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 नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
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 <gpiccoli@xxxxxxxxxx> - 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 <gpiccoli@xxxxxxxxxx> -
  2016-08-19 10:09:51 ==

  
  == Comment: #9 - Guilherme Guaglianoni Piccoli <gpiccoli@xxxxxxxxxx> - 2016-08-19 10:10:31 ==

  
  == Comment: #10 - Guilherme Guaglianoni Piccoli <gpiccoli@xxxxxxxxxx> - 2016-08-19 10:11:49 ==

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/1615021/+subscriptions