[Touch-packages] [Bug 1794909] Re: Memory corruption in RAR decoder

[Daniel Axtens]

Hi Seth,

I've pushed them to https://github.com/libarchive/libarchive/pull/1105

Thanks for walking me through the Ubuntu process.

Regards,
Daniel

** Information type changed from Private Security to Public Security

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libarchive in Ubuntu.
https://bugs.launchpad.net/bugs/1794909

Title:
  Memory corruption in RAR decoder

Status in libarchive package in Ubuntu:
  New

Bug description:
  Hi,

  There are some crashes and memory corruption issues in
  libarchive's RAR decoder. Most notably, I have observed some
  double-frees and heap use-after-frees, both reading and writing. These
  have not been detected by previous fuzzing runs because of the CRC
  checks in the RAR parser.

  The memory corruption seems to arise in ppmd7 decoding. The code can
  be made to read and write addresses that are at least partially
  attacker controlled, but the decoder is complex and I don't have the
  time to investigate fully whether the level of control is sufficient
  to lead to code execution. My gut feeling is that someone more skilled
  than I could cause arbitrary code execution, but I cannot say for
  certain.

  This bug can be used to crash bsdtar and other programs that use
  libarchive, such as file-roller.

  I have attached some test cases that demonstrate this.

  They run as follows:
  xxd -r testcase.rar.txt testcase.rar
  bsdtar -Oxf testcase.rar

  The test cases are:

   - oob-read.txt - Ppmd7_DecodeSymbol does an out-of-bounds read and
 crashes. (No UAF.)

   - uaf-read.txt - this heap UAF causes an out-of-bounds read in
 Ppmd7_DecodeSymbol and crashes.

   - double-free.txt - this test case causes a double-free

   - uaf-rw.txt - this shows reads and writes into a previously freed
 heap region.

  I've tested all of these on the version of bsdtar that ships with
  Ubuntu 18.04 Bionic and also with a build of libarchive from git. My
  analysis of their behaviour comes from running them under valgrind and
  ASAN. If you have any trouble reproducing them let me know.

  The crashes were found with afl-fuzz and the FairFuzz extension.

  I've also reported this to the OSS-Fuzz contacts for the upstream
  project.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1794909/+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 1794909] Re: Memory corruption in RAR decoder

[Daniel Axtens]

Here's a test case for the NULL pointer dereference in ACL handling.

** Attachment added: "aclcrasher.txt"
   
https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1794909/+attachment/5221005/+files/aclcrasher.txt

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libarchive in Ubuntu.
https://bugs.launchpad.net/bugs/1794909

Title:
  Memory corruption in RAR decoder

Status in libarchive package in Ubuntu:
  New

Bug description:
  Hi,

  There are some crashes and memory corruption issues in
  libarchive's RAR decoder. Most notably, I have observed some
  double-frees and heap use-after-frees, both reading and writing. These
  have not been detected by previous fuzzing runs because of the CRC
  checks in the RAR parser.

  The memory corruption seems to arise in ppmd7 decoding. The code can
  be made to read and write addresses that are at least partially
  attacker controlled, but the decoder is complex and I don't have the
  time to investigate fully whether the level of control is sufficient
  to lead to code execution. My gut feeling is that someone more skilled
  than I could cause arbitrary code execution, but I cannot say for
  certain.

  This bug can be used to crash bsdtar and other programs that use
  libarchive, such as file-roller.

  I have attached some test cases that demonstrate this.

  They run as follows:
  xxd -r testcase.rar.txt testcase.rar
  bsdtar -Oxf testcase.rar

  The test cases are:

   - oob-read.txt - Ppmd7_DecodeSymbol does an out-of-bounds read and
 crashes. (No UAF.)

   - uaf-read.txt - this heap UAF causes an out-of-bounds read in
 Ppmd7_DecodeSymbol and crashes.

   - double-free.txt - this test case causes a double-free

   - uaf-rw.txt - this shows reads and writes into a previously freed
 heap region.

  I've tested all of these on the version of bsdtar that ships with
  Ubuntu 18.04 Bionic and also with a build of libarchive from git. My
  analysis of their behaviour comes from running them under valgrind and
  ASAN. If you have any trouble reproducing them let me know.

  The crashes were found with afl-fuzz and the FairFuzz extension.

  I've also reported this to the OSS-Fuzz contacts for the upstream
  project.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1794909/+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 1794909] Re: Memory corruption in RAR decoder

[Daniel Axtens]

(as with the other test cases, it's in plain text, convert it back with
xxd -r aclcrasher.txt aclcrasher)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libarchive in Ubuntu.
https://bugs.launchpad.net/bugs/1794909

Title:
  Memory corruption in RAR decoder

Status in libarchive package in Ubuntu:
  New

Bug description:
  Hi,

  There are some crashes and memory corruption issues in
  libarchive's RAR decoder. Most notably, I have observed some
  double-frees and heap use-after-frees, both reading and writing. These
  have not been detected by previous fuzzing runs because of the CRC
  checks in the RAR parser.

  The memory corruption seems to arise in ppmd7 decoding. The code can
  be made to read and write addresses that are at least partially
  attacker controlled, but the decoder is complex and I don't have the
  time to investigate fully whether the level of control is sufficient
  to lead to code execution. My gut feeling is that someone more skilled
  than I could cause arbitrary code execution, but I cannot say for
  certain.

  This bug can be used to crash bsdtar and other programs that use
  libarchive, such as file-roller.

  I have attached some test cases that demonstrate this.

  They run as follows:
  xxd -r testcase.rar.txt testcase.rar
  bsdtar -Oxf testcase.rar

  The test cases are:

   - oob-read.txt - Ppmd7_DecodeSymbol does an out-of-bounds read and
 crashes. (No UAF.)

   - uaf-read.txt - this heap UAF causes an out-of-bounds read in
 Ppmd7_DecodeSymbol and crashes.

   - double-free.txt - this test case causes a double-free

   - uaf-rw.txt - this shows reads and writes into a previously freed
 heap region.

  I've tested all of these on the version of bsdtar that ships with
  Ubuntu 18.04 Bionic and also with a build of libarchive from git. My
  analysis of their behaviour comes from running them under valgrind and
  ASAN. If you have any trouble reproducing them let me know.

  The crashes were found with afl-fuzz and the FairFuzz extension.

  I've also reported this to the OSS-Fuzz contacts for the upstream
  project.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1794909/+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 1794909] Re: Memory corruption in RAR decoder

[Daniel Axtens]

This is the warc infinite loop test case. Unlike the other files, it's
*not* encoded, and I use ./bsdtar -Oxf warcloop.warc to see the looping
behaviour.

** Attachment added: "warcloop.warc"
   
https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1794909/+attachment/5221006/+files/warcloop.warc

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libarchive in Ubuntu.
https://bugs.launchpad.net/bugs/1794909

Title:
  Memory corruption in RAR decoder

Status in libarchive package in Ubuntu:
  New

Bug description:
  Hi,

  There are some crashes and memory corruption issues in
  libarchive's RAR decoder. Most notably, I have observed some
  double-frees and heap use-after-frees, both reading and writing. These
  have not been detected by previous fuzzing runs because of the CRC
  checks in the RAR parser.

  The memory corruption seems to arise in ppmd7 decoding. The code can
  be made to read and write addresses that are at least partially
  attacker controlled, but the decoder is complex and I don't have the
  time to investigate fully whether the level of control is sufficient
  to lead to code execution. My gut feeling is that someone more skilled
  than I could cause arbitrary code execution, but I cannot say for
  certain.

  This bug can be used to crash bsdtar and other programs that use
  libarchive, such as file-roller.

  I have attached some test cases that demonstrate this.

  They run as follows:
  xxd -r testcase.rar.txt testcase.rar
  bsdtar -Oxf testcase.rar

  The test cases are:

   - oob-read.txt - Ppmd7_DecodeSymbol does an out-of-bounds read and
 crashes. (No UAF.)

   - uaf-read.txt - this heap UAF causes an out-of-bounds read in
 Ppmd7_DecodeSymbol and crashes.

   - double-free.txt - this test case causes a double-free

   - uaf-rw.txt - this shows reads and writes into a previously freed
 heap region.

  I've tested all of these on the version of bsdtar that ships with
  Ubuntu 18.04 Bionic and also with a build of libarchive from git. My
  analysis of their behaviour comes from running them under valgrind and
  ASAN. If you have any trouble reproducing them let me know.

  The crashes were found with afl-fuzz and the FairFuzz extension.

  I've also reported this to the OSS-Fuzz contacts for the upstream
  project.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libarchive/+bug/1794909/+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 1812760] [NEW] networkd: [Route] PreferredSource not working in *.network files

[Daniel Axtens]

Public bug reported:

[Impact]

Users cannot create IPv6 routes that specify PreferredSource. This means
that users cannot specify a number of valid IPv6 routes that are useful
in some circumstances. These routes can be created with the 'ip' tool,
just not with systemd.

This was reported upstream in systemd issue #5882 is fixed by pulling in
the changes in systemd PR #11375 -
https://github.com/systemd/systemd/pull/11375

[Test Case]

Start a Bionic or Cosmic VM.

Add the following netplan yaml (adjust for ethernet card and MAC):

network:
version: 2
ethernets:
ens3:
dhcp4: true
match:
macaddress: 52:54:00:e2:c2:d7
set-name: ens3
addresses: ["fd8f:1d7d:b141::2/64", "fd8f:1d7d:b141::200/64"]
routes:
  - to: "a::/16"
via: "fd8f:1d7d:b141::1"
from: "fd8f:1d7d:b141::2"
  - to: "fd8f:1d7d:b141::/64"
scope: link
from: "fd8f:1d7d:b141::2"
metric: 255

Run netplan apply or reboot. Wait ~10s.

Currently, ip -6 route will not include a route to "a::/16", and will
not include the route to "fd8f:1d7d:b141::/64" that has
"fd8f:1d7d:b141::2" as the source address - both those addresses will be
missing.

Correct behaviour is for ip -6 route to report the following:

ubuntu@b-np:~$ ip -6 route
a::/16 via fd8f:1d7d:b141::1 dev ens3 proto static src fd8f:1d7d:b141::2 metric 
1024 pref medium
fd8f:1d7d:b141::/64 dev ens3 proto static src fd8f:1d7d:b141::2 metric 255 pref 
medium
fd8f:1d7d:b141::/64 dev ens3 proto kernel metric 256 pref medium
fe80::/64 dev ens3 proto kernel metric 256 pref medium


[Regression Potential] 

This changes the state machine in systemd which configures the links. It
passes systemd's internal tests, and has been approved by systemd
maintainers, but it remains possible that the changes will break the
configuration of obscure network setups.

The backport requires pulling in two further commits that also change
behaviour: currently systemd deletes all addresses and routes that were
attached to an interface. With this change, it will only delete those
that are not specified in the configuration files. I do not know how
this could cause issues - it moves from a surprising behaviour to a less
surprising behaviour, but it's worth pointing out.

** Affects: systemd (Ubuntu)
 Importance: Undecided
 Assignee: Daniel Axtens (daxtens)
 Status: In Progress

** Changed in: systemd (Ubuntu)
   Status: Confirmed => In Progress

** Changed in: systemd (Ubuntu)
 Assignee: (unassigned) => Daniel Axtens (daxtens)

-- 
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/1812760

Title:
  networkd: [Route] PreferredSource not working in *.network files

Status in systemd package in Ubuntu:
  In Progress

Bug description:
  [Impact]

  Users cannot create IPv6 routes that specify PreferredSource. This
  means that users cannot specify a number of valid IPv6 routes that are
  useful in some circumstances. These routes can be created with the
  'ip' tool, just not with systemd.

  This was reported upstream in systemd issue #5882 is fixed by pulling
  in the changes in systemd PR #11375 -
  https://github.com/systemd/systemd/pull/11375

  [Test Case]

  Start a Bionic or Cosmic VM.

  Add the following netplan yaml (adjust for ethernet card and MAC):

  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:e2:c2:d7
  set-name: ens3
  addresses: ["fd8f:1d7d:b141::2/64", "fd8f:1d7d:b141::200/64"]
  routes:
- to: "a::/16"
  via: "fd8f:1d7d:b141::1"
  from: "fd8f:1d7d:b141::2"
- to: "fd8f:1d7d:b141::/64"
  scope: link
  from: "fd8f:1d7d:b141::2"
  metric: 255

  Run netplan apply or reboot. Wait ~10s.

  Currently, ip -6 route will not include a route to "a::/16", and will
  not include the route to "fd8f:1d7d:b141::/64" that has
  "fd8f:1d7d:b141::2" as the source address - both those addresses will
  be missing.

  Correct behaviour is for ip -6 route to report the following:

  ubuntu@b-np:~$ ip -6 route
  a::/16 via fd8f:1d7d:b141::1 dev ens3 proto static src fd8f:1d7d:b141::2 
metric 1024 pref medium
  fd8f:1d7d:b141::/64 dev ens3 proto static src fd8f:1d7d:b141::2 metric 255 
pref medium
  fd8f:1d7d:b141::/64 dev ens3 proto kernel metric 256 pref medium
  fe80::/64 dev ens3 proto kernel metric 256 pref medium

  
  [R

[Touch-packages] [Bug 1812760] Re: networkd: [Route] PreferredSource not working in *.network files

[Daniel Axtens]

** Tags added: sts

-- 
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/1812760

Title:
  networkd: [Route] PreferredSource not working in *.network files

Status in systemd package in Ubuntu:
  In Progress

Bug description:
  [Impact]

  Users cannot create IPv6 routes that specify PreferredSource. This
  means that users cannot specify a number of valid IPv6 routes that are
  useful in some circumstances. These routes can be created with the
  'ip' tool, just not with systemd.

  This was reported upstream in systemd issue #5882 is fixed by pulling
  in the changes in systemd PR #11375 -
  https://github.com/systemd/systemd/pull/11375

  [Test Case]

  Start a Bionic or Cosmic VM.

  Add the following netplan yaml (adjust for ethernet card and MAC):

  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:e2:c2:d7
  set-name: ens3
  addresses: ["fd8f:1d7d:b141::2/64", "fd8f:1d7d:b141::200/64"]
  routes:
- to: "a::/16"
  via: "fd8f:1d7d:b141::1"
  from: "fd8f:1d7d:b141::2"
- to: "fd8f:1d7d:b141::/64"
  scope: link
  from: "fd8f:1d7d:b141::2"
  metric: 255

  Run netplan apply or reboot. Wait ~10s.

  Currently, ip -6 route will not include a route to "a::/16", and will
  not include the route to "fd8f:1d7d:b141::/64" that has
  "fd8f:1d7d:b141::2" as the source address - both those addresses will
  be missing.

  Correct behaviour is for ip -6 route to report the following:

  ubuntu@b-np:~$ ip -6 route
  a::/16 via fd8f:1d7d:b141::1 dev ens3 proto static src fd8f:1d7d:b141::2 
metric 1024 pref medium
  fd8f:1d7d:b141::/64 dev ens3 proto static src fd8f:1d7d:b141::2 metric 255 
pref medium
  fd8f:1d7d:b141::/64 dev ens3 proto kernel metric 256 pref medium
  fe80::/64 dev ens3 proto kernel metric 256 pref medium

  
  [Regression Potential] 

  This changes the state machine in systemd which configures the links.
  It passes systemd's internal tests, and has been approved by systemd
  maintainers, but it remains possible that the changes will break the
  configuration of obscure network setups.

  The backport requires pulling in two further commits that also change
  behaviour: currently systemd deletes all addresses and routes that
  were attached to an interface. With this change, it will only delete
  those that are not specified in the configuration files. I do not know
  how this could cause issues - it moves from a surprising behaviour to
  a less surprising behaviour, but it's worth pointing out.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1812760/+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

Re: [Touch-packages] [Bug 1746419] Re: bond parameters are not changed by 'netplan apply'

[Daniel Axtens]

Right, so netplan should tell networkd to tear down the bond first?

On Thu, Feb 15, 2018 at 7:06 AM, Dimitri John Ledkov
 wrote:
> I believe this is systemd intentional to not change bond parameters if
> the bond already exists. It is assumed that something else has already
> created the bond, and thus networkd should not be "updating" the params.
> Despite networkd creating the bond in the first place...
>
> ** Changed in: systemd (Ubuntu)
>Status: New => Won't Fix
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1746419
>
> Title:
>   bond parameters are not changed by 'netplan apply'
>
> Status in nplan package in Ubuntu:
>   New
> Status in systemd package in Ubuntu:
>   Won't Fix
>
> Bug description:
>   I have a yaml file as follows:
>
>   network:
>   version: 2
>   ethernets:
>   bonddevs:
>   match:
>   name: ens[78]
>   bonds:
>   bond0:
>   interfaces: [bonddevs]
>   parameters:
>   mode: active-backup
>   mii-monitor-interval: 1
>   addresses:
>   - 10.10.10.1/24
>
>
>   Say I decide that 1s is too frequent for the MII interval, and I want to 
> change the interval to 2s.
>
>   If I change that in the yaml, then run
>   # netplan generate
>   # netplan apply
>   # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
>   MII Polling Interval (ms): 1000
>
>   In other words, the change has not been applied.
>
>   Running netplan --debug apply prints:
>   DEBUG:device bond0 operstate is up, not replugging
>
>   So I wondered if bringing the bond down would help. It does not:
>   # ip link set dev bond0 down
>   # netplan apply
>   # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
>   MII Polling Interval (ms): 1000
>
>   However, deleting the link works:
>   # ip link del dev bond0
>   # netplan apply
>   # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
>   MII Polling Interval (ms): 2000
>
>   This is counter-intuitive behaviour.
>   Ideally, I would like a regular netplan apply to work without deleting the 
> bond.
>   However, a changed to the docs to make this clear would be OK.
>
>   ProblemType: Bug
>   DistroRelease: Ubuntu 17.10
>   Package: nplan 0.32~17.10.1
>   ProcVersionSignature: User Name 4.13.0-32.35-generic 4.13.13
>   Uname: Linux 4.13.0-32-generic x86_64
>   ApportVersion: 2.20.7-0ubuntu3.7
>   Architecture: amd64
>   Date: Wed Jan 31 05:47:42 2018
>   ProcEnviron:
>TERM=xterm-256color
>PATH=(custom, no user)
>XDG_RUNTIME_DIR=
>LANG=C.UTF-8
>SHELL=/bin/bash
>   SourcePackage: nplan
>   UpgradeStatus: No upgrade log present (probably fresh install)
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1746419/+subscriptions

-- 
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/1746419

Title:
  bond parameters are not changed by 'netplan apply'

Status in nplan package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  I have a yaml file as follows:

  network:
  version: 2
  ethernets:
  bonddevs:
  match:
  name: ens[78]
  bonds:
  bond0:
  interfaces: [bonddevs]
  parameters:
  mode: active-backup
  mii-monitor-interval: 1
  addresses:
  - 10.10.10.1/24

  
  Say I decide that 1s is too frequent for the MII interval, and I want to 
change the interval to 2s.

  If I change that in the yaml, then run
  # netplan generate
  # netplan apply
  # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
  MII Polling Interval (ms): 1000

  In other words, the change has not been applied.

  Running netplan --debug apply prints:
  DEBUG:device bond0 operstate is up, not replugging

  So I wondered if bringing the bond down would help. It does not:
  # ip link set dev bond0 down
  # netplan apply
  # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
  MII Polling Interval (ms): 1000

  However, deleting the link works:
  # ip link del dev bond0
  # netplan apply
  # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
  MII Polling Interval (ms): 2000

  This is counter-intuitive behaviour.
  Ideally, I would like a regular netplan apply to work without deleting the 
bond.
  However, a changed to the docs to make this clear would be OK.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: nplan 0.32~17.10.1
  ProcVersionSignature: User Name 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.7
  Architecture: amd64
  Date: Wed Jan 31 05:47:42 2018
  ProcEnviron:
   TERM=xterm-256color
   PATH

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

This is not a full solution. In Xenial this renaming works even if
initramfs has *not* been updated and there is no 70-persistent-net.rules
file in the initial ramdisk. I'm still figuring out why this is, but it
means that even if my patch were applied, there would be a regression in
bionic vs xenial.

Here's a snippet from dmesg showing the same device being renamed twice,
this is a xenial guest. It shows the device going from the kernel name
(eth0) to the udev slot based name (ens16), to the name specified in the
udev rules file that is *not* present in initrd.

ubuntu@xt2:~$ dmesg|grep renamed
[2.428015] virtio_net virtio3 ens16: renamed from eth0
[5.317990] virtio_net virtio3 ens3: renamed from ens16

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud environments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Hi Ryan,

[Journal Output]
Attached.

[Reproducer]
uvt-kvm create xenial-test release=xenial arch=amd64
virsh edit xenial-test # change network interface pci slot: s/0x03/0x10/
virsh destroy xenial-test
virsh start xenial-test
uvt-kvm ssh xenial-test
dmesg|grep rename
[2.790623] virtio_net virtio3 ens16: renamed from eth0
[6.048520] virtio_net virtio3 ens3: renamed from ens16

[Analysis]
I've been working on this a lot, and I think I have the cause of the difference.

In udev-events.c, udev_execute_rules will _forcibly_ rename a device
with via a netlink message if there is a matching rule that sets a name.
Under Xenial, there *is* a matching rule, in 70-persistent-net.rules, so
this forces a rename. This rename will occur even if the device already
has a name, and therefore even if the rules file isn't in the initramfs.

Under Bionic, this rules file doesn't exist, there is a .link file
instead. Unfortunately, a name in a .link file will only take effect if
the device hasn't been renamed - because of the renaming in initrd, this
means that a link file that is not present in the initrd will never be
able to cause a rename.

[Solutions]
There are a couple of ways we could fix this that come to mind:

 - make netplan generate a file in /run/udev/rules.d for each device
 - make systemd rename devices from a link file even if they've been renamed

My preference is the first, but I'm open to anything we can get
upstream.

Thanks again.

Regards,
Daniel

** Attachment added: "journalctl -b output on Xenial VM with multiple renames"
   
https://bugs.launchpad.net/netplan/+bug/1770082/+attachment/5139894/+files/journalctl-b.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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope 

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

> Note, that uvt-kvm is going to use cloud-init; how are you making
> sure that cloud-init isn't doing the rename itself?

I instrumented the kernel. I added a call to dump_stack() in the
function that does interface renaming: dev_change_name() in
net/core/dev.c. That showed that the process that sent the netlink
message was systemd-udevd:

[1.007200] virtio_net virtio3 ens16: renamed from eth0
[1.008453] CPU: 0 PID: 124 Comm: systemd-udevd Not tainted 4.4.59+ #1
[1.009887] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1ubuntu1 04/01/2014
[1.011938]  0286 d38795d9 88001ed3b970 
813f3f63
[1.012435]  88001f2d  88001ed3b9d8 
8170669b
[1.012435]  88001ed3b9c8 88001ed3b9a0 812255af 
30687465
[1.012435] Call Trace:
[1.012435]  [] dump_stack+0x63/0x90
[1.012435]  [] dev_change_name+0x25b/0x2e0


...

[2.336114] virtio_net virtio3 ens3: renamed from ens16
[2.336121] CPU: 0 PID: 454 Comm: systemd-udevd Not tainted 4.4.59+ #1
[2.336122] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1ubuntu1 04/01/2014
[2.336124]  0286 27d63c85 88001c59b970 
813f3f63
[2.336126]  88001f2d  88001c59b9d8 
8170669b
[2.336128]  0001 88001c59b9b0 810b3f1c 
003631736e65
[2.336130] Call Trace:
[2.336135]  [] dump_stack+0x63/0x90
[2.336138]  [] dev_change_name+0x25b/0x2e0


Notice in both cases: "Comm: systemd-udevd". Also notice the change in
PID, suggesting that the first one is in initrd and the second one is
not.

I then grepped the source code for netlink stuff and quickly narrowed in
on rename_if in udev-events.c.

> Xenial by default doesn't use netplan; it still uses eni; the network
> configuration generation in cloud-init using eni
> does create a 70-persistent-net.rules file that handles renames on
> subsequent reboots; in a netplan world (bionic)
> the .link file is meant to be the equivalent of a .rules file.

I am aware of this. (I've hacked on netplan quite a bit.)

The issue is that a .link file does not seem to be functionally
equivalent to a .rules file. I don't know if this difference is
deliberate or an oversight. I will open an issue upstream and ask.

> I've not attempted to determine if systemd-udev in bionic would
> respect renames from .rules file; it certainly seems
> odd to have .rules files allow renames independent of name_assign_type
> value where .link files do.

The end-user tested with a .rules file on Bionic and reported that it
worked. I have also just verified that it does respect renames from a
rules file regardless of name_assign_type. (The codepaths are unchanged
between systemd-229 and systemd-237.)

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp.

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Opened https://github.com/systemd/systemd/issues/9006

** Bug watch added: github.com/systemd/systemd/issues #9006
   https://github.com/systemd/systemd/issues/9006

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud environments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Hi,

This works on reboot but not so well after the system boots.

Say I have the following file:

network:
version: 2
ethernets:
ens7:
dhcp4: true
match:
macaddress: 52:54:00:b4:02:6e
set-name: myif1
optional: true

If I reboot, everything is fine:

ubuntu@netplan2:~$ ip l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3:  mtu 1500 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:d2:9b:b5 brd ff:ff:ff:ff:ff:ff
3: myif1:  mtu 1500 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:b4:02:6e brd ff:ff:ff:ff:ff:ff


But if I now change set-name to myif0, I can't get it to change the name 'live'.

If I apply with the interface 'up', nothing happens, which is fine:

ubuntu@netplan2:~$ sudo netplan apply
ubuntu@netplan2:~$ ip l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3:  mtu 1500 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:d2:9b:b5 brd ff:ff:ff:ff:ff:ff
3: myif1:  mtu 1500 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:b4:02:6e brd ff:ff:ff:ff:ff:ff

But if I bring it down and run netplan apply, the interface is renamed
to ens7, not myif0, and it stays down.

ubuntu@netplan2:~$ sudo ip l set dev myif1 down
ubuntu@netplan2:~$ sudo netplan apply
ubuntu@netplan2:~$ ip l
1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens3:  mtu 1500 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:d2:9b:b5 brd ff:ff:ff:ff:ff:ff
3: ens7:  mtu 1500 qdisc fq_codel state DOWN mode DEFAULT 
group default qlen 1000
link/ether 52:54:00:b4:02:6e brd ff:ff:ff:ff:ff:ff

If I downgrade to 0.36.3, the interface is correctly renamed and brought
up:

9: myif0:  mtu 1500 qdisc fq_codel state UP 
mode DEFAULT group default qlen 1000
link/ether 52:54:00:b4:02:6e brd ff:ff:ff:ff:ff:ff

So not an unqualified success here.

Regards,
Daniel

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Fix Released
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Released
Status in netplan.io source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Systems relying on renaming network interfaces at boot and when 'netplan 
apply' is run.

  [Test case]
  - Write a new netplan YAML (adjusting for current system as necessary):
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: myif0

  - Run 'netplan apply'
  - Verify that the device is correctly renamed to 'myif0'.
  - Reboot.
  - Make sure the device is correctly renamed to 'myif0'.

  [Regression potential]
  Changes in rename logic to add udev rules may otherwise impact applying 
different settings to the network interfaces. Changes in settings on network 
interfaces, missing parameters (especially on bonds, bridges) should be 
investigated as potential regressions. Other failures to apply network settings 
might also happen if there's a race between applying renames via the udev 
rules, and using the new names to apply configuration changes to the interfaces.

  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't chan

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Hi Łukasz,

I couldn't find the package in -proposed, but I was able to download it
from the link.

I verified that a device was not renamed with 0.32~16.04.5 but was
correctly renamed with 0.32~16.04.6, so for Xenial, verification
succeeds.

Regards,
Daniel

** Tags removed: verification-needed-xenial
** Tags added: verification-done-xenial

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Committed

Bug description:
  [Impact]
  Systems relying on renaming network interfaces at boot and when 'netplan 
apply' is run.

  [Test case]
  - Write a new netplan YAML (adjusting for current system as necessary):
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: myif0

  - Run 'netplan apply'
  - Verify that the device is correctly renamed to 'myif0'.
  - Reboot.
  - Make sure the device is correctly renamed to 'myif0'.

  [Regression potential]
  Changes in rename logic to add udev rules may otherwise impact applying 
different settings to the network interfaces. Changes in settings on network 
interfaces, missing parameters (especially on bonds, bridges) should be 
investigated as potential regressions. Other failures to apply network settings 
might also happen if there's a race between applying renames via the udev 
rules, and using the new names to apply configuration changes to the interfaces.

  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are 

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

** Tags removed: verification-failed-bionic
** Tags added: verification-done-bionic

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Committed
Status in netplan.io source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Systems relying on renaming network interfaces at boot and when 'netplan 
apply' is run.

  [Test case]
  - Write a new netplan YAML (adjusting for current system as necessary):
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: myif0

  - Run 'netplan apply'
  - Verify that the device is correctly renamed to 'myif0'.
  - Reboot.
  - Make sure the device is correctly renamed to 'myif0'.

  [Regression potential]
  Changes in rename logic to add udev rules may otherwise impact applying 
different settings to the network interfaces. Changes in settings on network 
interfaces, missing parameters (especially on bonds, bridges) should be 
investigated as potential regressions. Other failures to apply network settings 
might also happen if there's a race between applying renames via the udev 
rules, and using the new names to apply configuration changes to the interfaces.

  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Hi,

I can verify correct behaviour with renaming, static IPs and DHCP with
KVM. I'm about to check some cloud services as well.

Nicorac, are you claiming this is a regression or just an incomplete
fix?

If it's just an incomplete fix, I think we should spin that out into
another bug and fix it after this SRU goes through.

Regards,
Daniel

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Committed
Status in netplan.io source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Systems relying on renaming network interfaces at boot and when 'netplan 
apply' is run.

  [Test case]
  - Write a new netplan YAML (adjusting for current system as necessary):
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: myif0

  - Run 'netplan apply'
  - Verify that the device is correctly renamed to 'myif0'.
  - Reboot.
  - Make sure the device is correctly renamed to 'myif0'.

  [Regression potential]
  Changes in rename logic to add udev rules may otherwise impact applying 
different settings to the network interfaces. Changes in settings on network 
interfaces, missing parameters (especially on bonds, bridges) should be 
investigated as potential regressions. Other failures to apply network settings 
might also happen if there's a race between applying renames via the udev 
rules, and using the new names to apply configuration changes to the interfaces.

  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
   

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Hi,

I have confirmed that the Bionic package works on the cloud service
where the bug was originally observed. With this package, the affected
migrations now succeed.

Regards,
Daniel

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Committed
Status in netplan.io source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Systems relying on renaming network interfaces at boot and when 'netplan 
apply' is run.

  [Test case]
  - Write a new netplan YAML (adjusting for current system as necessary):
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: myif0

  - Run 'netplan apply'
  - Verify that the device is correctly renamed to 'myif0'.
  - Reboot.
  - Make sure the device is correctly renamed to 'myif0'.

  [Regression potential]
  Changes in rename logic to add udev rules may otherwise impact applying 
different settings to the network interfaces. Changes in settings on network 
interfaces, missing parameters (especially on bonds, bridges) should be 
investigated as potential regressions. Other failures to apply network settings 
might also happen if there's a race between applying renames via the udev 
rules, and using the new names to apply configuration changes to the interfaces.

  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priorit

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Hi,

I'm a bit confused then.

This is the netplan config you mentioned:

network:
  version: 2
  renderer: networkd
  ethernets:
id0:
  match:
macaddress: 08:00:27:6b:d8:91
  set-name: eth_static
  addresses: [ 1.2.3.4/16 ]
  gateway4: 5.6.7.8
id1:
  match:
macaddress: 08:00:27:23:68:f5
  set-name: eth_dhcp
  dhcp4: true


With the current version (not the -proposed version), my understanding
is that both devices keep their original names, neither device comes
up at all, and neither device will get an IP, dynamic or static. But
if I understand your comment correctly, you're saying that one of the
devices (the one with mac :f5) comes up and gets a DHCP IP? Is that
right? And if so, what is the device called - eth_dhcp or something
else?

Do you have virtualbox guest additions? I wonder if that's doing
something funky. And just checking you don't have ifupdown installed?

Regards,
Daniel

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Confirmed
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Committed
Status in netplan.io source package in Bionic:
  Fix Committed

Bug description:
  [Impact]
  Systems relying on renaming network interfaces at boot and when 'netplan 
apply' is run.

  [Test case]
  - Write a new netplan YAML (adjusting for current system as necessary):
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: myif0

  - Run 'netplan apply'
  - Verify that the device is correctly renamed to 'myif0'.
  - Reboot.
  - Make sure the device is correctly renamed to 'myif0'.

  [Regression potential]
  Changes in rename logic to add udev rules may otherwise impact applying 
different settings to the network interfaces. Changes in settings on network 
interfaces, missing parameters (especially on bonds, bridges) should be 
investigated as potential regressions. Other failures to apply network settings 
might also happen if there's a race between applying renames via the udev 
rules, and using the new names to apply configuration changes to the interfaces.

  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1

[Touch-packages] [Bug 1619258] Re: netplan should allow NICs to be disconnected and not stall the boot

[Daniel Axtens]

This has been in a released version of netplan.io since 0.32. Are we
right to mark this as Fix Released for nplan? It looks like LP: #1664844
has been marked as Fix Released too.

-- 
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/1619258

Title:
  netplan should allow NICs to be disconnected and not stall the boot

Status in Snappy:
  Confirmed
Status in nplan package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  in older snappy image we used to set "allow-hotplug" in
  /etc/network/interfaces.d/ when configuring a NIC to avoid the boot to
  completely stall or to be stuck for 5min when trying to find an
  internet connection.

  with recent versions of netplan the configuration seems to be back to
  require a network to be up before moving on with them boot so that
  booting takes forever until the network connection times out.

  netplan should make the system check the physical link status when
  trying to bring up a network device instead of stalling the boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1619258/+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 1619258] Re: netplan should allow NICs to be disconnected and not stall the boot

[Daniel Axtens]

Thanks, done.

** Changed in: nplan (Ubuntu)
   Status: In Progress => Fix Released

-- 
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/1619258

Title:
  netplan should allow NICs to be disconnected and not stall the boot

Status in Snappy:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  in older snappy image we used to set "allow-hotplug" in
  /etc/network/interfaces.d/ when configuring a NIC to avoid the boot to
  completely stall or to be stuck for 5min when trying to find an
  internet connection.

  with recent versions of netplan the configuration seems to be back to
  require a network to be up before moving on with them boot so that
  booting takes forever until the network connection times out.

  netplan should make the system check the physical link status when
  trying to bring up a network device instead of stalling the boot.

To manage notifications about this bug go to:
https://bugs.launchpad.net/snappy/+bug/1619258/+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 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

** Changed in: netplan
   Status: Confirmed => Fix Released

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Fix Released
Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in nplan package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Confirmed
Status in nplan source package in Xenial:
  Fix Released
Status in netplan.io source package in Bionic:
  Fix Released

Bug description:
  [Impact]
  Systems relying on renaming network interfaces at boot and when 'netplan 
apply' is run.

  [Test case]
  - Write a new netplan YAML (adjusting for current system as necessary):
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: myif0

  - Run 'netplan apply'
  - Verify that the device is correctly renamed to 'myif0'.
  - Reboot.
  - Make sure the device is correctly renamed to 'myif0'.

  [Regression potential]
  Changes in rename logic to add udev rules may otherwise impact applying 
different settings to the network interfaces. Changes in settings on network 
interfaces, missing parameters (especially on bonds, bridges) should be 
investigated as potential regressions. Other failures to apply network settings 
might also happen if there's a race between applying renames via the udev 
rules, and using the new names to apply configuration changes to the interfaces.

  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud environments.

To 

[Touch-packages] [Bug 1746419] Re: bond parameters are not changed by 'netplan apply'

[Daniel Axtens]

** Also affects: netplan
   Importance: Undecided
   Status: New

** Changed in: netplan
   Status: New => Confirmed

-- 
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/1746419

Title:
  bond parameters are not changed by 'netplan apply'

Status in netplan:
  Confirmed
Status in nplan package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  I have a yaml file as follows:

  network:
  version: 2
  ethernets:
  bonddevs:
  match:
  name: ens[78]
  bonds:
  bond0:
  interfaces: [bonddevs]
  parameters:
  mode: active-backup
  mii-monitor-interval: 1
  addresses:
  - 10.10.10.1/24

  
  Say I decide that 1s is too frequent for the MII interval, and I want to 
change the interval to 2s.

  If I change that in the yaml, then run
  # netplan generate
  # netplan apply
  # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
  MII Polling Interval (ms): 1000

  In other words, the change has not been applied.

  Running netplan --debug apply prints:
  DEBUG:device bond0 operstate is up, not replugging

  So I wondered if bringing the bond down would help. It does not:
  # ip link set dev bond0 down
  # netplan apply
  # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
  MII Polling Interval (ms): 1000

  However, deleting the link works:
  # ip link del dev bond0
  # netplan apply
  # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
  MII Polling Interval (ms): 2000

  This is counter-intuitive behaviour.
  Ideally, I would like a regular netplan apply to work without deleting the 
bond.
  However, a changed to the docs to make this clear would be OK.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: nplan 0.32~17.10.1
  ProcVersionSignature: User Name 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.7
  Architecture: amd64
  Date: Wed Jan 31 05:47:42 2018
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: nplan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1746419/+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 1781652] Re: should be possible to specify static routes on a dhcp-configured interface

[Daniel Axtens]

This hit me too.

I'm not sure how netplan can fix this - it looks like it's generating
pretty sensible configuration files.

-- 
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/1781652

Title:
  should be possible to specify static routes on a dhcp-configured
  interface

Status in netplan:
  New
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  From , a user wants to add a static route to a
  network interface where the gateway is known, but the interface's
  local address is configured via dhcp.

  This doesn't work with direct netplan yaml, because networkd will try
  to apply the static routes before the interface has been configured
  via dhcp, failing because there is not yet a route to the gateway on
  that interface.

  Demonstrating in a lxd container locally, which has 10.44.49.0/24 as
  its network:

  $ cat /etc/netplan/50-cloud-init.yaml
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  eth0:
  dhcp4: true
  routes:
 - to: 10.44.48.0/24
   via: 10.44.49.2
   metric: 10
  $  systemctl status systemd-networkd --no-pager -l
  ● systemd-networkd.service - Network Service
 Loaded: loaded (/lib/systemd/system/systemd-networkd.service; enabled; 
vendor preset: enabled)
 Active: active (running) since Fri 2018-07-13 19:21:29 UTC; 8min ago
   Docs: man:systemd-networkd.service(8)
   Main PID: 165 (systemd-network)
 Status: "Processing requests..."
  Tasks: 1 (limit: 4915)
 CGroup: /system.slice/systemd-networkd.service
 └─165 /lib/systemd/systemd-networkd

  Jul 13 19:21:29 stable-dane systemd[1]: Starting Network Service...
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: Enumeration completed
  Jul 13 19:21:29 stable-dane systemd[1]: Started Network Service.
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: Could not set route: 
Network is unreachable
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: DHCPv4 address 
10.44.49.32/24 via 10.44.49.1
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: Not connected to system 
bus, not setting hostname.
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: Gained IPv6LL
  Jul 13 19:21:29 stable-dane systemd-networkd[165]: eth0: Configured
  Jul 13 19:21:55 stable-dane systemd-networkd[165]: Could not set hostname: 
Method call timed out
  $ ip route 
  default via 10.44.49.1 dev eth0 proto dhcp src 10.44.49.32 metric 100 
  10.44.49.0/24 dev eth0 proto kernel scope link src 10.44.49.32 
  10.44.49.1 dev eth0 proto dhcp scope link src 10.44.49.32 metric 100 
  $

  netplan and networkd should DTRT.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1781652/+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 1746419] Re: bond parameters are not changed by 'netplan apply'

[Daniel Axtens]

Should it though? That will, for example, terminate any tcpdump
processes bound to the bond, it will disrupt currently running
connections, etc. Maybe we could do it but we'd want to put it behind a
--force option or something, I think.

-- 
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/1746419

Title:
  bond parameters are not changed by 'netplan apply'

Status in netplan:
  Confirmed
Status in nplan package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Won't Fix

Bug description:
  I have a yaml file as follows:

  network:
  version: 2
  ethernets:
  bonddevs:
  match:
  name: ens[78]
  bonds:
  bond0:
  interfaces: [bonddevs]
  parameters:
  mode: active-backup
  mii-monitor-interval: 1
  addresses:
  - 10.10.10.1/24

  
  Say I decide that 1s is too frequent for the MII interval, and I want to 
change the interval to 2s.

  If I change that in the yaml, then run
  # netplan generate
  # netplan apply
  # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
  MII Polling Interval (ms): 1000

  In other words, the change has not been applied.

  Running netplan --debug apply prints:
  DEBUG:device bond0 operstate is up, not replugging

  So I wondered if bringing the bond down would help. It does not:
  # ip link set dev bond0 down
  # netplan apply
  # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
  MII Polling Interval (ms): 1000

  However, deleting the link works:
  # ip link del dev bond0
  # netplan apply
  # cat /proc/net/bonding/bond0|grep "MII Polling Interval (ms)"
  MII Polling Interval (ms): 2000

  This is counter-intuitive behaviour.
  Ideally, I would like a regular netplan apply to work without deleting the 
bond.
  However, a changed to the docs to make this clear would be OK.

  ProblemType: Bug
  DistroRelease: Ubuntu 17.10
  Package: nplan 0.32~17.10.1
  ProcVersionSignature: User Name 4.13.0-32.35-generic 4.13.13
  Uname: Linux 4.13.0-32-generic x86_64
  ApportVersion: 2.20.7-0ubuntu3.7
  Architecture: amd64
  Date: Wed Jan 31 05:47:42 2018
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: nplan
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1746419/+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 1770082] Re: set-name doesn't work on boot, only with netplan apply

[Daniel Axtens]

** Description changed:

+ === systemd issue ===
+ 
+ Renaming devices doesn't seem to work.
+ 
+ If I create /etc/systemd/network/10-network.link with:
+ 
+ [Match]
+ MACAddress=52:54:00:c1:c9:bb
+ 
+ [Link]
+ Name=myiface3
+ 
+ I expect this to cause the device with that MAC address to be named to
+ myiface3. However, when I reboot, I instead see:
+ 
+ $ ip l
+ 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ 2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
+ link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
+ 
+ The device is not renamed.
+ 
+ This link is pretty much identical to Example 2 in
+ https://www.freedesktop.org/software/systemd/man/systemd.link.html.
+ 
+ Oddly, while it doesn't work on reboot, it does work if you unbind the
+ device and rebind it as netplan apply does.
+ 
+ === Original Bug ==
+ 
  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.
  
  Say I take this 50-cloud-init.yaml file:
  
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3
  
  Say I change set-name to 'myiface3' and reboot. I expect that the device
  will be called myiface3 and brought up fine with dhcp. However, instead
  I see:
  
  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  
  The name has not been changed, and the device has not been brought up.
  
  If I run netplan apply however, I see the following:
  
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever
  
  So names are successfully changed with netplan apply.
  
  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.
  
  This breaks some forms of migration in certain cloud environments.

** Description changed:

  === systemd issue ===
  
  Renaming devices doesn't seem to work.
  
  If I create /etc/systemd/network/10-network.link with:
  
  [Match]
  MACAddress=52:54:00:c1:c9:bb
  
  [Link]
  Name=myiface3
  
- I expect this to cause the device with that MAC address to be named to
+ I expect this to cause the device with that MAC address to be renamed to
  myiface3. However, when I reboot, I instead see:
  
  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
- link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
+ link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
- link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
+ link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
  
  The device is not renamed.
  
  This link is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.
  
  Oddly, while it doesn't work on reboot, it does work if you unbind the
  device and rebind it as netplan apply does.
  
  === Original Bug ==
  
  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.
  
  Say I take this 50-cloud-init.yaml file:
  
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macad

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

** Summary changed:

- set-name doesn't work on boot, only with netplan apply
+ systemd-networkd not renaming devices on boot

** Description changed:

  === systemd issue ===
  
  Renaming devices doesn't seem to work.
  
  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:
  
  [Match]
  MACAddress=52:54:00:c1:c9:bb
  
  [Link]
  Name=myiface3
  
  I expect this to cause the device with that MAC address to be renamed to
  myiface3. However, when I reboot, I instead see:
  
  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff
  
  The device is not renamed.
  
  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.
  
  The renaming does work if I boot with net.ifnames=0, and oddly, it also
- works if I unbind the device and rebind it as netplan apply does.
+ works if I unbind the device and rebind it as netplan apply does. No
+ setting of NamePolicy seems to help.
  
  === Original Bug ==
  
  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.
  
  Say I take this 50-cloud-init.yaml file:
  
  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3
  
  Say I change set-name to 'myiface3' and reboot. I expect that the device
  will be called myiface3 and brought up fine with dhcp. However, instead
  I see:
  
  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  
  The name has not been changed, and the device has not been brought up.
  
  If I run netplan apply however, I see the following:
  
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever
  
  So names are successfully changed with netplan apply.
  
  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.
  
  This breaks some forms of migration in certain cloud environments.

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works 

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Both the original cloudy report and my test use a VM. The issue seems to
happen for both virtio and emulated e1000 network hardware.

What happens differently with a VM?

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud environments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Ryan: I removed /etc/netplan/50-cloud-init.yaml and rebooted repeatedly and
I've never seen it regenerated.

I also don't see anything in /run/netplan or /run/systemd/network that has
been autogenerated.

I haven't touched anything else generated by cloud-init. When would
cloud-init regenerate a network config file?

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud environments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Ryan, I can't get that to work on my systems. What is it that update-
initramfs is supposed to change? I don't see any files in my initramfs
that are generated or read by netplan. Neither do I see netplan itself
in the initramfs!

Mathieu, I thought netplan was supposed to be initramfs friendly by
virtue of being in C. Is it supposed to be in the initramfs?

For both of you, how are you getting through initrd without your device
being given a generic udev name (like ens3 or enp1s0)? On both my
physical and virtual machines, my various network cards all get renamed
in initrd, well before netplan is run.

[PS. I know the scenario as described sounds far-fetched - the original
way this came up was a cloud setup where you can change the type of a
network interface but keep the same MAC. The different type leads to a
different udev name, which is what revealed that set-name: wasn't taking
effect.]

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud environments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Ok, so the bit I'm stuck on is how the link files and the netplan
generator are getting pulled into the initramfs then.

ubuntu@btest:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-4.15.0-20-generic

ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep \\.link
lib/systemd/network/99-default.link
ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep netplan
ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep generate
ubuntu@btest:~$ lsinitramfs /boot/initrd.img-4.15.0-20-generic | grep 
system-generators

As you can see there's no generator and no link files in my initramfs -
by what mechanism is it supposed to work? What package/script/tool is
supposed to pull the link files in?

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud environments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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

Re: [Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Right. Yes, I can replicate that, thanks heaps!

So to summarise, you can make the rename take effect on boot if you:
 1) copy the files from /run/systemd/network -> /etc/systemd/network
 2) then update-initramfs -u

This seems pretty far outside of the way that netplan is supposed to work -
indeed using /etc/systemd/ is basically bypassing netplan. So we still have
the issue that just changing 'set-name' in /etc/netplan/*.yaml doesn't work
as expected. What should we change so that set-name works as expected?

I see a few options:

 0) Document that set-name is fragile and stop relying on it. This is
actually really easy to do and I have a netplan patch drafted already. The
reason that we have no network connectivity when set-name fails is that the
network file netplan creates maches on *both* the new name and the mac
address. We can just drop the new name from the [Match] section of the
relevant .network file and match only on the provided mac address (or
whatever else was used in the netplan match stanza). This means that
regardless of the interface name it's brought up and networking works.

 1) Make the initramfs hook for udev copy the files from /run (as well as
from /lib and /etc) into the initial ramdisk. This is probably my
preference; we can run netplan generate beforehand to make sure we get a
clean copy, and then document that update-initramfs is required to get
stuff to stick.

 2) Allow udev to re-rename interfaces. I don't know if this would be
acceptable to systemd upstream?

 3) Something else?

Regards,
Daniel

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netpla

[Touch-packages] [Bug 1770082] Re: systemd-networkd not renaming devices on boot

[Daniel Axtens]

Ok, how does this look?

** Patch added: "link-files-in-run.debdiff"
   
https://bugs.launchpad.net/netplan/+bug/1770082/+attachment/5139062/+files/link-files-in-run.debdiff

-- 
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/1770082

Title:
  systemd-networkd not renaming devices on boot

Status in netplan:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  === systemd issue ===

  Renaming devices doesn't seem to work.

  If I disable all other network configuration and create
  /etc/systemd/network/10-network.link with:

  [Match]
  MACAddress=52:54:00:c1:c9:bb

  [Link]
  Name=myiface3

  I expect this to cause the device with that MAC address to be renamed
  to  myiface3. However, when I reboot, I instead see:

  $ ip l
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  2: ens3:  mtu 1500 qdisc noop state DOWN mode DEFAULT 
group default qlen 1000
  link/ether 52:54:00:c1:c9:bb brd ff:ff:ff:ff:ff:ff

  The device is not renamed.

  This link file is pretty much identical to Example 2 in
  https://www.freedesktop.org/software/systemd/man/systemd.link.html.

  The renaming does work if I boot with net.ifnames=0, and oddly, it
  also works if I unbind the device and rebind it as netplan apply does.
  No setting of NamePolicy seems to help.

  === Original Bug ==

  'set-name:' doesn't change the name of a network interface on boot, it
  only works when you do netplan apply.

  Say I take this 50-cloud-init.yaml file:

  # This file is generated from information provided by
  # the datasource.  Changes to it will not persist across an instance.
  # To disable cloud-init's network configuration capabilities, write a file
  # /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
  # network: {config: disabled}
  network:
  version: 2
  ethernets:
  ens3:
  dhcp4: true
  match:
  macaddress: 52:54:00:de:bd:f6
  set-name: ens3

  Say I change set-name to 'myiface3' and reboot. I expect that the
  device will be called myiface3 and brought up fine with dhcp. However,
  instead I see:

  $ ip a
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  2: ens3:  mtu 1500 qdisc noop state DOWN group default 
qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff

  The name has not been changed, and the device has not been brought up.

  If I run netplan apply however, I see the following:

  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN group 
default qlen 1000
  link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
  inet 127.0.0.1/8 scope host lo
     valid_lft forever preferred_lft forever
  inet6 ::1/128 scope host
     valid_lft forever preferred_lft forever
  3: myiface3:  mtu 1500 qdisc fq_codel state 
UP group default qlen 1000
  link/ether 52:54:00:de:bd:f6 brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.151/24 brd 192.168.122.255 scope global dynamic myiface3
     valid_lft 3575sec preferred_lft 3575sec
  inet6 fe80::5054:ff:fede:bdf6/64 scope link
     valid_lft forever preferred_lft forever

  So names are successfully changed with netplan apply.

  This seems to be some udev-related timing or priority issue that I'm
  still trying to hunt down.

  This breaks some forms of migration in certain cloud environments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/netplan/+bug/1770082/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi,

What happens if you remove the fb driver - uninstall the xserver-xorg-
video-fbdev package?

Also, I'm not sure what (if any) changes have been made in the kernel
version you're running - the 'pearl' version - but are you able to try
against a mainline kernel?

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi,

This is what I have figured out so far.

For some reason the initial probing done by the modesetting driver
fails. This is part of the platform device probing stage. This failure
means the device is not claimed by the modesetting driver as a 'regular'
screen. Instead it is claimed by the fbdev driver. The modesetting
driver then claims the platform device as a 'GPU' device. It shouldn't
do that: the GPU device init is what causes the crash.

What I am still trying to figure out is why the initial probing fails.
This is difficult to figure out from the core dump, so I have attached a
patch for xorg-server that should help. With this patch I should be able
to figure out what part of the probe doesn't go as expected.

Please let me know if you have any trouble applying the patch.

** Patch added: "patch to enable extra debugging"
   
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+attachment/4886582/+files/debug.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi Mao,

Yes, remote access would be the fastest way to debug this.

You can contact me by email - daniel.axt...@canonical.com.

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

OK, I have made some progress on this:

The busid reported by libdrm on the arm64 system is "0007:a1:00.0"
The busid reported by libdrm on a amd64 system is "pci::00:02.0"

The "pci:" prefix is missing on arm64. I think this leads to the
segfault on arm64 as X tests for the prefix.

This little C program below extracts the information and demonstrates
the difference.

I will follow up why this is happening.

Regards,
Daniel

#include 
#include 
#include "stdio.h"
#include 
#include 
#include 

int main() {
char *path="/dev/dri/card0";
drmSetVersion sv;
char *buf;
int fd;
int err = 0;

fd = open(path, O_RDWR, O_CLOEXEC);

sv.drm_di_major = 1;
sv.drm_di_minor = 4;
sv.drm_dd_major = -1;   /* Don't care */
sv.drm_dd_minor = -1;   /* Don't care */

err = drmSetInterfaceVersion(fd, &sv);

buf = drmGetBusid(fd);
printf("busid: '%s'\n", buf);
drmFreeBusid(buf);
close(fd);
return (err == 0);
}

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Ok, so I think part of the problem is that the kernel hibmc driver needs
to use a set_busid function from the drm core. I've simulated this
change in the debugger, and it seems to at least prevent the crash. (It
doesn't seem to be enough for the server to work, still working on
that.)

Here's a patch - we can discuss the best way to build and install it.

** Patch added: "0001-Use-standard-busid-function-from-drm-core.patch"
   
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+attachment/4887275/+files/0001-Use-standard-busid-function-from-drm-core.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi,

On further investigation it turns out that one large difference between
my x86 system and the arm64 system is they way the vga arbiter is
operating in the kernel. This means that the vga card isn't labelled as
the "boot vga" card, which affects how it's picked up by X.

On the HiSilicon board, I'm seeing:

[0.815343] pci 0007:a1:00.0: vgaarb: VGA device added: 
decodes=io+mem,owns=none,locks=none
[0.815355] pci 0007:a1:00.0: vgaarb: bridge control possible
[0.815360] vgaarb: loaded

On an x86 vm I'm seeing:

[0.390696] vgaarb: setting as boot device: PCI::00:02.0
[0.391245] vgaarb: device added: 
PCI::00:02.0,decodes=io+mem,owns=io+mem,locks=none
[0.393421] vgaarb: loaded
[0.393811] vgaarb: bridge control possible :00:02.0

(The difference in the format is due to different kernel versions)

Looking at the kernel source, it looks like the owns= section is getting
blanked because of the bridge that the VGA card is sitting behind.

>From drivers/gpu/vga/vgaarb.c:

/* Mark that we "own" resources based on our enables, we will
 * clear that below if the bridge isn't forwarding
 */
pci_read_config_word(pdev, PCI_COMMAND, &cmd);
if (cmd & PCI_COMMAND_IO)
vgadev->owns |= VGA_RSRC_LEGACY_IO;
if (cmd & PCI_COMMAND_MEMORY)
vgadev->owns |= VGA_RSRC_LEGACY_MEM;

/* Check if VGA cycles can get down to us */
bus = pdev->bus;
while (bus) {
bridge = bus->self;
if (bridge) {
u16 l;

pci_read_config_word(bridge, PCI_BRIDGE_CONTROL, &l);
if (!(l & PCI_BRIDGE_CTL_VGA)) {
vgadev->owns = 0;
break;
}
}
bus = bus->parent;
}

/* Deal with VGA default device. Use first enabled one
 * by default if arch doesn't have it's own hook
 */
if (vga_default == NULL &&
((vgadev->owns & VGA_RSRC_LEGACY_MASK) == VGA_RSRC_LEGACY_MASK)) {
vgaarb_info(&pdev->dev, "setting as boot VGA device\n");
vga_set_default_device(pdev);

Perhaps X should be be picking up the card through PCI probing on arm64
rather than platform probing which seems to rely a bit on boot VGA
devices. I will check this. But first I just wanted to check the PCI
topology: is the card behind any unusual bridges or switches?

I can write some kernel code next week to find out specifically why this
isn't being picked up, but I thought I'd check for HW quirks first.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsu

[Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Dann: thanks, will do that.

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi,

I can get xorg working if I do these 2 things:

1) Edit memory with gdb to add "pci:" to bus id. This is what the kernel
patch should do. I will test the patch soon, I am just waiting for the
kernel to build.

2) Install this /etc/X11/xorg.conf:

Section "ServerFlags"
Option "AutoAddGPU" "off"
EndSection

Section "Device"
Identifier "dja"
Driver "modesetting"
BusID "pci:0007:161:0:0"
EndSection


This does 2 things:
 - AutoAddGPU prevents the card from falsely being marked as GPU. I am not yet 
fully sure why that is required.

 - The Device section then specifies the busid and driver specifically.
This forces the driver to be loaded correctly.

This Xorg configuration should not be required in the long term. There
are obviously still some bugs to be fixed. But, I wanted to let you know
that progress was being made and give you good news.

Attached is a screenshot of Xeyes over KVM.

Regards,
Daniel

** Attachment added: "xeyes.png"
   
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+attachment/4889182/+files/xeyes.png

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

** Changed in: xorg (Ubuntu)
 Assignee: (unassigned) => Daniel Axtens (daxtens)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi Mao,

I have looked at the PCI setup a bit more closely: the VGA card is
behind a PCI bridge which does not advertise the PCI_BRIDGE_CTL_VGA
capability, so it is not being picked up by the kernel as the
default/boot card.

Is there anything special about the bridge or the hardware in this
regard?

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi Dann,

I have tried to boot the HiSilicon board with a zesty kernel (and with a
patched zesty kernel) and it boots, gets to the following, and then
hangs without displaying a prompt:

[9.900239] async_tx: api initialized (async)
[9.991929] Btrfs loaded, crc32c=crc32c-arm64-hw
[   55.474203] hidraw: raw HID events driver (C) Jiri Kosina
[   55.483000] usbcore: registered new interface driver usbhid
[   55.488571] usbhid: USB HID core driver
[ME] Fault detect start!
[ME] Fault detect start!

Is there anything different between the pearl kernels and the zesty
kernel that would make the prompt show up and/or avoid the hang?

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi Dann,

Ignore that, I didn't realise I needed the -extra package.

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi Mao,

I have successfully verified that with the patched kernel and the Xorg
config, X starts fine.

Do you need assistance getting that patch upstream, or is that something
HiSilicon/the HWE team can do?

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi Mao,

I have installed a version of the kernel which ignores the capabilities
of the PCI bridge when determining whether a device can be the boot
device. With this patched kernel, X starts without needing a config
file.

This confirms:
 - that the vga card is not marked as boot device because of the the PCI bridge 
that the VGA card sits behind.
 - not being marked as boot vga is what is causing X not to pick it up the card.

This is a debug patch only, and not a patch we will be able to get
upstream, so I think we will need to discuss with the HiSilicon people
why their hardware is behaving this way.

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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

Re: [Touch-packages] [Bug 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi Mao,

OK, that sounds reasonable. I will follow up on this.

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi Mao,

I have done more work on the HiSilicon board. I have talked with the SEG
team and our conclusion is that the hardware is not compliant with the
specification, but that it is appropriate to include a workaround in
software.

I have developed a patch that adds a workaround or 'quirk' to the kernel
specifically for the hisilicon graphics card and the hisilicon PCI
bridge. It tests for the card and the bridge on the development board. I
think it might be acceptable for upstream. With this, X
autoconfiguration works.

Please could you ask the HiSilicon people if there are other boards or
parts with different PCI IDs that should be included in this fixup?

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

Hi Mao,

Thanks for that.

You are right, this should be split into two kernel issues.

I have opened:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1698700 - "pci:" prefix in 
bus ID
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1698706 - Quirk for vga 
card and bridge

I have subscribed you to these bugs. They include some updates to the
upstreaming process and I will keep them updated.

If it's alright with you I will close this bug as we've established it's
not a bug in X.

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  New

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1691991] Re: Xorg Segmentation fault on Hisilicon D05 board (arm64)

[Daniel Axtens]

** Changed in: xorg (Ubuntu)
   Status: New => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to xorg in Ubuntu.
https://bugs.launchpad.net/bugs/1691991

Title:
  Xorg Segmentation fault on Hisilicon D05 board (arm64)

Status in xorg package in Ubuntu:
  Invalid

Bug description:
  ubuntu@ubuntu:~$ sudo /usr/lib/xorg/Xorg 
  [sudo] password for ubuntu: 

  X.Org X Server 1.18.4
  Release Date: 2016-07-19
  X Protocol Version 11, Revision 0
  Build Operating System: Linux 4.4.0-45-generic aarch64 Ubuntu
  Current Operating System: Linux ubuntu 4.10.0-20.22-generic 
#22+pearl.2-Ubuntu SMP Thu Apr 27 20:23:08 UTC 2017 aarch64
  Kernel command line: BOOT_IMAGE=/boot/vmlinuz-4.10.0-20.22-generic 
root=UUID=eee681c5-04ce-4cd0-a004-cae6717961ce ro debug 
earlycon=pl011,mmio,0x602B console=tty0
  Build Date: 02 November 2016  10:05:28PM
  xorg-server 2:1.18.4-0ubuntu0.2 (For technical support please see 
http://www.ubuntu.com/support) 
  Current version of pixman: 0.33.6
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
  Markers: (--) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
  (==) Log file: "/var/log/Xorg.0.log", Time: Fri May 19 18:10:13 2017
  (==) Using system config directory "/usr/share/X11/xorg.conf.d"
  pci id for fd 10: 19e5:1711, driver (null)
  EGL_MESA_drm_image required.
  (EE) 
  (EE) Backtrace:
  (EE) 0: /usr/lib/xorg/Xorg (xorg_backtrace+0x58) [0xd7f1cc48]
  (EE) 
  (EE) Segmentation fault at address 0xa0
  (EE) 
  Fatal server error:
  (EE) Caught signal 11 (Segmentation fault). Server aborting
  (EE) 
  (EE) 
  Please consult the The X.Org Foundation support 
 at http://wiki.x.org
   for help. 
  (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional 
information.
  (EE) 
  (EE) Server terminated with error (1). Closing log file.
  Aborted (core dumped)
  ubuntu@ubuntu:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1691991/+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 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Daniel Axtens]

Hi Marzog,

What commit has been committed to Linux? I cannot find it.

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1701297

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Won't Fix
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Fix Committed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

  Related bugs:
   * bug 1645644: cloud-init ntp not using expected servers

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Daniel Axtens]

Hi Tyler,

Do you know what the changes between the ga-16.04 and hwe-16.04 kernel
are that make apparmor+overlayfs work? I'm worried we might hit this
problem elsewhere...

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1701297

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1701297] Re: NTP reload failure (unable to read library) on overlayfs

[Daniel Axtens]

Tyler - thanks for that.

John - this is coming up in some internal support team escalations so
I'm going to have a look at the kernel changes myself and will let you
know if I find anything. I'd be keen to sync up if you have any leads.

Regards,
Daniel

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to apparmor in Ubuntu.
https://bugs.launchpad.net/bugs/1701297

Title:
  NTP reload failure (unable to read library) on overlayfs

Status in cloud-init:
  Incomplete
Status in apparmor package in Ubuntu:
  Confirmed
Status in cloud-init package in Ubuntu:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After update [1] of cloud-init in Ubuntu (which landed in xenial-
  updates on 2017-06-27), it is causing NTP reload failures.

  https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f-
  0ubuntu1~16.04.1

  In MAAS scenarios, this is causing the machine to fail to deploy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1458416] [NEW] JIT unnecessarily disabled on ppc64le

[Daniel Axtens]

Public bug reported:

Ubuntu carries 'no_jit_ppc64el.patch' in the debian/patches directory.
As the name suggests, this patch disables JIT on ppc64 little-endian.
This used to be necessary because JIT was broken on little endian.

However, JIT on ppc64 little endian has been supported in pcre3 since
version 8.35 (see http://www.pcre.org/original/changelog.txt - point 19
for version 8.35). Given that Ubuntu has shipped 8.35 since Utopic, this
patch should now be dropped.

** Affects: pcre3 (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pcre3 in Ubuntu.
https://bugs.launchpad.net/bugs/1458416

Title:
  JIT unnecessarily disabled on ppc64le

Status in pcre3 package in Ubuntu:
  New

Bug description:
  Ubuntu carries 'no_jit_ppc64el.patch' in the debian/patches directory.
  As the name suggests, this patch disables JIT on ppc64 little-endian.
  This used to be necessary because JIT was broken on little endian.

  However, JIT on ppc64 little endian has been supported in pcre3 since
  version 8.35 (see http://www.pcre.org/original/changelog.txt - point
  19 for version 8.35). Given that Ubuntu has shipped 8.35 since Utopic,
  this patch should now be dropped.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pcre3/+bug/1458416/+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 1818340] Re: systemd-networkd core dumps in bionic-proposed

[Daniel Axtens]

Oof, sorry! It's not clear to me from the bug report and subsequent
comments - is it just Bionic that's affected, or is it also Cosmic?

-- 
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/1818340

Title:
  systemd-networkd core dumps in bionic-proposed

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  during restart, systemd-networkd fails an assertion and aborts,
  leaving the system networking partially (if at all) configured.
  Further restarts continue to fail.

  [Test Case]

  Install a bionic system (cosmic affected also) with only systemd-
  networkd networking (i.e. uninstall or do not configure netplan).
  Ensure no networkd conf files are in /run/systemd/network.  Stop
  networkd (sudo systemctl stop systemd-networkd).  The interface to
  test with networkd (e.g. ens3) should have no address assigned and
  should be down.

  Create a file similar to below, adjusting for interface name:

  $ cat /etc/systemd/network/10-netplan-ens3.network
  [Match]
  Name=ens3

  [Network]
  Address=192.168.122.68/24

  Start networkd:

  ubuntu@lp1818340-b:~$ sudo systemctl start systemd-networkd
  ubuntu@lp1818340-b:~$ ip a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether 52:54:00:6e:8c:9f brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.68/24 brd 192.168.122.255 scope global ens3
     valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe6e:8c9f/64 scope link
     valid_lft forever preferred_lft forever

  Stop networkd; ens3 should retain its address:

  ubuntu@lp1818340-b:~$ sudo systemctl stop systemd-networkd
  ubuntu@lp1818340-b:~$ ip a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether 52:54:00:6e:8c:9f brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.68/24 brd 192.168.122.255 scope global ens3
     valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe6e:8c9f/64 scope link
     valid_lft forever preferred_lft forever

  Start networkd again; the bug is triggered:

  ubuntu@lp1818340-b:~$ sudo systemctl start systemd-networkd
  Job for systemd-networkd.service failed because a fatal signal was delivered 
causing the control process to dump core.
  See "systemctl status systemd-networkd.service" and "journalctl -xe" for 
details.

  Alternately, instead of separately stopping and then starting
  networkd, the failure can be reproduced with just a restart.

  Note the failure only happens with statically-assigned addresses;
  interfaces configured with dhcp do not trigger this bug.

  [Regression Potential]

  TBD

  [Other Info]

  This was introduced by the SRU for bug 1812760; both the new behavior
  of networkd not removing managed addresses/routes from managed
  interfaces, as well as the assertion failure bug.  This does not fail
  in disco; I believe additional commit(s) from upstream need to be
  backported.

  Original description:

  ---

  I run a number of servers with -proposed enabled and have seen a bunch
  of this today:

  Mar 02 16:20:58 4-ridge-fw1 systemd[1]: systemd-networkd.service: Failed with 
result 'core-dump'.
  Mar 02 16:20:58 4-ridge-fw1 systemd[1]: Failed to start Network Service.

  These machines have numerous bonds, so I suspect that's a factor.

  So far I have only observed the issue on machines with -proposed
  enabled so I suspect it is a problem with systemd 237-3ubuntu10.14

  Example netplan.yaml attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818340/+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 1818340] Re: systemd-networkd core dumps in bionic-proposed

[Daniel Axtens]

Never mind, I can reproduce on Cosmic.

-- 
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/1818340

Title:
  systemd-networkd core dumps in bionic-proposed

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  during restart, systemd-networkd fails an assertion and aborts,
  leaving the system networking partially (if at all) configured.
  Further restarts continue to fail.

  [Test Case]

  Install a bionic system (cosmic affected also) with only systemd-
  networkd networking (i.e. uninstall or do not configure netplan).
  Ensure no networkd conf files are in /run/systemd/network.  Stop
  networkd (sudo systemctl stop systemd-networkd).  The interface to
  test with networkd (e.g. ens3) should have no address assigned and
  should be down.

  Create a file similar to below, adjusting for interface name:

  $ cat /etc/systemd/network/10-netplan-ens3.network
  [Match]
  Name=ens3

  [Network]
  Address=192.168.122.68/24

  Start networkd:

  ubuntu@lp1818340-b:~$ sudo systemctl start systemd-networkd
  ubuntu@lp1818340-b:~$ ip a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether 52:54:00:6e:8c:9f brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.68/24 brd 192.168.122.255 scope global ens3
     valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe6e:8c9f/64 scope link
     valid_lft forever preferred_lft forever

  Stop networkd; ens3 should retain its address:

  ubuntu@lp1818340-b:~$ sudo systemctl stop systemd-networkd
  ubuntu@lp1818340-b:~$ ip a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether 52:54:00:6e:8c:9f brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.68/24 brd 192.168.122.255 scope global ens3
     valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe6e:8c9f/64 scope link
     valid_lft forever preferred_lft forever

  Start networkd again; the bug is triggered:

  ubuntu@lp1818340-b:~$ sudo systemctl start systemd-networkd
  Job for systemd-networkd.service failed because a fatal signal was delivered 
causing the control process to dump core.
  See "systemctl status systemd-networkd.service" and "journalctl -xe" for 
details.

  Alternately, instead of separately stopping and then starting
  networkd, the failure can be reproduced with just a restart.

  Note the failure only happens with statically-assigned addresses;
  interfaces configured with dhcp do not trigger this bug.

  [Regression Potential]

  TBD

  [Other Info]

  This was introduced by the SRU for bug 1812760; both the new behavior
  of networkd not removing managed addresses/routes from managed
  interfaces, as well as the assertion failure bug.  This does not fail
  in disco; I believe additional commit(s) from upstream need to be
  backported.

  Original description:

  ---

  I run a number of servers with -proposed enabled and have seen a bunch
  of this today:

  Mar 02 16:20:58 4-ridge-fw1 systemd[1]: systemd-networkd.service: Failed with 
result 'core-dump'.
  Mar 02 16:20:58 4-ridge-fw1 systemd[1]: Failed to start Network Service.

  These machines have numerous bonds, so I suspect that's a factor.

  So far I have only observed the issue on machines with -proposed
  enabled so I suspect it is a problem with systemd 237-3ubuntu10.14

  Example netplan.yaml attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818340/+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 1818340] Re: systemd-networkd core dumps in bionic-proposed

[Daniel Axtens]

OK, so with the magic of debug symbols and gdb on Cosmic:

(gdb) run
...
ens8: Gained IPv6LL
Assertion 'link->state == LINK_STATE_SETTING_ADDRESSES' failed at 
../src/network/networkd-link.c:803, function link_enter_set_routes(). Aborting.
...
(gdb) up
#3  0x5566b194 in link_enter_set_routes (link=0x5571d050) at 
../src/network/networkd-link.c:803
803 ../src/network/networkd-link.c: No such file or directory.
(gdb) p link->state
$3 = LINK_STATE_PENDING

Looking at the code, it seems we are hitting link_enter_set_routes()
before link_enter_set_addresses() which is where the state is set. We're
hitting link_enter_set_routes() because link_check_ready() now calls it
straight off the bat.

I think the backport just needs to add a check to not flow through to
setting the routes until after we've gone through the process of setting
the addresses; we can do that with the attached patch. (It applies to
the cosmic version, I haven't tested it against Bionic.)

Having said that Dan you've obviously had a closer look at the code and more 
recently, what patches did you think were needed? It looks like perhaps you 
could solve this by backporting c42ff3a1a7bf ("networkd: Track address 
configuration")
 and 289e6774d0da ("networkd: Use only a generic CONFIGURING state") - is that 
what you had in mind?


** Patch added: 
"0001-Do-not-call-link_enter_set_routes-until-LINK_STATE_S.patch"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1818340/+attachment/5243670/+files/0001-Do-not-call-link_enter_set_routes-until-LINK_STATE_S.patch

-- 
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/1818340

Title:
  systemd-networkd core dumps in bionic-proposed

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  during restart, systemd-networkd fails an assertion and aborts,
  leaving the system networking partially (if at all) configured.
  Further restarts continue to fail.

  [Test Case]

  Install a bionic system (cosmic affected also) with only systemd-
  networkd networking (i.e. uninstall or do not configure netplan).
  Ensure no networkd conf files are in /run/systemd/network.  Stop
  networkd (sudo systemctl stop systemd-networkd).  The interface to
  test with networkd (e.g. ens3) should have no address assigned and
  should be down.

  Create a file similar to below, adjusting for interface name:

  $ cat /etc/systemd/network/10-netplan-ens3.network
  [Match]
  Name=ens3

  [Network]
  Address=192.168.122.68/24

  Start networkd:

  ubuntu@lp1818340-b:~$ sudo systemctl start systemd-networkd
  ubuntu@lp1818340-b:~$ ip a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether 52:54:00:6e:8c:9f brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.68/24 brd 192.168.122.255 scope global ens3
     valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe6e:8c9f/64 scope link
     valid_lft forever preferred_lft forever

  Stop networkd; ens3 should retain its address:

  ubuntu@lp1818340-b:~$ sudo systemctl stop systemd-networkd
  ubuntu@lp1818340-b:~$ ip a show ens3
  2: ens3:  mtu 1500 qdisc fq_codel state UP 
group default qlen 1000
  link/ether 52:54:00:6e:8c:9f brd ff:ff:ff:ff:ff:ff
  inet 192.168.122.68/24 brd 192.168.122.255 scope global ens3
     valid_lft forever preferred_lft forever
  inet6 fe80::5054:ff:fe6e:8c9f/64 scope link
     valid_lft forever preferred_lft forever

  Start networkd again; the bug is triggered:

  ubuntu@lp1818340-b:~$ sudo systemctl start systemd-networkd
  Job for systemd-networkd.service failed because a fatal signal was delivered 
causing the control process to dump core.
  See "systemctl status systemd-networkd.service" and "journalctl -xe" for 
details.

  Alternately, instead of separately stopping and then starting
  networkd, the failure can be reproduced with just a restart.

  Note the failure only happens with statically-assigned addresses;
  interfaces configured with dhcp do not trigger this bug.

  [Regression Potential]

  TBD

  [Other Info]

  This was introduced by the SRU for bug 1812760; both the new behavior
  of networkd not removing managed addresses/routes from managed
  interfaces, as well as the assertion failure bug.  This does not fail
  in disco; I believe additional commit(s) from upstream need to be
  backported.

  Original description:

  ---

  I run a number of servers with -proposed enabled and have seen a bunch
  of this today:

  Mar 02 16:20:58 4-ridge-fw1 systemd[1]: systemd-networkd.service: Failed with 
result 'core-dump'.
  Mar 02 16:20:58 4-ridge-fw1 systemd[1]: Failed to start Network Service.

  These machines have numerous bonds, 

[Touch-packages] [Bug 1871451] Re: powerpc segfault on exponential of negative in python

[Daniel Axtens]

Hi,

I tested this on a real ppc64le machine:

root@1325f5985861:/#  python3 -c "import math; print(math.exp(-1))"
0.36787944117144233
root@1325f5985861:/# uname -a
Linux 1325f5985861 5.4.0-21-generic #25+lp1866909v202004031128-Ubuntu SMP Fri 
Apr 3 18:38:30 UTC 202 ppc64le ppc64le ppc64le GNU/Linux


It looks like it's a qemu bug.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to python3-defaults in
Ubuntu.
https://bugs.launchpad.net/bugs/1871451

Title:
  powerpc segfault on exponential of negative in python

Status in cloud-images:
  New
Status in python3-defaults package in Ubuntu:
  New

Bug description:
  When calculating the exponential of a negative number in python 3.6
  with the Ubuntu 18.04 Docker image (ppcle64), I receive a segfault.

  ```
  python3 -c "import math; math.exp(-1)"
  qemu: uncaught target signal 11 (Segmentation fault) - core dumped
  Segmentation fault
  ```

  I am running this in Docker on macOS. Here are the steps to reproduce
  the error.

  ```
  docker run --rm -it --platform linux/ppc64le ubuntu:18.04
  apt-get update -qq && apt-get install -y -qq python3
  python3 -c "import math; print(math.exp(0))"  # 1.0
  python3 -c "import math; print(math.exp(-0))"  # 1.0
  python3 -c "import math; print(math.exp(1))"  # 2.718281828459045
  python3 -c "import math; print(math.exp(-1))"
  ```

  This error does not happen when using the debian:10 or alpine images.

  Here is the output of docker version on my machine:

  ```
  Client: Docker Engine - Community
   Version:   19.03.8
   API version:   1.40
   Go version:go1.12.17
   Git commit:afacb8b
   Built: Wed Mar 11 01:21:11 2020
   OS/Arch:   darwin/amd64
   Experimental:  true

  Server: Docker Engine - Community
   Engine:
    Version:  19.03.8
    API version:  1.40 (minimum version 1.12)
    Go version:   go1.12.17
    Git commit:   afacb8b
    Built:Wed Mar 11 01:29:16 2020
    OS/Arch:  linux/amd64
    Experimental: true
   containerd:
    Version:  v1.2.13
    GitCommit:7ad184331fa3e55e52b890ea95e65ba581ae3429
   runc:
    Version:  1.0.0-rc10
    GitCommit:dc9208a3303feef5b3839f4323d9beb36df0a9dd
   docker-init:
    Version:  0.18.0
    GitCommit:fec3683
  ```

  Cross-posted to StackOverflow:
  https://stackoverflow.com/questions/61084969/python-segfault-
  calculating-exponential-of-negative-ppc64le

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1871451/+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