group.of.nepali.translators team mailing list archive

[Launchpad Bug Tracker <1615021@xxxxxxxxxxxxxxxxxx>]

This bug was fixed in the package systemd - 231-5

---------------
systemd (231-5) unstable; urgency=medium

  [ Iain Lane ]
  * Let graphical-session-pre.target be manually started (LP: #1615341)

  [ Felipe Sateler ]
  * Add basic version of git-cherry-pick
  * Replace Revert-units-add-a-basic-SystemCallFilter-3471.patch with upstream
    patch
  * sysv-generator: better error reporting. (Closes: #830257)

  [ Martin Pitt ]
  * 73-usb-net-by-mac.rules: Test for disabling 80-net-setup-link.rules more
    efficiently. Stop calling readlink at all and just test if
    /etc/udev/rules.d/80-net-setup-link.rules exists -- a common way to
    disable an udev rule is to just "touch" it in /etc/udev/rule.d/ (i. e.
    empty file), and if the rule is customized we cannot really predict anyway
    if the user wants MAC-based USB net names or not. (LP: #1615021)
  * Ship kernel-install (Closes: #744301)
  * Add debian/extra/kernel-install.d/60-initrd.install.
    This kernel-install drop-in copies the initrd of the selected kernel to
    the EFI partition.
  * bootctl: Automatically detect ESP partition.
    This makes bootctl work with Debian's /boot/efi/ mountpoint without having
    to explicitly specify --path.
    Patches cherry-picked from upstream master.
  * systemd.NEWS: Point out that alternatively rcS scripts can be moved to
    rc[2-5]. Thanks to Petter Reinholdtsen for the suggestion!

  [ Michael Biebl ]
  * Enable iptables support (Closes: #787480)
  * Revert "logind: really handle *KeyIgnoreInhibited options in logind.conf"
    The special 'key handling' inhibitors should always work regardless of
    any *IgnoreInhibited settings – otherwise they're nearly useless.
    Update man pages to clarify that *KeyIgnoreInhibited only apply to a
    subset of locks (Closes: #834148)

 -- Martin Pitt <mpitt@xxxxxxxxxx>  Fri, 26 Aug 2016 10:58:07 +0200

** Changed in: systemd (Ubuntu Yakkety)
       Status: Fix Committed => Fix Released

-- 
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 Released
Status in debian-installer package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Fix Released
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:
  In Progress
Status in busybox source package in Yakkety:
  Fix Released
Status in debian-installer source package in Yakkety:
  Triaged
Status in systemd source package in Yakkety:
  Fix Released

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

  
  SRU INFORMATION for systemd
  ===========================

  Test case:
   * Check what happens for uevents on devices which are not USB network interfaces:
     udevadm test /sys/devices/virtual/mem/null
     udevadm test /sys/class/net/lo

   With the current version these will run

    PROGRAM '/bin/readlink /etc/udev/rules.d/80-net-setup-link.rules'
  /lib/udev/rules.d/73-usb-net-by-mac.rules:6

   which is pointless. With the proposed version these should be gone.

   * Ensure that the rule still works as intended by connecting an USB
  network device that has a permanent MAC address (e. g. Android
  tethering uses a temporary MAC): You should get a MAC-based name like
  "enx12345678" for it. Now disconnect it again, disable ifnames with

      sudo ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules

  and reconnect the device. You should now get a kernel name like "usb0"
  for it.

  * Regression potential: Errors in the rule could break persistent
  naming - or its disabling - of USB network interfaces. Running the
  above test carefully is important to ensure this keeps working. This
  has little to no actual effect on anything else on the system (aside
  from a performance impact and spamming logs), so overall the
  regression potential is low.

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