[Desktop-packages] [Bug 1833322] Re: Please consider no more having irqbalance enabled by default (per image/use-case/TBD)

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Opinion => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1833322

Title:
  Please consider no more having irqbalance enabled by default (per
  image/use-case/TBD)

Status in cloud-images:
  New
Status in Release Notes for Ubuntu:
  Fix Released
Status in Ubuntu on IBM z Systems:
  Fix Released
Status in irqbalance package in Ubuntu:
  Opinion
Status in ubuntu-meta package in Ubuntu:
  Fix Released

Bug description:
  as per https://github.com/pop-os/default-settings/issues/60

  Distribution (run cat /etc/os-release):

  $ cat /etc/os-release
  NAME="Pop!_OS"
  VERSION="19.04"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Pop!_OS 19.04"
  VERSION_ID="19.04"
  HOME_URL="https://system76.com/pop;
  SUPPORT_URL="http://support.system76.com;
  BUG_REPORT_URL="https://github.com/pop-os/pop/issues;
  PRIVACY_POLICY_URL="https://system76.com/privacy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  Related Application and/or Package Version (run apt policy $PACKAGE
  NAME):

  $ apt policy irqbalance
  irqbalance:
  Installed: 1.5.0-3ubuntu1
  Candidate: 1.5.0-3ubuntu1
  Version table:
  *** 1.5.0-3ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages
  100 /var/lib/dpkg/status

  $ apt rdepends irqbalance
  irqbalance
  Reverse Depends:
  Recommends: ubuntu-standard
  gce-compute-image-packages

  Issue/Bug Description:

  as per konkor/cpufreq#48 and
  http://konkor.github.io/cpufreq/faq/#irqbalance-detected

  irqbalance is technically not needed on desktop systems (supposedly it
  is mainly for servers), and may actually reduce performance and power
  savings. It appears to provide benefits only to server environments
  that have relatively-constant loading. If it is truly a server-
  oriented package, then it shouldn't be installed by default on a
  desktop/laptop system and shouldn't be included in desktop OS images.

  Steps to reproduce (if you know):

  This is potentially an issue with all default installs.

  Expected behavior:

  n/a

  Other Notes:

  I can safely remove it via "sudo apt purge irqbalance" without any
  apparent adverse side-effects. If someone is running a situation where
  they need it, then they always have the option of installing it from
  the repositories.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1833322/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1833322] Re: Please consider no more having irqbalance enabled by default (per image/use-case/TBD)

[Frank Heimes]

[Please ignore comment#35 - this was caused by a BZ-to-LP-bridge issue
...]

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1833322

Title:
  Please consider no more having irqbalance enabled by default (per
  image/use-case/TBD)

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in irqbalance package in Ubuntu:
  Confirmed
Status in ubuntu-meta package in Ubuntu:
  Confirmed

Bug description:
  as per https://github.com/pop-os/default-settings/issues/60

  Distribution (run cat /etc/os-release):

  $ cat /etc/os-release
  NAME="Pop!_OS"
  VERSION="19.04"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Pop!_OS 19.04"
  VERSION_ID="19.04"
  HOME_URL="https://system76.com/pop;
  SUPPORT_URL="http://support.system76.com;
  BUG_REPORT_URL="https://github.com/pop-os/pop/issues;
  PRIVACY_POLICY_URL="https://system76.com/privacy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  Related Application and/or Package Version (run apt policy $PACKAGE
  NAME):

  $ apt policy irqbalance
  irqbalance:
  Installed: 1.5.0-3ubuntu1
  Candidate: 1.5.0-3ubuntu1
  Version table:
  *** 1.5.0-3ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages
  100 /var/lib/dpkg/status

  $ apt rdepends irqbalance
  irqbalance
  Reverse Depends:
  Recommends: ubuntu-standard
  gce-compute-image-packages

  Issue/Bug Description:

  as per konkor/cpufreq#48 and
  http://konkor.github.io/cpufreq/faq/#irqbalance-detected

  irqbalance is technically not needed on desktop systems (supposedly it
  is mainly for servers), and may actually reduce performance and power
  savings. It appears to provide benefits only to server environments
  that have relatively-constant loading. If it is truly a server-
  oriented package, then it shouldn't be installed by default on a
  desktop/laptop system and shouldn't be included in desktop OS images.

  Steps to reproduce (if you know):

  This is potentially an issue with all default installs.

  Expected behavior:

  n/a

  Other Notes:

  I can safely remove it via "sudo apt purge irqbalance" without any
  apparent adverse side-effects. If someone is running a situation where
  they need it, then they always have the option of installing it from
  the repositories.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1833322] Re: Consider removing irqbalance from default install on desktop images

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1833322

Title:
  Consider removing irqbalance from default install on desktop images

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in irqbalance package in Ubuntu:
  Confirmed
Status in ubuntu-meta package in Ubuntu:
  Confirmed

Bug description:
  as per https://github.com/pop-os/default-settings/issues/60

  Distribution (run cat /etc/os-release):

  $ cat /etc/os-release
  NAME="Pop!_OS"
  VERSION="19.04"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Pop!_OS 19.04"
  VERSION_ID="19.04"
  HOME_URL="https://system76.com/pop;
  SUPPORT_URL="http://support.system76.com;
  BUG_REPORT_URL="https://github.com/pop-os/pop/issues;
  PRIVACY_POLICY_URL="https://system76.com/privacy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  Related Application and/or Package Version (run apt policy $PACKAGE
  NAME):

  $ apt policy irqbalance
  irqbalance:
  Installed: 1.5.0-3ubuntu1
  Candidate: 1.5.0-3ubuntu1
  Version table:
  *** 1.5.0-3ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages
  100 /var/lib/dpkg/status

  $ apt rdepends irqbalance
  irqbalance
  Reverse Depends:
  Recommends: ubuntu-standard
  gce-compute-image-packages

  Issue/Bug Description:

  as per konkor/cpufreq#48 and
  http://konkor.github.io/cpufreq/faq/#irqbalance-detected

  irqbalance is technically not needed on desktop systems (supposedly it
  is mainly for servers), and may actually reduce performance and power
  savings. It appears to provide benefits only to server environments
  that have relatively-constant loading. If it is truly a server-
  oriented package, then it shouldn't be installed by default on a
  desktop/laptop system and shouldn't be included in desktop OS images.

  Steps to reproduce (if you know):

  This is potentially an issue with all default installs.

  Expected behavior:

  n/a

  Other Notes:

  I can safely remove it via "sudo apt purge irqbalance" without any
  apparent adverse side-effects. If someone is running a situation where
  they need it, then they always have the option of installing it from
  the repositories.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1833322] Re: Consider removing irqbalance from default install on desktop images

[Frank Heimes]

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-z-systems
 Assignee: (unassigned) => bugproxy (bugproxy)

** Tags added: reverse-proxy-bugzilla

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to ubuntu-meta in Ubuntu.
https://bugs.launchpad.net/bugs/1833322

Title:
  Consider removing irqbalance from default install on desktop images

Status in Ubuntu on IBM z Systems:
  New
Status in irqbalance package in Ubuntu:
  Confirmed
Status in ubuntu-meta package in Ubuntu:
  Confirmed

Bug description:
  as per https://github.com/pop-os/default-settings/issues/60

  Distribution (run cat /etc/os-release):

  $ cat /etc/os-release
  NAME="Pop!_OS"
  VERSION="19.04"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Pop!_OS 19.04"
  VERSION_ID="19.04"
  HOME_URL="https://system76.com/pop;
  SUPPORT_URL="http://support.system76.com;
  BUG_REPORT_URL="https://github.com/pop-os/pop/issues;
  PRIVACY_POLICY_URL="https://system76.com/privacy;
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  Related Application and/or Package Version (run apt policy $PACKAGE
  NAME):

  $ apt policy irqbalance
  irqbalance:
  Installed: 1.5.0-3ubuntu1
  Candidate: 1.5.0-3ubuntu1
  Version table:
  *** 1.5.0-3ubuntu1 500
  500 http://us.archive.ubuntu.com/ubuntu disco/main amd64 Packages
  100 /var/lib/dpkg/status

  $ apt rdepends irqbalance
  irqbalance
  Reverse Depends:
  Recommends: ubuntu-standard
  gce-compute-image-packages

  Issue/Bug Description:

  as per konkor/cpufreq#48 and
  http://konkor.github.io/cpufreq/faq/#irqbalance-detected

  irqbalance is technically not needed on desktop systems (supposedly it
  is mainly for servers), and may actually reduce performance and power
  savings. It appears to provide benefits only to server environments
  that have relatively-constant loading. If it is truly a server-
  oriented package, then it shouldn't be installed by default on a
  desktop/laptop system and shouldn't be included in desktop OS images.

  Steps to reproduce (if you know):

  This is potentially an issue with all default installs.

  Expected behavior:

  n/a

  Other Notes:

  I can safely remove it via "sudo apt purge irqbalance" without any
  apparent adverse side-effects. If someone is running a situation where
  they need it, then they always have the option of installing it from
  the repositories.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1833322/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 2037569] Re: udev issues with mantic beta

[Frank Heimes]

Hi Dan, I've took the manytic daily from yesterday (Oct 3rd) and checked if the 
updated udisks2 package is in - which is the case - and gave it a try.
I did multiple different installations - all with DASDs, on LPAR and on z/VM. 
Installations with a single DASD or with multiple DASDs (even combining them to 
a bigger disk using LVM), and I didn't faced udev issues anymore. I checked 
with top during the installation as well as after the post-install reboot was 
completed -- all good.

So many thanks for your fix and upload on this (and Seb's review) !

** Changed in: ubuntu-z-systems
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libblockdev in Ubuntu.
https://bugs.launchpad.net/bugs/2037569

Title:
  udev issues with mantic beta

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in libblockdev package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in udisks2 package in Ubuntu:
  Fix Released

Bug description:
  While installing mantic beta (on s390x, LPAR and z/VM - but this might not be 
architecture specific) I faced issues with udev.
  In my installation I've updated the installer to "edge/lp-2009141" (subiquity 
 22.02.2+git1762.1b1ee6f4  5164).

  During my installations I first noticed bad response times in case of
  dealing with devices (like enabling new devices with chzdev). chzdev
  is used during the installation, hence the installation procedure is
  also affected by this. (I mainly notice this issue in case of DASD
  ECKD disk enablements.)

  But even after after a successful (but due to this issue less snappier) 
installation, means after the post-install reboot, in the installed system I 
can find several udev related processes, like:
69448 root  20   0   31280  11944   2560 S  39.2   0.0   2:51.67 
(udev-worker)
  509 root  20   0   31276  13812   4600 S  20.6   0.0   2:07.76 
systemd-udevd
  893 root  20   0  469016  13544  10496 R  17.3   0.0   1:43.53 
udisksd  
1 root  20   0  168664  12748   8396 S  16.3   0.0   1:40.47 
systemd  
  which is not only unusual, but (as one can see) they consume quite some 
resources.
  Even the remote ssh into that system is impacted by this high load.

  So far I only see this in mantic.
  I tried 20.04.3 as well as lunar, but both do not seem to be affected by this 
udev problem.
  I neither face the bad response on device enablement, nor can see any udev 
related processes still running after post-install-reboot in the installed 
system.

  (Sometimes I could also see a growing log file 'syslog').

  I cannot say yet what is causing this, but since I see 'systemd-udevd'
  as prominent process in top, I'll first of all mark this as affecting
  systemd-udevd (or systemd).

  I've attached the outcome of some more investigations I did ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 2037569] Re: udev issues with mantic beta

[Frank Heimes]

I think it's caused by udisksctl here:
https://github.com/storaged-project/udisks/blob/c7027d888c00381851d918f33a13102e7b86e188/tools/udisksctl.c#L2810C1-L2811C75
due to its repeating monitor messages:
udisksctl monitor
** (udisksctl monitor:424911): WARNING **: 11:14:33.100: 
(udisksctl.c:2811):monitor_on_interface_proxy_properties_changed: runtime check 
failed: (g_strv_length ((gchar **) invalidated_properties) == 0)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to udisks2 in Ubuntu.
https://bugs.launchpad.net/bugs/2037569

Title:
  udev issues with mantic beta

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in udisks2 package in Ubuntu:
  Confirmed

Bug description:
  While installing mantic beta (on s390x, LPAR and z/VM - but this might not be 
architecture specific) I faced issues with udev.
  In my installation I've updated the installer to "edge/lp-2009141" (subiquity 
 22.02.2+git1762.1b1ee6f4  5164).

  During my installations I first noticed bad response times in case of
  dealing with devices (like enabling new devices with chzdev). chzdev
  is used during the installation, hence the installation procedure is
  also affected by this. (I mainly notice this issue in case of DASD
  ECKD disk enablements.)

  But even after after a successful (but due to this issue less snappier) 
installation, means after the post-install reboot, in the installed system I 
can find several udev related processes, like:
69448 root  20   0   31280  11944   2560 S  39.2   0.0   2:51.67 
(udev-worker)
  509 root  20   0   31276  13812   4600 S  20.6   0.0   2:07.76 
systemd-udevd
  893 root  20   0  469016  13544  10496 R  17.3   0.0   1:43.53 
udisksd  
1 root  20   0  168664  12748   8396 S  16.3   0.0   1:40.47 
systemd  
  which is not only unusual, but (as one can see) they consume quite some 
resources.
  Even the remote ssh into that system is impacted by this high load.

  So far I only see this in mantic.
  I tried 20.04.3 as well as lunar, but both do not seem to be affected by this 
udev problem.
  I neither face the bad response on device enablement, nor can see any udev 
related processes still running after post-install-reboot in the installed 
system.

  (Sometimes I could also see a growing log file 'syslog').

  I cannot say yet what is causing this, but since I see 'systemd-udevd'
  as prominent process in top, I'll first of all mark this as affecting
  systemd-udevd (or systemd).

  I've attached the outcome of some more investigations I did ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 2037569] Re: udev issues with mantic beta

[Frank Heimes]

Today I did some more tests and investigations.

First of all I moved to the new mantic ISO image (20230928) that improved 
things quite a lot!
The installation (on z/VM so far) is again very snappy and quick,
incl. the enablement of a DASD device in the zDev activation screen.

At the end of the installation, before hitting 'Reboot now' I went to
the console and had a look at top to see if udev related processes are
active, but I couldn't identify any:

top - 10:47:51 up 9 min,  2 users,  load average: 0.44, 0.41, 0.20
Tasks: 137 total,   1 running, 136 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st 
MiB Mem :   3988.9 total,214.3 free,   1957.6 used,   3233.2 buff/cache 
MiB Swap:  0.0 total,  0.0 free,  0.0 used.   2031.3 avail Mem 
PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND  

  15026 root  20   08788   4864   2816 R   0.7   0.1   0:00.28 top  

   1439 root  20   0  129824  74216  21376 S   0.3   1.8   0:03.76 
/snap/subiquity/5183/usr/bin/python3.10 /snap/subiquity/518+ 
   1441 root  20   0  129788  74312  21376 S   0.3   1.8   0:03.57 
/snap/subiquity/5183/usr/bin/python3.10 /snap/subiquity/518+ 
   2381 root  20   0   12216   5760   4864 S   0.3   0.1   0:00.10 sudo 
snap run subiquity  
   2383 root  20   0  206204  77680  21632 S   0.3   1.9   0:04.96 
/snap/subiquity/5183/usr/bin/python3.10 -m subiquity 
  1 root  20   0  103300  13676   8940 S   0.0   0.3   0:03.49 
/sbin/init ---   
  2 root  20   0   0  0  0 S   0.0   0.0   0:00.00 
[kthreadd]   
  3 root   0 -20   0  0  0 I   0.0   0.0   0:00.00 [rcu_gp] 

  4 root   0 -20   0  0  0 I   0.0   0.0   0:00.00 
[rcu_par_gp] 
  5 root   0 -20   0  0  0 I   0.0   0.0   0:00.00 
[slub_flushwq]   
  6 root   0 -20   0  0  0 I   0.0   0.0   0:00.00 [netns]  

  8 root   0 -20   0  0  0 I   0.0   0.0   0:00.00 
[kworker/0:0H-events_highpri]
  9 root  20   0   0  0  0 I   0.0   0.0   0:00.00 
[kworker/0:1-cgroup_destroy] 
 10 root  20   0   0  0  0 I   0.0   0.0   0:01.11 
[kworker/u128:0-events_unbound]  
 11 root   0 -20   0  0  0 I   0.0   0.0   0:00.00 
[mm_percpu_wq]   
 12 root  20   0   0  0  0 I   0.0   0.0   0:00.00 
[rcu_tasks_rude_kthread] 
 13 root  20   0   0  0  0 I   0.0   0.0   0:00.00 
[rcu_tasks_trace_kthread]   

Then, having the post-install reboot completed, and looking at top, I
can observe the udev activities:

top - 10:55:26 up 6 min,  1 user,  load average: 2.16, 1.75, 0.84
Tasks: 108 total,   5 running, 103 sleeping,   0 stopped,   0 zombie
%Cpu(s): 18.1 us, 22.7 sy,  0.0 ni, 48.8 id,  8.1 wa,  0.6 hi,  0.8 si,  0.9 st 
MiB Mem :   3988.9 total,   3274.2 free,271.4 used,539.0 buff/cache 
MiB Swap:  0.0 total,  0.0 free,  0.0 used.   3717.5 avail Mem 

PID USER  PR  NIVIRTRESSHR S  %CPU  %MEM TIME+ COMMAND  

   1177 root  20   0   24884   5724   2560 R  33.2   0.1   1:50.24 
(udev-worker)
  1 root  20   0  168592  12912   8432 R  20.6   0.3   1:07.93 
/sbin/init   
690 root  20   0  467964  13112  10752 D  15.6   0.3   0:52.91 
/usr/libexec/udisks2/udisksd 
660 message+  20   09328   4480   3840 S  14.6   0.1   0:52.68 
@dbus-daemon --system --address=systemd: --nofork --nopidfile -+ 
  16285 ubuntu20   0   18004   9984   8448 S  10.6   0.2   0:33.06 
/lib/systemd/systemd --user  
385 root  20   0   24764   7492   4676 S   9.3   0.2   0:30.40 
/lib/systemd/systemd-udevd   
373 root  rt   0  288412  26368   8064 S   6.6   0.6   0:21.50 
/sbin/multipathd -d -s   
686 root  20   0   16096   7424   6528 S   4.0   0.2   0:13.20 
/lib/systemd/systemd-logind  
681 root  20   0 2066332  34480  21248 S   1.7   0.8   

[Desktop-packages] [Bug 2037569] Re: udev issues with mantic beta

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: New => Confirmed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to udisks2 in Ubuntu.
https://bugs.launchpad.net/bugs/2037569

Title:
  udev issues with mantic beta

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed
Status in udisks2 package in Ubuntu:
  Confirmed

Bug description:
  While installing mantic beta (on s390x, LPAR and z/VM - but this might not be 
architecture specific) I faced issues with udev.
  In my installation I've updated the installer to "edge/lp-2009141" (subiquity 
 22.02.2+git1762.1b1ee6f4  5164).

  During my installations I first noticed bad response times in case of
  dealing with devices (like enabling new devices with chzdev). chzdev
  is used during the installation, hence the installation procedure is
  also affected by this. (I mainly notice this issue in case of DASD
  ECKD disk enablements.)

  But even after after a successful (but due to this issue less snappier) 
installation, means after the post-install reboot, in the installed system I 
can find several udev related processes, like:
69448 root  20   0   31280  11944   2560 S  39.2   0.0   2:51.67 
(udev-worker)
  509 root  20   0   31276  13812   4600 S  20.6   0.0   2:07.76 
systemd-udevd
  893 root  20   0  469016  13544  10496 R  17.3   0.0   1:43.53 
udisksd  
1 root  20   0  168664  12748   8396 S  16.3   0.0   1:40.47 
systemd  
  which is not only unusual, but (as one can see) they consume quite some 
resources.
  Even the remote ssh into that system is impacted by this high load.

  So far I only see this in mantic.
  I tried 20.04.3 as well as lunar, but both do not seem to be affected by this 
udev problem.
  I neither face the bad response on device enablement, nor can see any udev 
related processes still running after post-install-reboot in the installed 
system.

  (Sometimes I could also see a growing log file 'syslog').

  I cannot say yet what is causing this, but since I see 'systemd-udevd'
  as prominent process in top, I'll first of all mark this as affecting
  systemd-udevd (or systemd).

  I've attached the outcome of some more investigations I did ...

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/2037569/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

[Frank Heimes]

libnettle8 3.8.1-2 finally landed in kinetic,
hence updating the status to Fix Released and closing this ticket.

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

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nettle in Ubuntu.
https://bugs.launchpad.net/bugs/1959469

Title:
  [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in nettle package in Ubuntu:
  Fix Released
Status in nettle package in Debian:
  New

Bug description:
  Upgrade nettle to latest version >= 3.7.4 (crypto)

  Description

  Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for
  Crypto Libraries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

[Frank Heimes]

Meanwhile libnettle8 3.8.1-2 landed in kinetic-proposed, hence updating status 
to Fix Committed.
(thx to Magnus Holmgren)

** Changed in: nettle (Ubuntu)
   Status: In Progress => Fix Committed

** Changed in: ubuntu-z-systems
   Status: In Progress => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nettle in Ubuntu.
https://bugs.launchpad.net/bugs/1959469

Title:
  [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in nettle package in Ubuntu:
  Fix Committed
Status in nettle package in Debian:
  New

Bug description:
  Upgrade nettle to latest version >= 3.7.4 (crypto)

  Description

  Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for
  Crypto Libraries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

[Frank Heimes]

** Bug watch added: Debian Bug tracker #1015346
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015346

** Also affects: nettle (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1015346
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nettle in Ubuntu.
https://bugs.launchpad.net/bugs/1959469

Title:
  [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

Status in Ubuntu on IBM z Systems:
  In Progress
Status in nettle package in Ubuntu:
  In Progress
Status in nettle package in Debian:
  Unknown

Bug description:
  Upgrade nettle to latest version >= 3.7.4 (crypto)

  Description

  Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for
  Crypto Libraries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

[Frank Heimes]

Here is the debdiff for this version bump (from
3.7.3-1build2_to_3.8-0ubuntu1).

** Patch added: "debdiff_nettle_3.7.3-1build2_to_3.8-0ubuntu1.diff"
   
https://bugs.launchpad.net/ubuntu/+source/nettle/+bug/1959469/+attachment/5603732/+files/debdiff_nettle_3.7.3-1build2_to_3.8-0ubuntu1.diff

** Changed in: nettle (Ubuntu)
   Status: New => In Progress

** Changed in: ubuntu-z-systems
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nettle in Ubuntu.
https://bugs.launchpad.net/bugs/1959469

Title:
  [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

Status in Ubuntu on IBM z Systems:
  In Progress
Status in nettle package in Ubuntu:
  In Progress

Bug description:
  Upgrade nettle to latest version >= 3.7.4 (crypto)

  Description

  Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for
  Crypto Libraries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

[Frank Heimes]

Since the symbol files are a bit tricky in this case (because the incl.
arch-specific entries), I'm uploading them here separately, too.

** Attachment added: "updated_symbols.tgz"
   
https://bugs.launchpad.net/ubuntu/+source/nettle/+bug/1959469/+attachment/5603726/+files/updated_symbols.tgz

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nettle in Ubuntu.
https://bugs.launchpad.net/bugs/1959469

Title:
  [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

Status in Ubuntu on IBM z Systems:
  New
Status in nettle package in Ubuntu:
  New

Bug description:
  Upgrade nettle to latest version >= 3.7.4 (crypto)

  Description

  Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for
  Crypto Libraries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1959469] Re: [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

[Frank Heimes]

** Information type changed from Private to Public

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nettle in Ubuntu.
https://bugs.launchpad.net/bugs/1959469

Title:
  [22.10 FEAT] Upgrade nettle to latest version >= 3.7.4 (crypto)

Status in Ubuntu on IBM z Systems:
  New
Status in nettle package in Ubuntu:
  New

Bug description:
  Upgrade nettle to latest version >= 3.7.4 (crypto)

  Description

  Upgrade nettle to latest version >= 3.7.4 to provide CPACF Support for
  Crypto Libraries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1959469/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1943818] Re: mesa built with -O3 on ppc64el has broken EGL

[Frank Heimes]

** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to mesa in Ubuntu.
https://bugs.launchpad.net/bugs/1943818

Title:
  mesa built with -O3 on ppc64el has broken EGL

Status in Mesa:
  Unknown
Status in The Ubuntu-power-systems project:
  New
Status in gcc-11 package in Ubuntu:
  New
Status in mesa package in Ubuntu:
  New

Bug description:
  If mesa is built with -O3 then EGL will fail with:

  libEGL warning: DRI2: failed to create any config

  this can be easily reproduced by building libepoxy which then runs a
  series of tests.

  The same is fine on amd64, and also ppc64el is fine with gcc-10 and
  -O3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/mesa/+bug/1943818/+subscriptions


-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1913388] Re: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to clucene-core in Ubuntu.
https://bugs.launchpad.net/bugs/1913388

Title:
  clucene-core: please pull in patch to stabilize API on s390x during
  upgrade to glibc 2.33

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in clucene-core package in Ubuntu:
  Fix Released

Bug description:
  On s390x, the type float_t has historically been defined as double for
  no good reason, yet with unexpected and unnecessary impact on
  performance in some scenarios. The upcoming glibc release 2.33 will be
  a first step towards cleaning that up, which will change float_t to
  become float on s390x when compiling C++ code, such as in clucene-
  core. That would break the ABI of clucene-core on s390x for existing
  binaries.

  Today, clucene-core uses float_t for some parameters in its API; that
  type is defined as double on s390x today. Together with gcc's default
  behavior, that contradicts the C standard. To get to a more sane
  combination, the upcoming glibc release 2.33 will change float_t to
  become float on s390x (with some exceptions when compiling C code,
  which do not apply for clucene-core). To my knowledge, glibc 2.33 is a
  candidate for inclusion in Ubuntu 21.04.

  To avoid breaking the API of clucene-core in the process, I have
  prepared a trivial patch that fixes clucene-core's API to always use
  double instead of float_t on s390x. That patch effectively persists
  the current de-facto API on s390x, without changes for other
  architectures. Note that using float_t in an API is generally "not a
  great idea", because that type can have different definitions even
  with the same compiler and glibc version on the same system (e.g., on
  32-bit x86, when switching between SSE and x87 FP ops).

  Patch submitted in https://sourceforge.net/p/clucene/bugs/233/ and 
https://sourceforge.net/p/clucene/mailman/message/37153930/
  yet upstream clucene is effectively unmaintained.

  If Ubuntu 21.04 adopts glibc 2.33, please consider pulling in this
  patch in clucene-core.

  Related request for ImageMagick:
  https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1913268

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1913388/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1913388] Re: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to clucene-core in Ubuntu.
https://bugs.launchpad.net/bugs/1913388

Title:
  clucene-core: please pull in patch to stabilize API on s390x during
  upgrade to glibc 2.33

Status in Ubuntu on IBM z Systems:
  In Progress
Status in clucene-core package in Ubuntu:
  In Progress

Bug description:
  On s390x, the type float_t has historically been defined as double for
  no good reason, yet with unexpected and unnecessary impact on
  performance in some scenarios. The upcoming glibc release 2.33 will be
  a first step towards cleaning that up, which will change float_t to
  become float on s390x when compiling C++ code, such as in clucene-
  core. That would break the ABI of clucene-core on s390x for existing
  binaries.

  Today, clucene-core uses float_t for some parameters in its API; that
  type is defined as double on s390x today. Together with gcc's default
  behavior, that contradicts the C standard. To get to a more sane
  combination, the upcoming glibc release 2.33 will change float_t to
  become float on s390x (with some exceptions when compiling C code,
  which do not apply for clucene-core). To my knowledge, glibc 2.33 is a
  candidate for inclusion in Ubuntu 21.04.

  To avoid breaking the API of clucene-core in the process, I have
  prepared a trivial patch that fixes clucene-core's API to always use
  double instead of float_t on s390x. That patch effectively persists
  the current de-facto API on s390x, without changes for other
  architectures. Note that using float_t in an API is generally "not a
  great idea", because that type can have different definitions even
  with the same compiler and glibc version on the same system (e.g., on
  32-bit x86, when switching between SSE and x87 FP ops).

  Patch submitted in https://sourceforge.net/p/clucene/bugs/233/ and 
https://sourceforge.net/p/clucene/mailman/message/37153930/
  yet upstream clucene is effectively unmaintained.

  If Ubuntu 21.04 adopts glibc 2.33, please consider pulling in this
  patch in clucene-core.

  Related request for ImageMagick:
  https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1913268

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1913388/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1913388] Re: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: In Progress => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to clucene-core in Ubuntu.
https://bugs.launchpad.net/bugs/1913388

Title:
  clucene-core: please pull in patch to stabilize API on s390x during
  upgrade to glibc 2.33

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in clucene-core package in Ubuntu:
  Fix Released

Bug description:
  On s390x, the type float_t has historically been defined as double for
  no good reason, yet with unexpected and unnecessary impact on
  performance in some scenarios. The upcoming glibc release 2.33 will be
  a first step towards cleaning that up, which will change float_t to
  become float on s390x when compiling C++ code, such as in clucene-
  core. That would break the ABI of clucene-core on s390x for existing
  binaries.

  Today, clucene-core uses float_t for some parameters in its API; that
  type is defined as double on s390x today. Together with gcc's default
  behavior, that contradicts the C standard. To get to a more sane
  combination, the upcoming glibc release 2.33 will change float_t to
  become float on s390x (with some exceptions when compiling C code,
  which do not apply for clucene-core). To my knowledge, glibc 2.33 is a
  candidate for inclusion in Ubuntu 21.04.

  To avoid breaking the API of clucene-core in the process, I have
  prepared a trivial patch that fixes clucene-core's API to always use
  double instead of float_t on s390x. That patch effectively persists
  the current de-facto API on s390x, without changes for other
  architectures. Note that using float_t in an API is generally "not a
  great idea", because that type can have different definitions even
  with the same compiler and glibc version on the same system (e.g., on
  32-bit x86, when switching between SSE and x87 FP ops).

  Patch submitted in https://sourceforge.net/p/clucene/bugs/233/ and 
https://sourceforge.net/p/clucene/mailman/message/37153930/
  yet upstream clucene is effectively unmaintained.

  If Ubuntu 21.04 adopts glibc 2.33, please consider pulling in this
  patch in clucene-core.

  Related request for ImageMagick:
  https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1913268

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1913388/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1913388] Re: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Triaged => In Progress

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to clucene-core in Ubuntu.
https://bugs.launchpad.net/bugs/1913388

Title:
  clucene-core: please pull in patch to stabilize API on s390x during
  upgrade to glibc 2.33

Status in Ubuntu on IBM z Systems:
  In Progress
Status in clucene-core package in Ubuntu:
  In Progress

Bug description:
  On s390x, the type float_t has historically been defined as double for
  no good reason, yet with unexpected and unnecessary impact on
  performance in some scenarios. The upcoming glibc release 2.33 will be
  a first step towards cleaning that up, which will change float_t to
  become float on s390x when compiling C++ code, such as in clucene-
  core. That would break the ABI of clucene-core on s390x for existing
  binaries.

  Today, clucene-core uses float_t for some parameters in its API; that
  type is defined as double on s390x today. Together with gcc's default
  behavior, that contradicts the C standard. To get to a more sane
  combination, the upcoming glibc release 2.33 will change float_t to
  become float on s390x (with some exceptions when compiling C code,
  which do not apply for clucene-core). To my knowledge, glibc 2.33 is a
  candidate for inclusion in Ubuntu 21.04.

  To avoid breaking the API of clucene-core in the process, I have
  prepared a trivial patch that fixes clucene-core's API to always use
  double instead of float_t on s390x. That patch effectively persists
  the current de-facto API on s390x, without changes for other
  architectures. Note that using float_t in an API is generally "not a
  great idea", because that type can have different definitions even
  with the same compiler and glibc version on the same system (e.g., on
  32-bit x86, when switching between SSE and x87 FP ops).

  Patch submitted in https://sourceforge.net/p/clucene/bugs/233/ and 
https://sourceforge.net/p/clucene/mailman/message/37153930/
  yet upstream clucene is effectively unmaintained.

  If Ubuntu 21.04 adopts glibc 2.33, please consider pulling in this
  patch in clucene-core.

  Related request for ImageMagick:
  https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1913268

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1913388/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1913388] Re: clucene-core: please pull in patch to stabilize API on s390x during upgrade to glibc 2.33

[Frank Heimes]

Please notice that clucene (clucene-core) belongs to Ubuntu Desktop
(ubuntu-desktop).

** Package changed: linux (Ubuntu) => clucene-core (Ubuntu)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to clucene-core in Ubuntu.
https://bugs.launchpad.net/bugs/1913388

Title:
  clucene-core: please pull in patch to stabilize API on s390x during
  upgrade to glibc 2.33

Status in Ubuntu on IBM z Systems:
  Triaged
Status in clucene-core package in Ubuntu:
  Incomplete

Bug description:
  On s390x, the type float_t has historically been defined as double for
  no good reason, yet with unexpected and unnecessary impact on
  performance in some scenarios. The upcoming glibc release 2.33 will be
  a first step towards cleaning that up, which will change float_t to
  become float on s390x when compiling C++ code, such as in clucene-
  core. That would break the ABI of clucene-core on s390x for existing
  binaries.

  Today, clucene-core uses float_t for some parameters in its API; that
  type is defined as double on s390x today. Together with gcc's default
  behavior, that contradicts the C standard. To get to a more sane
  combination, the upcoming glibc release 2.33 will change float_t to
  become float on s390x (with some exceptions when compiling C code,
  which do not apply for clucene-core). To my knowledge, glibc 2.33 is a
  candidate for inclusion in Ubuntu 21.04.

  To avoid breaking the API of clucene-core in the process, I have
  prepared a trivial patch that fixes clucene-core's API to always use
  double instead of float_t on s390x. That patch effectively persists
  the current de-facto API on s390x, without changes for other
  architectures. Note that using float_t in an API is generally "not a
  great idea", because that type can have different definitions even
  with the same compiler and glibc version on the same system (e.g., on
  32-bit x86, when switching between SSE and x87 FP ops).

  Patch submitted in https://sourceforge.net/p/clucene/bugs/233/ and 
https://sourceforge.net/p/clucene/mailman/message/37153930/
  yet upstream clucene is effectively unmaintained.

  If Ubuntu 21.04 adopts glibc 2.33, please consider pulling in this
  patch in clucene-core.

  Related request for ImageMagick:
  https://bugs.launchpad.net/ubuntu/+source/imagemagick/+bug/1913268

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1913388/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

[Frank Heimes]

** Tags added: ssc

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1794478

Title:
  Automatic ipv4 not assigned to bond interface is manual ipv6 is
  assigned to it

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Released

Bug description:
  [Impact]

  In case creating bond interface, IPv4 address is not automatically
  assigned when IPv6 has manual setting.

  [Test Case]

  1. create 18.04.4 instance, network-manager version is 1.10.6-2ubuntu.1.2 as 
original description.
  2. ipv6 manual, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method manual ipv6.addresses 
fe81::ff:fe97:a27f/64;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5;
  sudo nmcli c s bond0
  ##
  3. ipv6 auto, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method auto;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5

  sudo nmcli c s bond0
  ##

  when run #3, it is working, but with #2, it is not working.

  [Potential Regression]

  Actually nothing special. fix just remove if statement. but it needs
  Network Manager restarted.

  [Other informations]

  After upstream fix, it is working fine with #2 and #3 above.

  * Upstream bug and fix:

  https://bugzilla.redhat.com/show_bug.cgi?id=1575944
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

  $ rmadison network-manager
  ==> network-manager | 1.10.6-2ubuntu1.2   | bionic-updates
  network-manager | 1.20.4-2ubuntu2.2   | eoan-updates
  network-manager | 1.22.4-1ubuntu2 | focal

  [Original description]

  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.

  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux

  Machine Type = s390x

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface

  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto

  From /var/log/syslog, we can see ip got assigned:

  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 
10.2.3.1
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1

  

[Desktop-packages] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

[Frank Heimes]

Thx 'abhir...@in.ibm.com' for verification - the tags are set to done.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1794478

Title:
  Automatic ipv4 not assigned to bond interface is manual ipv6 is
  assigned to it

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

  In case creating bond interface, IPv4 address is not automatically
  assigned when IPv6 has manual setting.

  [Test Case]

  1. create 18.04.4 instance, network-manager version is 1.10.6-2ubuntu.1.2 as 
original description.
  2. ipv6 manual, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method manual ipv6.addresses 
fe81::ff:fe97:a27f/64;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5;
  sudo nmcli c s bond0
  ##
  3. ipv6 auto, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method auto;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5

  sudo nmcli c s bond0
  ##

  when run #3, it is working, but with #2, it is not working.

  [Potential Regression]

  Actually nothing special. fix just remove if statement. but it needs
  Network Manager restarted.

  [Other informations]

  After upstream fix, it is working fine with #2 and #3 above.

  * Upstream bug and fix:

  https://bugzilla.redhat.com/show_bug.cgi?id=1575944
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

  $ rmadison network-manager
  ==> network-manager | 1.10.6-2ubuntu1.2   | bionic-updates
  network-manager | 1.20.4-2ubuntu2.2   | eoan-updates
  network-manager | 1.22.4-1ubuntu2 | focal

  [Original description]

  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.

  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux

  Machine Type = s390x

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface

  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto

  From /var/log/syslog, we can see ip got assigned:

  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 
10.2.3.1
  Sep 26 06:26:26 NetworkTest 

[Desktop-packages] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

[Frank Heimes]

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

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1794478

Title:
  Automatic ipv4 not assigned to bond interface is manual ipv6 is
  assigned to it

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Committed

Bug description:
  [Impact]

  In case creating bond interface, IPv4 address is not automatically
  assigned when IPv6 has manual setting.

  [Test Case]

  1. create 18.04.4 instance, network-manager version is 1.10.6-2ubuntu.1.2 as 
original description.
  2. ipv6 manual, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method manual ipv6.addresses 
fe81::ff:fe97:a27f/64;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5;
  sudo nmcli c s bond0
  ##
  3. ipv6 auto, ipv4 auto
  ##
  sudo nmcli con add type bond con-name bond0 ifname bond0 mode active-backup;
  sudo nmcli con mod bond0 bond.options "downdelay=0, fail_over_mac=none, 
miimon=100, mode=active-backup,num_grat_arp=0, primary_reselect=always, 
updelay=0";
  sudo nmcli con mod bond0 ipv6.method auto;
  sudo nmcli con mod bond0 ipv4.method auto;
  sudo nmcli con add type bond-slave ifname ens34 master bond0;
  sudo nmcli con add type bond-slave ifname ens35 master bond0;
  sudo nmcli con mod bond0 +bond.options mii=100

  sleep 5

  sudo nmcli con up bond-slave-ens34
  sudo nmcli con up bond-slave-ens35
  sudo nmcli con up bond0;

  sleep 5

  sudo nmcli c s bond0
  ##

  when run #3, it is working, but with #2, it is not working.

  [Potential Regression]

  Actually nothing special. fix just remove if statement. but it needs
  Network Manager restarted.

  [Other informations]

  After upstream fix, it is working fine with #2 and #3 above.

  * Upstream bug and fix:

  https://bugzilla.redhat.com/show_bug.cgi?id=1575944
  https://gitlab.freedesktop.org/NetworkManager/NetworkManager/commit/f03ae35

  * Only affecting Bionic:

  $ git describe --contains f03ae35
  1.10.8~2

  $ rmadison network-manager
  ==> network-manager | 1.10.6-2ubuntu1.2   | bionic-updates
  network-manager | 1.20.4-2ubuntu2.2   | eoan-updates
  network-manager | 1.22.4-1ubuntu2 | focal

  [Original description]

  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.

  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux

  Machine Type = s390x

  ---Debugger---
  A debugger is not configured

  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface

  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto

  From /var/log/syslog, we can see ip got assigned:

  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 
10.2.3.1
  Sep 26 06:26:26 NetworkTest 

[Desktop-packages] [Bug 1694926] Re: Boost.Context and Boost.Coroutine not built on s390x

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Triaged => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to boost-defaults in Ubuntu.
https://bugs.launchpad.net/bugs/1694926

Title:
  Boost.Context and Boost.Coroutine not built on s390x

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in boost-defaults package in Ubuntu:
  Fix Committed
Status in boost1.67 package in Ubuntu:
  Won't Fix
Status in boost1.71 package in Ubuntu:
  Fix Released
Status in ceph package in Ubuntu:
  Triaged

Bug description:
  The Boost packaging currently excludes s390x support for Boost.Context
  and Boost.Coroutine; These are required to support Ceph >= 12.0.3.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1694926/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1790098] Re: vlan created on bond fails auto activation on updating parent network bond

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1790098

Title:
  vlan created on bond fails auto activation on updating parent network
  bond

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Released

Bug description:
  Auto activation of Vlan created over network-bond fails if bond is 
deactivated and reactivated.
   
  Contact Information = Abhiram Kulkarni(abhir...@in.ibm.com), Mandar 
Deshpande(manda...@in.ibm.com) 
   
  ---uname output---
  Linux S36MANDAR 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:23 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Created a network bond with static IP address (and no IPv6 address); 
active backup mode; ARP polling; single slave.

  2. Created a VLAN using said network bond with static IPv4 address
  (and no IPv6 address).

  3. Can ping from the appliance to a target on both links (the parent
  bond and the VLAN).

  4. Switched to another slave for the created bond

  5. Can still ping from the appliance to a target via the parent bond;
  however, cannot ping to the target via the VLAN.

  =
  Detailed steps:

  1. Initial setup:
  
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --  

  2. Create Netwrok-bond with one slave:
  
  root@S36MANDAR:~# nmcli c add type bond con-name mybond1 ifname mybond1 
ipv4.method disabled ipv6.method ignore
  Connection 'mybond1' (4b918a65-43a6-4ec3-b3c4-388ed52b116d) successfully 
added.

  root@S36MANDAR:~# nmcli con add type ethernet ifname enc1d40 master mybond1
  Connection 'bond-slave-enc1d40' (cfe4b245-3dda-4f45-b7b4-6d40d144a02f) 
successfully added.
  root@S36MANDAR:~# nmcli con up bond-slave-enc1d40
  Connection successfully activated (D-Bus active path: 
/org/freedesktop/NetworkManager/ActiveConnection/18)
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  enc1d40 
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --  

  3. Create vlan over mybond1:
  ===
  root@S36MANDAR:~# nmcli con add type vlan con-name vlanbond.100 ifname 
vlanbond.100 dev mybond1 id 100  ipv4.method disabled ipv6.method ignore
  Connection 'vlanbond.100' (e054df42-97a0-492b-b2c9-b9571077493e) successfully 
added.
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE
   
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  enc1d40   
   
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80   
   
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00   
   
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1   
   
  vlanbond.100e054df42-97a0-492b-b2c9-b9571077493e  vlan  
vlanbond.100 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --
   

  4. Reactivate bond : 
  =
  root@S36MANDAR:~# nmcli con up mybond1
  Connection successfully activated (master waiting for slaves) (D-Bus active 
path: /org/freedesktop/NetworkManager/ActiveConnection/30)

  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  enc1d40 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1 
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  --  
  encw18104ddeb38e-d5f7-3814-abb7-be50b8da874e  ethernet  --  
  vlanbond.100e054df42-97a0-492b-b2c9-b9571077493e  vlan  --  

  As is seen, vlan(vlanbond.100) did not get activated

  Now, if manually I make vlan connection up, it gets activated:

[Desktop-packages] [Bug 1790098] Re: vlan created on bond fails auto activation on updating parent network bond

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Won't Fix => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1790098

Title:
  vlan created on bond fails auto activation on updating parent network
  bond

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Committed

Bug description:
  Auto activation of Vlan created over network-bond fails if bond is 
deactivated and reactivated.
   
  Contact Information = Abhiram Kulkarni(abhir...@in.ibm.com), Mandar 
Deshpande(manda...@in.ibm.com) 
   
  ---uname output---
  Linux S36MANDAR 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:23 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Created a network bond with static IP address (and no IPv6 address); 
active backup mode; ARP polling; single slave.

  2. Created a VLAN using said network bond with static IPv4 address
  (and no IPv6 address).

  3. Can ping from the appliance to a target on both links (the parent
  bond and the VLAN).

  4. Switched to another slave for the created bond

  5. Can still ping from the appliance to a target via the parent bond;
  however, cannot ping to the target via the VLAN.

  =
  Detailed steps:

  1. Initial setup:
  
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --  

  2. Create Netwrok-bond with one slave:
  
  root@S36MANDAR:~# nmcli c add type bond con-name mybond1 ifname mybond1 
ipv4.method disabled ipv6.method ignore
  Connection 'mybond1' (4b918a65-43a6-4ec3-b3c4-388ed52b116d) successfully 
added.

  root@S36MANDAR:~# nmcli con add type ethernet ifname enc1d40 master mybond1
  Connection 'bond-slave-enc1d40' (cfe4b245-3dda-4f45-b7b4-6d40d144a02f) 
successfully added.
  root@S36MANDAR:~# nmcli con up bond-slave-enc1d40
  Connection successfully activated (D-Bus active path: 
/org/freedesktop/NetworkManager/ActiveConnection/18)
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  enc1d40 
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --  

  3. Create vlan over mybond1:
  ===
  root@S36MANDAR:~# nmcli con add type vlan con-name vlanbond.100 ifname 
vlanbond.100 dev mybond1 id 100  ipv4.method disabled ipv6.method ignore
  Connection 'vlanbond.100' (e054df42-97a0-492b-b2c9-b9571077493e) successfully 
added.
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE
   
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  enc1d40   
   
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80   
   
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00   
   
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1   
   
  vlanbond.100e054df42-97a0-492b-b2c9-b9571077493e  vlan  
vlanbond.100 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --
   

  4. Reactivate bond : 
  =
  root@S36MANDAR:~# nmcli con up mybond1
  Connection successfully activated (master waiting for slaves) (D-Bus active 
path: /org/freedesktop/NetworkManager/ActiveConnection/30)

  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  enc1d40 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1 
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  --  
  encw18104ddeb38e-d5f7-3814-abb7-be50b8da874e  ethernet  --  
  vlanbond.100e054df42-97a0-492b-b2c9-b9571077493e  vlan  --  

  As is seen, vlan(vlanbond.100) did not get activated

  Now, if manually I make vlan connection up, it gets activated:

 

[Desktop-packages] [Bug 1790098] Re: vlan created on bond fails auto activation on updating parent network bond

[Frank Heimes]

Since our focus is on netplan only, I'm changing the status to Won't
Fix.

** Changed in: ubuntu-z-systems
   Status: Incomplete => Won't Fix

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1790098

Title:
  vlan created on bond fails auto activation on updating parent network
  bond

Status in Ubuntu on IBM z Systems:
  Won't Fix
Status in network-manager package in Ubuntu:
  Won't Fix

Bug description:
  Auto activation of Vlan created over network-bond fails if bond is 
deactivated and reactivated.
   
  Contact Information = Abhiram Kulkarni(abhir...@in.ibm.com), Mandar 
Deshpande(manda...@in.ibm.com) 
   
  ---uname output---
  Linux S36MANDAR 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:23 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Created a network bond with static IP address (and no IPv6 address); 
active backup mode; ARP polling; single slave.

  2. Created a VLAN using said network bond with static IPv4 address
  (and no IPv6 address).

  3. Can ping from the appliance to a target on both links (the parent
  bond and the VLAN).

  4. Switched to another slave for the created bond

  5. Can still ping from the appliance to a target via the parent bond;
  however, cannot ping to the target via the VLAN.

  =
  Detailed steps:

  1. Initial setup:
  
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --  

  2. Create Netwrok-bond with one slave:
  
  root@S36MANDAR:~# nmcli c add type bond con-name mybond1 ifname mybond1 
ipv4.method disabled ipv6.method ignore
  Connection 'mybond1' (4b918a65-43a6-4ec3-b3c4-388ed52b116d) successfully 
added.

  root@S36MANDAR:~# nmcli con add type ethernet ifname enc1d40 master mybond1
  Connection 'bond-slave-enc1d40' (cfe4b245-3dda-4f45-b7b4-6d40d144a02f) 
successfully added.
  root@S36MANDAR:~# nmcli con up bond-slave-enc1d40
  Connection successfully activated (D-Bus active path: 
/org/freedesktop/NetworkManager/ActiveConnection/18)
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  enc1d40 
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --  

  3. Create vlan over mybond1:
  ===
  root@S36MANDAR:~# nmcli con add type vlan con-name vlanbond.100 ifname 
vlanbond.100 dev mybond1 id 100  ipv4.method disabled ipv6.method ignore
  Connection 'vlanbond.100' (e054df42-97a0-492b-b2c9-b9571077493e) successfully 
added.
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE
   
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  enc1d40   
   
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80   
   
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00   
   
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1   
   
  vlanbond.100e054df42-97a0-492b-b2c9-b9571077493e  vlan  
vlanbond.100 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --
   

  4. Reactivate bond : 
  =
  root@S36MANDAR:~# nmcli con up mybond1
  Connection successfully activated (master waiting for slaves) (D-Bus active 
path: /org/freedesktop/NetworkManager/ActiveConnection/30)

  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  enc1d40 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1 
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  --  
  encw18104ddeb38e-d5f7-3814-abb7-be50b8da874e  ethernet  --  
  vlanbond.100e054df42-97a0-492b-b2c9-b9571077493e  vlan  --  

  As is seen, vlan(vlanbond.100) did not get activated

  Now, if manually I make vlan connection up, it gets activated:

  

[Desktop-packages] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Fix Committed => Fix Released

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1794478

Title:
  Automatic ipv4 not assigned to bond interface is manual ipv6 is
  assigned to it

Status in Ubuntu on IBM z Systems:
  Fix Released
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Released

Bug description:
  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.
   
  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface

  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto

  From /var/log/syslog, we can see ip got assigned:

  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 
10.2.3.1
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1

  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  28: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute 
test_bond
 valid_lft 353sec preferred_lft 353sec
  inet6 fe80::ff:feb3:b522/64 scope link 
 valid_lft forever preferred_lft forever

  
  
+++
  Bond interface, ipv4 automatic mode and ipv6 manual mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537943300

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  address1=fe81::32a5:bc5f:287f:8db8/64
  dns-search=
  method=manual

  No automatic ip assigned to ipv4 and no requests to dhcp server seen in 
/var/log/syslog
  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  29: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute 
 valid_lft forever preferred_lft forever

  
  ==> Correct LP-Package need to be assigned...!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1794478/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

[Frank Heimes]

Adjusting tags according to comments #9 and #10.

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

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1794478

Title:
  Automatic ipv4 not assigned to bond interface is manual ipv6 is
  assigned to it

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Committed

Bug description:
  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.
   
  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface

  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto

  From /var/log/syslog, we can see ip got assigned:

  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 
10.2.3.1
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1

  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  28: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute 
test_bond
 valid_lft 353sec preferred_lft 353sec
  inet6 fe80::ff:feb3:b522/64 scope link 
 valid_lft forever preferred_lft forever

  
  
+++
  Bond interface, ipv4 automatic mode and ipv6 manual mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537943300

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  address1=fe81::32a5:bc5f:287f:8db8/64
  dns-search=
  method=manual

  No automatic ip assigned to ipv4 and no requests to dhcp server seen in 
/var/log/syslog
  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  29: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute 
 valid_lft forever preferred_lft forever

  
  ==> Correct LP-Package need to be assigned...!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1794478/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: Incomplete => Fix Committed

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1794478

Title:
  Automatic ipv4 not assigned to bond interface is manual ipv6 is
  assigned to it

Status in Ubuntu on IBM z Systems:
  Fix Committed
Status in network-manager package in Ubuntu:
  Fix Released
Status in network-manager source package in Bionic:
  Fix Committed

Bug description:
  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.
   
  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface

  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto

  From /var/log/syslog, we can see ip got assigned:

  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 
10.2.3.1
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1

  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  28: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute 
test_bond
 valid_lft 353sec preferred_lft 353sec
  inet6 fe80::ff:feb3:b522/64 scope link 
 valid_lft forever preferred_lft forever

  
  
+++
  Bond interface, ipv4 automatic mode and ipv6 manual mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537943300

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  address1=fe81::32a5:bc5f:287f:8db8/64
  dns-search=
  method=manual

  No automatic ip assigned to ipv4 and no requests to dhcp server seen in 
/var/log/syslog
  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  29: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute 
 valid_lft forever preferred_lft forever

  
  ==> Correct LP-Package need to be assigned...!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1794478/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1794478] Re: Automatic ipv4 not assigned to bond interface is manual ipv6 is assigned to it

[Frank Heimes]

** Changed in: ubuntu-z-systems
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1794478

Title:
  Automatic ipv4 not assigned to bond interface is manual ipv6 is
  assigned to it

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  ---Problem Description---
  Bond interface with automatic ipv4 mode and manual ipv6 mode fails to get 
automatic ipv4 assigned from dhcp server.
   
  ---uname output---
  Linux NetworkTest 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 13:42:17 UTC 
2018 s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   When user configures ipv4 as automatic and ipv6 as manual for bond interface 
automatic ipv4 is not getting assigned.
  Looks like dhcp client request for ipv4 is not done to dhcp server after 
maunal ipv6 is assigned quickly to bond interface

  This issue will not happen in below cases:
  1)with ipv4 automatic and ipv6 manual configuration for ethernet or vlan 
interface.
  2)with ipv4 automatic and ipv6 automatic configuration for bond interface
  3)with ipv4 automatic and ipv6 disabled configuration for bond interface

  Configuration:
  Bond interface, ipv4 automatic mode and ipv6 automatic mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=63e54542-5135-47ac-a954-b861c3937be2
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537944121

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  dns-search=
  method=auto

  From /var/log/syslog, we can see ip got assigned:

  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPDISCOVER on test_bond to 
255.255.255.255 port 67 interval 3 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPREQUEST of 10.2.3.55 on 
test_bond to 255.255.255.255 port 67 (xid=0x5e04bf1e)
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPOFFER of 10.2.3.55 from 
10.2.3.1
  Sep 26 06:26:26 NetworkTest dhclient[8663]: DHCPACK of 10.2.3.55 from 10.2.3.1

  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  28: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet 10.2.3.55/24 brd 10.2.3.255 scope global dynamic noprefixroute 
test_bond
 valid_lft 353sec preferred_lft 353sec
  inet6 fe80::ff:feb3:b522/64 scope link 
 valid_lft forever preferred_lft forever

  
  
+++
  Bond interface, ipv4 automatic mode and ipv6 manual mode

  root@NetworkTest:/etc/NetworkManager/system-connections# cat test_bond 
  [connection]
  id=test_bond
  uuid=3efb153a-a6e4-48fb-aa04-f0b8cb549bab
  type=bond
  interface-name=test_bond
  permissions=
  timestamp=1537943300

  [ethernet]
  mac-address-blacklist=

  [bond]
  downdelay=0
  fail_over_mac=none
  miimon=100
  mode=active-backup
  num_grat_arp=0
  primary_reselect=always
  updelay=0

  [ipv4]
  dns-search=
  method=auto

  [ipv6]
  addr-gen-mode=stable-privacy
  address1=fe81::32a5:bc5f:287f:8db8/64
  dns-search=
  method=manual

  No automatic ip assigned to ipv4 and no requests to dhcp server seen in 
/var/log/syslog
  root@NetworkTest:/etc/NetworkManager/system-connections# ip a s test_bond
  29: test_bond:  mtu 1500 qdisc 
noqueue state UP group default qlen 1000
  link/ether 02:00:00:b3:b5:22 brd ff:ff:ff:ff:ff:ff
  inet6 fe81::32a5:bc5f:287f:8db8/64 scope link noprefixroute 
 valid_lft forever preferred_lft forever

  
  ==> Correct LP-Package need to be assigned...!

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1794478/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1790098] Re: vlan created on bond fails auto activation on updating parent network bond

[Frank Heimes]

** Changed in: network-manager (Ubuntu)
   Status: New => Incomplete

** Changed in: ubuntu-z-systems
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1790098

Title:
  vlan created on bond fails auto activation on updating parent network
  bond

Status in Ubuntu on IBM z Systems:
  Incomplete
Status in network-manager package in Ubuntu:
  Incomplete

Bug description:
  Auto activation of Vlan created over network-bond fails if bond is 
deactivated and reactivated.
   
  Contact Information = Abhiram Kulkarni(abhir...@in.ibm.com), Mandar 
Deshpande(manda...@in.ibm.com) 
   
  ---uname output---
  Linux S36MANDAR 4.15.0-20-generic #21-Ubuntu SMP Tue Apr 24 06:14:23 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = s390x 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Created a network bond with static IP address (and no IPv6 address); 
active backup mode; ARP polling; single slave.

  2. Created a VLAN using said network bond with static IPv4 address
  (and no IPv6 address).

  3. Can ping from the appliance to a target on both links (the parent
  bond and the VLAN).

  4. Switched to another slave for the created bond

  5. Can still ping from the appliance to a target via the parent bond;
  however, cannot ping to the target via the VLAN.

  =
  Detailed steps:

  1. Initial setup:
  
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --  

  2. Create Netwrok-bond with one slave:
  
  root@S36MANDAR:~# nmcli c add type bond con-name mybond1 ifname mybond1 
ipv4.method disabled ipv6.method ignore
  Connection 'mybond1' (4b918a65-43a6-4ec3-b3c4-388ed52b116d) successfully 
added.

  root@S36MANDAR:~# nmcli con add type ethernet ifname enc1d40 master mybond1
  Connection 'bond-slave-enc1d40' (cfe4b245-3dda-4f45-b7b4-6d40d144a02f) 
successfully added.
  root@S36MANDAR:~# nmcli con up bond-slave-enc1d40
  Connection successfully activated (D-Bus active path: 
/org/freedesktop/NetworkManager/ActiveConnection/18)
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  enc1d40 
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --  

  3. Create vlan over mybond1:
  ===
  root@S36MANDAR:~# nmcli con add type vlan con-name vlanbond.100 ifname 
vlanbond.100 dev mybond1 id 100  ipv4.method disabled ipv6.method ignore
  Connection 'vlanbond.100' (e054df42-97a0-492b-b2c9-b9571077493e) successfully 
added.
  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE
   
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  enc1d40   
   
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80   
   
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00   
   
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1   
   
  vlanbond.100e054df42-97a0-492b-b2c9-b9571077493e  vlan  
vlanbond.100 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  --
   

  4. Reactivate bond : 
  =
  root@S36MANDAR:~# nmcli con up mybond1
  Connection successfully activated (master waiting for slaves) (D-Bus active 
path: /org/freedesktop/NetworkManager/ActiveConnection/30)

  root@S36MANDAR:~# nmcli c s
  NAMEUUID  TYPE  DEVICE  
  enc1a80 c3a2037d-60a3-3cb4-9234-45aed55f7093  ethernet  enc1a80 
  enc1d40 ff2d70f8-130e-3dc6-ab24-1dba07563605  ethernet  enc1d40 
  enc8f00 2423add6-1464-3765-877c-a214dc497492  ethernet  enc8f00 
  mybond1 4b918a65-43a6-4ec3-b3c4-388ed52b116d  bond  mybond1 
  bond-slave-enc1d40  cfe4b245-3dda-4f45-b7b4-6d40d144a02f  ethernet  --  
  encw18104ddeb38e-d5f7-3814-abb7-be50b8da874e  ethernet  --  
  vlanbond.100e054df42-97a0-492b-b2c9-b9571077493e  vlan  --  

  As is seen, vlan(vlanbond.100) did not get activated

  Now, if manually I make vlan connection up, it gets activated:

  

[Desktop-packages] [Bug 1772859] Re: Network Manager is not able to manage the devices on Ubuntu 18.04

[Frank Heimes]

Hi Nicholas, since the original ticket is already closed and the
particular problem solved, I strongly suggest to open a separate new
Launchpad bug for your case.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1772859

Title:
  Network Manager is not able to manage the devices on Ubuntu 18.04

Status in Ubuntu on IBM z Systems:
  Invalid
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  NetworkManager is not able to manage the devices on latest Ubuntu(18.04)
   
  ---uname output---
  Linux (none) 4.15.0-12-generic #13-Ubuntu SMP Wed Mar 7 21:36:36 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = z14 s390 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Install the latest Ubuntu(18.04) with Network Manager(1.10.4).
  2. Configure a network device and login to the partition through ssh.
  3. Now you can see the following output
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
   
  Userspace tool common name: 1.10.6-2ubuntu1: amd64 arm64 armhf i386 ppc64el 
s390x 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: NetworkManager --version 1.10.4

  Userspace tool obtained from project website:  na 
   

  Some more information about the issue:

  Network device has been configured manually after the image is up from 
Support Element(SE):
  - znetconf -a 
  - cat /sys/bus/ccwgroup/drivers/qeth//if_name
  - ifconfig   netmask 255.255.255.0
  - route add default gw  
  - SSH service has been configured
  
  This helped us to login to the Lpar. In Lpar
  - output of znetconf -c
  Device IDs TypeCard Type  CHPID Drv. Name 
State
  
-
  0.0.1a80,0.0.1a81,0.0.1a82 1731/01 OSD_10GIG A8 qeth eth0 
online
  0.0.1810,0.0.1811,0.0.1812 1731/01 OSD_1000  D0 qeth eth1 
online

  - output of nmcli c s
  root@(none):~# nmcli c s
  NAME  UUID  TYPE  DEVICE
  
  - output of nmcli d s
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
  
  * The above output shows that devices are not managed by nmcli
  
  After some investigation we found couple of suggestions like
  1. Ubuntu(version <17.04): Creating an empty 
file(/etc/NetworkManager/conf.d/10-globally-managed-devices.conf) and 
restarting NM,
 solved the issue.
 
  2. Ubuntu(version 17.10): Copying the said 
file(10-globally-managed-devices.conf) from /usr/lib to /etc/ and modifying the 
 "unmanaged-devices" to none, resolved the issue.

  * link for reference: https://bugs.launchpad.net/ubuntu/+source
  /network-manager/+bug/1638842

  For the latest version(18.04), none of the above solutions worked.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1772859/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1772859] Re: Network Manager is not able to manage the devices on Ubuntu 18.04

[Frank Heimes]

So your system is obviously not an 18.04 default installation from
scratch - otherwise you would have netplan.io installed and this folder
and file "/etc/netplan/01-netcfg.yaml" will exist on your system.

There is no known way to me to install an 18.04 system without having
netplan (initially) as default.

Did you have removed netplan manually from that installation?
Or is your 18.04 system and upgrade from an older Ubuntu release (like 16.04 or 
17.10)?

If it's an 18.04 installation from scratch please provide the installation logs.
They are during the installation available at /var/log/*
and after the installation still available at /var/log/installer/*

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1772859

Title:
  Network Manager is not able to manage the devices on Ubuntu 18.04

Status in Ubuntu on IBM z Systems:
  Invalid
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  NetworkManager is not able to manage the devices on latest Ubuntu(18.04)
   
  ---uname output---
  Linux (none) 4.15.0-12-generic #13-Ubuntu SMP Wed Mar 7 21:36:36 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = z14 s390 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Install the latest Ubuntu(18.04) with Network Manager(1.10.4).
  2. Configure a network device and login to the partition through ssh.
  3. Now you can see the following output
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
   
  Userspace tool common name: 1.10.6-2ubuntu1: amd64 arm64 armhf i386 ppc64el 
s390x 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: NetworkManager --version 1.10.4

  Userspace tool obtained from project website:  na 
   

  Some more information about the issue:

  Network device has been configured manually after the image is up from 
Support Element(SE):
  - znetconf -a 
  - cat /sys/bus/ccwgroup/drivers/qeth//if_name
  - ifconfig   netmask 255.255.255.0
  - route add default gw  
  - SSH service has been configured
  
  This helped us to login to the Lpar. In Lpar
  - output of znetconf -c
  Device IDs TypeCard Type  CHPID Drv. Name 
State
  
-
  0.0.1a80,0.0.1a81,0.0.1a82 1731/01 OSD_10GIG A8 qeth eth0 
online
  0.0.1810,0.0.1811,0.0.1812 1731/01 OSD_1000  D0 qeth eth1 
online

  - output of nmcli c s
  root@(none):~# nmcli c s
  NAME  UUID  TYPE  DEVICE
  
  - output of nmcli d s
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
  
  * The above output shows that devices are not managed by nmcli
  
  After some investigation we found couple of suggestions like
  1. Ubuntu(version <17.04): Creating an empty 
file(/etc/NetworkManager/conf.d/10-globally-managed-devices.conf) and 
restarting NM,
 solved the issue.
 
  2. Ubuntu(version 17.10): Copying the said 
file(10-globally-managed-devices.conf) from /usr/lib to /etc/ and modifying the 
 "unmanaged-devices" to none, resolved the issue.

  * link for reference: https://bugs.launchpad.net/ubuntu/+source
  /network-manager/+bug/1638842

  For the latest version(18.04), none of the above solutions worked.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1772859/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1772859] Re: Network Manager is not able to manage the devices on Ubuntu 18.04

[Frank Heimes]

Since the ticket was opened against 18.04, and since 18.04 installations
come with and use netplan by default with again networkd as the default
renderer (and not NetworkManager), NetworkManager just cannot work by
default.

If you want to work with NetworkManager on an 18.04 installation that's using 
netplan, the described re-configuration is needed and the renderer needs to be 
changed from networkd to NetworkManager - that's not a bug, that's intended and 
caused by the introduction of netplan (since about 17.10).
With that change NetworkManager should be able to manage qdio devices (see end 
of comment #3 - devices are listed as managed).

If you still have problems managing the devices _after_ doing the re-
config there might be a bug, but I don't see that right now (but I for
sure didn't covered your entire use case that I just don't know).

We understand that behavior is now a bit different compared to other
distributions.

There were some bugs in the past on NetworkManager and netplan on previous 
Ubuntu releases, like the one mentioned by you in the bug description:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1638842
which is a duplicate of:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1676547
and already 'Fix Release' (since quite some time).
And btw. comment 26: 
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1676547/comments/26
 confirms that the above renderer change works.

If issues still occur on other Ubuntu releases (not 18.04, but for example 
16.04) that are not yet addressed in an LP bug, please open a separate bug on 
them.
And if there are still issues managing qdio devices after the change above, we 
may address them is a separate ticket, too.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1772859

Title:
  Network Manager is not able to manage the devices on Ubuntu 18.04

Status in Ubuntu on IBM z Systems:
  Invalid
Status in network-manager package in Ubuntu:
  Invalid

Bug description:
  NetworkManager is not able to manage the devices on latest Ubuntu(18.04)
   
  ---uname output---
  Linux (none) 4.15.0-12-generic #13-Ubuntu SMP Wed Mar 7 21:36:36 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = z14 s390 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Install the latest Ubuntu(18.04) with Network Manager(1.10.4).
  2. Configure a network device and login to the partition through ssh.
  3. Now you can see the following output
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
   
  Userspace tool common name: 1.10.6-2ubuntu1: amd64 arm64 armhf i386 ppc64el 
s390x 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: NetworkManager --version 1.10.4

  Userspace tool obtained from project website:  na 
   

  Some more information about the issue:

  Network device has been configured manually after the image is up from 
Support Element(SE):
  - znetconf -a 
  - cat /sys/bus/ccwgroup/drivers/qeth//if_name
  - ifconfig   netmask 255.255.255.0
  - route add default gw  
  - SSH service has been configured
  
  This helped us to login to the Lpar. In Lpar
  - output of znetconf -c
  Device IDs TypeCard Type  CHPID Drv. Name 
State
  
-
  0.0.1a80,0.0.1a81,0.0.1a82 1731/01 OSD_10GIG A8 qeth eth0 
online
  0.0.1810,0.0.1811,0.0.1812 1731/01 OSD_1000  D0 qeth eth1 
online

  - output of nmcli c s
  root@(none):~# nmcli c s
  NAME  UUID  TYPE  DEVICE
  
  - output of nmcli d s
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
  
  * The above output shows that devices are not managed by nmcli
  
  After some investigation we found couple of suggestions like
  1. Ubuntu(version <17.04): Creating an empty 
file(/etc/NetworkManager/conf.d/10-globally-managed-devices.conf) and 
restarting NM,
 solved the issue.
 
  2. Ubuntu(version 17.10): Copying the said 
file(10-globally-managed-devices.conf) from /usr/lib to /etc/ and modifying the 
 "unmanaged-devices" to none, resolved the issue.

  * link for reference: https://bugs.launchpad.net/ubuntu/+source
  /network-manager/+bug/1638842

  For the latest version(18.04), none of the above solutions worked.

To manage notifications about this bug go to:

[Desktop-packages] [Bug 1772859] Re: Network Manager is not able to manage the devices on Ubuntu 18.04

[Frank Heimes]

So this is more a configuration thing, because with netplan the default
renderer is networkd (and not NetworkManager):

ubuntu@zlin:~$ grep renderer /etc/netplan/01-netcfg.yaml
  renderer: networkd

This leads to the fact that no connections are managed by nm by default:

ubuntu@zlin:~$ nmcli con show
NAME  UUID  TYPE  DEVICE 
ubuntu@zlin:~$ nmcli d s
DEVICETYPE  STATE  CONNECTION 
enP1p0s0  ethernet  unmanaged  -- 
enP1p0s0d1ethernet  unmanaged  -- 
enP2p0s0  ethernet  unmanaged  -- 
enP2p0s0d1ethernet  unmanaged  -- 
encc000   ethernet  unmanaged  -- 
loloopback  unmanaged  -- 
encc000.2653  vlan  unmanaged  --  

Changing the renderer from networkd to NetworkManager is probably what
you are looking for:

# default:
ubuntu@zlin:~$ cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: networkd
  ethernets:
encc000:
  dhcp4: no
  dhcp6: no
  vlans:
encc000.2653:
  link: encc000
  id: 2653
  addresses: [ 10.245.236.14/24 ]
  gateway4: 10.245.236.1
  nameservers:
  search: [ canonical.com ]
  addresses:
  - "10.245.236.1"

# change the renderer form 'networkd' to 'NetworkManager':

ubuntu@zlin:~$ cat /etc/netplan/01-netcfg.yaml
# This file describes the network interfaces available on your system
# For more information, see netplan(5).
network:
  version: 2
  renderer: NetworkManager
  ethernets:
encc000:
  dhcp4: no
  dhcp6: no
  vlans:
encc000.2653:
  link: encc000
  id: 2653
  addresses: [ 10.245.236.14/24 ]
  gateway4: 10.245.236.1
  nameservers:
  search: [ canonical.com ]
  addresses:
  - "10.245.236.1"

# restart netplan / dry-run, to look for any potential config errors
ubuntu@zlin:~$ sudo netplan --debug generate
DEBUG:command generate: running ['/lib/netplan/generate']
** (generate:2472): DEBUG: 13:47:43.846: Processing input file 
//etc/netplan/01-netcfg.yaml..
** (generate:2472): DEBUG: 13:47:43.846: starting new processing pass
** (generate:2472): DEBUG: 13:47:43.846: encc000.2653: setting default backend 
to 2
** (generate:2472): DEBUG: 13:47:43.846: encc000: setting default backend to 2
** (generate:2472): DEBUG: 13:47:43.846: Generating output files..
** (generate:2472): DEBUG: 13:47:43.846: networkd: definition encc000.2653 is 
not for us (backend 2)
** (generate:2472): DEBUG: 13:47:43.846: networkd: definition encc000 is not 
for us (backend 2)

# restart netplan in case no error are detected
ubuntu@zlin:~$ sudo netplan apply
ubuntu@zlin:~$

# now nm / nmcli has control:
ubuntu@zlin:~$ nmcli dev show
GENERAL.DEVICE: encc000.2653
GENERAL.TYPE:   vlan
GENERAL.HWADDR: 02:00:00:33:B5:DD
GENERAL.MTU:1500
GENERAL.STATE:  100 (connected)
GENERAL.CONNECTION: netplan-encc000.2653
GENERAL.CON-PATH:   /org/freedesktop/NetworkManager/ActiveCo
IP4.ADDRESS[1]: 10.245.236.14/24
IP4.GATEWAY:10.245.236.1
IP4.ROUTE[1]:   dst = 10.245.236.0/24, nh = 0.0.0.0, mt 
IP4.ROUTE[2]:   dst = 0.0.0.0/0, nh = 10.245.236.1, mt =
IP4.DNS[1]: 10.245.236.1
IP6.ADDRESS[1]: fe80::ff:fe33:b5dd/64
IP6.GATEWAY:--
IP6.ROUTE[1]:   dst = ff00::/8, nh = ::, mt = 256, table
IP6.ROUTE[2]:   dst = fe80::/64, nh = ::, mt = 256

GENERAL.DEVICE: encc000
GENERAL.TYPE:   ethernet
GENERAL.HWADDR: 02:00:00:33:B5:DD
GENERAL.MTU:1500
GENERAL.STATE:  100 (connected)
GENERAL.CONNECTION: netplan-encc000
ubuntu@zlin:~$ nmcli con show
NAME  UUID  TYPE  DEVICE
netplan-encc000   abd74282-8c33-3a09-985f-54c65ed16162  ethernet  encc000   
netplan-encc000.2653  8aabaee8-34fb-3808-b152-454ad49553d3  vlan  encc000.26
Wired connection 1ce36d943-64bd-312a-bd46-6bbf9ce71795  ethernet  --
Wired connection 2fbc21b74-c93e-3441-be46-decf30bf22f4  ethernet  --
Wired connection 307334b8f-c16d-37d6-b8cb-dc38f4b8e3e3  ethernet  --
Wired connection 48f06587e-be8c-366e-83b3-ab6a285e93cd  ethernet  -- 

Since networkmanager is a tool that is mainly used in the desktop space,
I'm wondering what you are trying to do with nmcli and if the iproute2
tools (man ip) are a better alternative, since they can be used by
default w/o the need of changing the renderer ...

** Changed in: network-manager 

[Desktop-packages] [Bug 1772859] Re: Network Manager is not able to manage the devices on Ubuntu 18.04

[Frank Heimes]

First of all some comments:
- why was znetconf used and not chzdev ?
- I'm a bit puzzled reading about "rpm" in combination with Ubuntu
  even if a universe rpm package exists, I  assume a network-manager deb 
package was used, right?
- afaik the network-manager package (that also incl. the nmcli) is a package 
that belongs to the desktop-packages pocket (need to check this ...)
- is the use of the ip tools (from iproute2) an alternative?

** Package changed: linux (Ubuntu) => network-manager (Ubuntu)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to network-manager in Ubuntu.
https://bugs.launchpad.net/bugs/1772859

Title:
  Network Manager is not able to manage the devices on Ubuntu 18.04

Status in Ubuntu on IBM z Systems:
  New
Status in network-manager package in Ubuntu:
  New

Bug description:
  NetworkManager is not able to manage the devices on latest Ubuntu(18.04)
   
  ---uname output---
  Linux (none) 4.15.0-12-generic #13-Ubuntu SMP Wed Mar 7 21:36:36 UTC 2018 
s390x s390x s390x GNU/Linux
   
  Machine Type = z14 s390 
   
  ---Debugger---
  A debugger is not configured
   
  ---Steps to Reproduce---
   1. Install the latest Ubuntu(18.04) with Network Manager(1.10.4).
  2. Configure a network device and login to the partition through ssh.
  3. Now you can see the following output
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
   
  Userspace tool common name: 1.10.6-2ubuntu1: amd64 arm64 armhf i386 ppc64el 
s390x 
   
  The userspace tool has the following bit modes: 64-bit 

  Userspace rpm: NetworkManager --version 1.10.4

  Userspace tool obtained from project website:  na 
   

  Some more information about the issue:

  Network device has been configured manually after the image is up from 
Support Element(SE):
  - znetconf -a 
  - cat /sys/bus/ccwgroup/drivers/qeth//if_name
  - ifconfig   netmask 255.255.255.0
  - route add default gw  
  - SSH service has been configured
  
  This helped us to login to the Lpar. In Lpar
  - output of znetconf -c
  Device IDs TypeCard Type  CHPID Drv. Name 
State
  
-
  0.0.1a80,0.0.1a81,0.0.1a82 1731/01 OSD_10GIG A8 qeth eth0 
online
  0.0.1810,0.0.1811,0.0.1812 1731/01 OSD_1000  D0 qeth eth1 
online

  - output of nmcli c s
  root@(none):~# nmcli c s
  NAME  UUID  TYPE  DEVICE
  
  - output of nmcli d s
  root@(none):~# nmcli d s
  DEVICE  TYPE  STATE  CONNECTION
  eth0ethernet  unmanaged  --
  eth1ethernet  unmanaged  --
  lo  loopback  unmanaged  --
  
  * The above output shows that devices are not managed by nmcli
  
  After some investigation we found couple of suggestions like
  1. Ubuntu(version <17.04): Creating an empty 
file(/etc/NetworkManager/conf.d/10-globally-managed-devices.conf) and 
restarting NM,
 solved the issue.
 
  2. Ubuntu(version 17.10): Copying the said 
file(10-globally-managed-devices.conf) from /usr/lib to /etc/ and modifying the 
 "unmanaged-devices" to none, resolved the issue.

  * link for reference: https://bugs.launchpad.net/ubuntu/+source
  /network-manager/+bug/1638842

  For the latest version(18.04), none of the above solutions worked.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1772859/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1734032] Re: X11 application cannot get nabi XIM server's state

[Frank Heimes]

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

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nabi in Ubuntu.
https://bugs.launchpad.net/bugs/1734032

Title:
  X11 application cannot get nabi XIM server's state

Status in nabi package in Ubuntu:
  Invalid

Bug description:
  ---Problem Description---
  X11 application cannot get nabi XIM server's state.

  ---uname output---
  4.10.0-30-generic #34~16.04.1-Ubuntu SMP Wed Aug 2 02:13:56 UTC 2017 x86_64 
x86_64 x86_64 GNU/Linux
   
  Machine Type = x64 machine 

  ---Steps to Reproduce---
   This testing requires X11 desktop environment , nabi XIM server (nabi 
package) and Korean locale.
  1. Login to X11 environmnet
  2. Download attached xim_root.zip file
  3. Compile it with "-lX11" option, like
  $ cc -o xim_root xim_root.c -lX11
  4. Change current local ko_KR.utf8, like
  $ export LANG=ko_KR.utf8
  5. Start nabi, like
  $ nabi &
  (XIM's state may display somewhere...)
  6. Start xim_root with XMODIFIERS environment variable, like
  $ XMODIFIERS=@im=nabi ./xim_root
  7. Press "A" key, then xim_root prints "XmbLookupString:a"
  8. Press Ctrl+Muddle Mouse button on xim_root, then print "State: IM On", 
even if IM is not turned ON <== ISSUE
  9. Press Shift+Space key to turn on, then type "gks", Korean character is 
displayed on xim_root, then press Return key, this Korean character is committed
  10. Press Ctrl+Left Mouse button to turn off XIM server, then type "gks", but 
still XIM is turned on <== ISSUE
  11. Press Ctrl+Middle Mouse button, print "State: IM Off".

  So X11 application cannot get XIM state properly.

  $ ps -ef | grep nabi
  jdktest   4377  3409  0 21:21 pts/10   00:00:00 nabi
  jdktest   7427  1760  0 21:40 pts/100:00:00 grep --color=auto nabi
  $ apport-cli 4377 --save=bug.apport

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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1706948] Re: [Ubuntu 18.04] [Feature] Inconsistent report of pm CanSuspend state by systemd and pm-utils

[Frank Heimes]

** Changed in: pm-utils (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: ubuntu-power-systems
   Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pm-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1706948

Title:
  [Ubuntu 18.04] [Feature] Inconsistent report of pm CanSuspend state by
  systemd and pm-utils

Status in The Ubuntu-power-systems project:
  Invalid
Status in pm-utils package in Ubuntu:
  Invalid

Bug description:
  == Comment: #0 - Balamuruhan S <> - 2017-06-28 03:39:15 ==
  systemd and pm-utils interprets CanSuspend states differently and reports it 
as supported or not in a conflicting way.

  # gdbus call --system --dest org.freedesktop.login1 --object-path 
/org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanSuspend
  ('yes',)

  # pm-is-supported --suspend
  # echo $?
  1

  Both systemd and pm-is-supported looks into /sys/power/state file to
  check if suspend is supported.

  pm-is-supported --suspend returns true if either "standby" or "mem" is 
present in the file.
  ( /usr/lib/pm-utils/pm-functions )

  systemd(Manager.CanSuspend) returns true if "standby", "freeze" or "mem" is 
present in the file.
  ( 
https://github.com/systemd/systemd/blob/dd8352659c9428b196706d04399eec106a8917ed/src/shared/sleep-config.c
 )

  # cat /sys/power/state
  freeze

  So here, pm-is-supported --suspend returns false and gdbus returns
  true.

  Both these utilities interpret /sys/power/state differently.

  Secondly, systemd should split CanSuspend to Cansuspend+CanFreeze Or
  don't report freeze as CanSuspend.

  Impact of this inconsistency can be felt from Libvirt supported pm
  states:

  To reduce ABI dependency, libvirt queries the available states via
  dbus, if not falls to pm-utils. Libvirt won't check for strings in
  sys/power/state and interpret directly.

  so due to this, libvirt will list that suspend_to_mem is supported
  from virsh capabilities but ideally it might not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1706948/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1734032] Re: X11 application cannot get nabi XIM server's state

[Frank Heimes]

** Changed in: nabi (Ubuntu)
 Assignee: Ubuntu on IBM Power Systems Bug Triage (ubuntu-power-triage) => 
(unassigned)

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nabi in Ubuntu.
https://bugs.launchpad.net/bugs/1734032

Title:
  X11 application cannot get nabi XIM server's state

Status in nabi package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  X11 application cannot get nabi XIM server's state.

  ---uname output---
  4.10.0-30-generic #34~16.04.1-Ubuntu SMP Wed Aug 2 02:13:56 UTC 2017 x86_64 
x86_64 x86_64 GNU/Linux
   
  Machine Type = x64 machine 

  ---Steps to Reproduce---
   This testing requires X11 desktop environment , nabi XIM server (nabi 
package) and Korean locale.
  1. Login to X11 environmnet
  2. Download attached xim_root.zip file
  3. Compile it with "-lX11" option, like
  $ cc -o xim_root xim_root.c -lX11
  4. Change current local ko_KR.utf8, like
  $ export LANG=ko_KR.utf8
  5. Start nabi, like
  $ nabi &
  (XIM's state may display somewhere...)
  6. Start xim_root with XMODIFIERS environment variable, like
  $ XMODIFIERS=@im=nabi ./xim_root
  7. Press "A" key, then xim_root prints "XmbLookupString:a"
  8. Press Ctrl+Muddle Mouse button on xim_root, then print "State: IM On", 
even if IM is not turned ON <== ISSUE
  9. Press Shift+Space key to turn on, then type "gks", Korean character is 
displayed on xim_root, then press Return key, this Korean character is committed
  10. Press Ctrl+Left Mouse button to turn off XIM server, then type "gks", but 
still XIM is turned on <== ISSUE
  11. Press Ctrl+Middle Mouse button, print "State: IM Off".

  So X11 application cannot get XIM state properly.

  $ ps -ef | grep nabi
  jdktest   4377  3409  0 21:21 pts/10   00:00:00 nabi
  jdktest   7427  1760  0 21:40 pts/100:00:00 grep --color=auto nabi
  $ apport-cli 4377 --save=bug.apport

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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1734032] Re: X11 application cannot get nabi XIM server's state

[Frank Heimes]

nabi is a package that belongs to Ubuntu Desktop.
And the underlying platform is listed as x86_64.

But why is this ticket marked as affecting the ubuntu-power-systems project?
Ubuntu for Power is Ubuntu Server only.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to nabi in Ubuntu.
https://bugs.launchpad.net/bugs/1734032

Title:
  X11 application cannot get nabi XIM server's state

Status in nabi package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  X11 application cannot get nabi XIM server's state.

  ---uname output---
  4.10.0-30-generic #34~16.04.1-Ubuntu SMP Wed Aug 2 02:13:56 UTC 2017 x86_64 
x86_64 x86_64 GNU/Linux
   
  Machine Type = x64 machine 

  ---Steps to Reproduce---
   This testing requires X11 desktop environment , nabi XIM server (nabi 
package) and Korean locale.
  1. Login to X11 environmnet
  2. Download attached xim_root.zip file
  3. Compile it with "-lX11" option, like
  $ cc -o xim_root xim_root.c -lX11
  4. Change current local ko_KR.utf8, like
  $ export LANG=ko_KR.utf8
  5. Start nabi, like
  $ nabi &
  (XIM's state may display somewhere...)
  6. Start xim_root with XMODIFIERS environment variable, like
  $ XMODIFIERS=@im=nabi ./xim_root
  7. Press "A" key, then xim_root prints "XmbLookupString:a"
  8. Press Ctrl+Muddle Mouse button on xim_root, then print "State: IM On", 
even if IM is not turned ON <== ISSUE
  9. Press Shift+Space key to turn on, then type "gks", Korean character is 
displayed on xim_root, then press Return key, this Korean character is committed
  10. Press Ctrl+Left Mouse button to turn off XIM server, then type "gks", but 
still XIM is turned on <== ISSUE
  11. Press Ctrl+Middle Mouse button, print "State: IM Off".

  So X11 application cannot get XIM state properly.

  $ ps -ef | grep nabi
  jdktest   4377  3409  0 21:21 pts/10   00:00:00 nabi
  jdktest   7427  1760  0 21:40 pts/100:00:00 grep --color=auto nabi
  $ apport-cli 4377 --save=bug.apport

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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1706948] Re: [Ubuntu 1710] [Feature] Inconsistent report of pm CanSuspend state by systemd and pm-utils

[Frank Heimes]

This package / The package is part of the universe section of the Ubuntu 
archive. Universe packages are maintained by the community, and the maintainers 
do not necessarily work for Canonical, therefore these packages are not always 
supported directly by Canonical. 
The existing process to update packages in the Universe archive with patches, 
is as follows: 
1. Upstream: Upstream your fix to the appropriate upstream project.
2. Debian: once your patch is ack’ed and accepted upstream, you need to request 
a merge of this patch to the package in Debian stable. 
https://www.debian.org/Bugs/Reporting use this link to report your issue and 
submit a fix. 
3. Ubuntu: Once it is merged into Debian stable, request a merge of this 
package with Ubuntu. https://wiki.ubuntu.com/Debian/Bugs will provide you an 
overview on how to handle bugs that are reported to Debian and subsequently to 
Ubuntu. 
- The merge request lands by default in Ubuntu's current development release 
(today ‘Artful’).
- If required an SRU may follow to get the changes into already released Ubuntu 
versions (like ‘Xenial’ or ‘Zesty’).
Work with the respective upstream maintainers (Debian and Ubuntu) is required 
during this process.  For critical issues we can advise you as you go through 
this process and help push the patches through by chasing the appropriate 
project contributors.
[To find out if a package is a universe package use: apt policy .]

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pm-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1706948

Title:
  [Ubuntu 1710] [Feature] Inconsistent report of pm CanSuspend state by
  systemd and pm-utils

Status in The Ubuntu-power-systems project:
  New
Status in pm-utils package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Balamuruhan S <> - 2017-06-28 03:39:15 ==
  systemd and pm-utils interprets CanSuspend states differently and reports it 
as supported or not in a conflicting way.

  # gdbus call --system --dest org.freedesktop.login1 --object-path 
/org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanSuspend
  ('yes',)

  # pm-is-supported --suspend
  # echo $?
  1

  Both systemd and pm-is-supported looks into /sys/power/state file to
  check if suspend is supported.

  pm-is-supported --suspend returns true if either "standby" or "mem" is 
present in the file.
  ( /usr/lib/pm-utils/pm-functions )

  systemd(Manager.CanSuspend) returns true if "standby", "freeze" or "mem" is 
present in the file.
  ( 
https://github.com/systemd/systemd/blob/dd8352659c9428b196706d04399eec106a8917ed/src/shared/sleep-config.c
 )

  # cat /sys/power/state
  freeze

  So here, pm-is-supported --suspend returns false and gdbus returns
  true.

  Both these utilities interpret /sys/power/state differently.

  Secondly, systemd should split CanSuspend to Cansuspend+CanFreeze Or
  don't report freeze as CanSuspend.

  Impact of this inconsistency can be felt from Libvirt supported pm
  states:

  To reduce ABI dependency, libvirt queries the available states via
  dbus, if not falls to pm-utils. Libvirt won't check for strings in
  sys/power/state and interpret directly.

  so due to this, libvirt will list that suspend_to_mem is supported
  from virsh capabilities but ideally it might not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1706948/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1706948] Re: [Ubuntu 1710] [Feature] Inconsistent report of pm CanSuspend state by systemd and pm-utils

[Frank Heimes]

** Also affects: ubuntu-power-systems
   Importance: Undecided
   Status: New

** Changed in: ubuntu-power-systems
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to pm-utils in Ubuntu.
https://bugs.launchpad.net/bugs/1706948

Title:
  [Ubuntu 1710] [Feature] Inconsistent report of pm CanSuspend state by
  systemd and pm-utils

Status in The Ubuntu-power-systems project:
  New
Status in pm-utils package in Ubuntu:
  New

Bug description:
  == Comment: #0 - Balamuruhan S <> - 2017-06-28 03:39:15 ==
  systemd and pm-utils interprets CanSuspend states differently and reports it 
as supported or not in a conflicting way.

  # gdbus call --system --dest org.freedesktop.login1 --object-path 
/org/freedesktop/login1 --method org.freedesktop.login1.Manager.CanSuspend
  ('yes',)

  # pm-is-supported --suspend
  # echo $?
  1

  Both systemd and pm-is-supported looks into /sys/power/state file to
  check if suspend is supported.

  pm-is-supported --suspend returns true if either "standby" or "mem" is 
present in the file.
  ( /usr/lib/pm-utils/pm-functions )

  systemd(Manager.CanSuspend) returns true if "standby", "freeze" or "mem" is 
present in the file.
  ( 
https://github.com/systemd/systemd/blob/dd8352659c9428b196706d04399eec106a8917ed/src/shared/sleep-config.c
 )

  # cat /sys/power/state
  freeze

  So here, pm-is-supported --suspend returns false and gdbus returns
  true.

  Both these utilities interpret /sys/power/state differently.

  Secondly, systemd should split CanSuspend to Cansuspend+CanFreeze Or
  don't report freeze as CanSuspend.

  Impact of this inconsistency can be felt from Libvirt supported pm
  states:

  To reduce ABI dependency, libvirt queries the available states via
  dbus, if not falls to pm-utils. Libvirt won't check for strings in
  sys/power/state and interpret directly.

  so due to this, libvirt will list that suspend_to_mem is supported
  from virsh capabilities but ideally it might not.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1706948/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1679184] Re: LVM configuration cannot be removed when volume groups with the same name are found during installation

[Frank Heimes]

** Package changed: llvm-toolchain-3.5 (Ubuntu) => lvm2 (Ubuntu)

** Also affects: ubuntu-z-systems
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to llvm-toolchain-3.5 in Ubuntu.
https://bugs.launchpad.net/bugs/1679184

Title:
  LVM configuration cannot be removed when volume groups with the same
  name are found during installation

Status in Ubuntu on IBM z Systems:
  New
Status in lvm2 package in Ubuntu:
  New

Bug description:
  Installer version: 20101020ubuntu500

  Kernel: 4.10.0-14

  Description/Reproduction:

  During installation, the installer finds LVM volume groups from a
  previous installation.

  Current LVM configuration:
   Unallocated physical volumes:
 * /dev/mapper/mpatha2  (21218MB)
  
   Volume groups:   
 * rootVG   (21218MB)
   - Uses physical volume: /dev/dasda2  (21315MB)
   - Uses physical volume: /dev/mapper/mpathc1  (21470MB)
   - Uses physical volume: [unknown](21470MB)
   - Uses physical volume: [unknown](21470MB)
 * rootVG   (21470MB)
   - Uses physical volume: /dev/dasda2  (21315MB)
   - Uses physical volume: /dev/mapper/mpathc1  (21470MB)
   - Uses physical volume: [unknown](21470MB)
   - Uses physical volume: [unknown](21470MB)
 * rootvg   (42685MB)
   - Uses physical volume: /dev/mapper/mpathb1  (21470MB)
   - Uses physical volume: [unknown](214

  When trying to remove that LVM using "Configure the Logical Volume
  Manager", it is not possible to remove logical volumes. The error "The
  logical volume swapLV on rootVG could not be deleted." is displayed.
  In syslog, you see the following messages:

  Apr  3 12:55:56 partman-lvm:   Multiple VGs found with the same name: 
skipping rootVG
  Apr  3 12:55:56 partman-lvm:   Use --select vg_uuid= in place of the VG 
name.

  As you cannot use the suggested parameter in the installer, the system
  cannot be installed without manually removing the LVM setup with
  another shell.

  Debug logs are attached

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1679184/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1642965] Re: Firefox crashes - Error loading theme icon

[Frank Heimes]

** Tags added: s390x

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to firefox in Ubuntu.
https://bugs.launchpad.net/bugs/1642965

Title:
  Firefox crashes - Error loading theme icon

Status in firefox package in Ubuntu:
  Incomplete

Bug description:
  Linux lnx 4.4.0-45-generic #66-Ubuntu SMP Wed Oct 19 14:14:35 UTC 2016 s390x 
s390x s390x GNU/Linux
  Firefox:
  firefox   47.0+build3-0ubuntu0.16.04.1

  Description:
  Firefox crashes when trying to start it on the server and display on the 
local client.
  Other X application can be displayed.

  Reproduction:
  Login to the server: ssh -X lnxserver
  Start firefox: firefox --no-remote

  Error Message:
  (firefox:39655): Gtk-WARNING **: Error loading theme icon 'list-add' for 
stock: Icon 'list-add' not present in theme System
  Segmentation fault (core dumped)

  == Comment: #6 - Thorsten Diehl  - 2016-11-16 
11:50:35 ==
  I can confirm this.

  I installed Ubuntu 16.04.1 on s390x (z13 machine) and installed updates, then 
x11-apps, which were working fine (xclock, xeyes).
  I installed firefox and started it:
  firefox --no-remote 
  it created tons of messages, all complaing about an unknown image format.
  Any subsequent start does not create that many messages. But even with 
--safe-mode I can't get it started:
  root@s8330009:~# firefox --no-remote --safe-mode

  (firefox:1487): Gtk-WARNING **: Locale not supported by C library.
Using the fallback 'C' locale.
  Crash Annotation GraphicsCriticalError: |[0][GFX1]: Unknown image format 1 
(t=0.627128) [GFX1]: Unknown image format 1
  Crash Annotation GraphicsCriticalError: |[0][GFX1]: Unknown image format 1 
(t=0.627128) |[1][GFX1]: Unknown image format 0 (t=0.631695) [GFX1]: Unknown 
image format 0
  [1487] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private 
resource denied); 3 requests ago: file 
/build/firefox-xMihVX/firefox-47.0+build3/toolkit/xre/nsX11ErrorHandler.cpp, 
line 157
  [1487] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private 
resource denied); 3 requests ago: file 
/build/firefox-xMihVX/firefox-47.0+build3/toolkit/xre/nsX11ErrorHandler.cpp, 
line 157

  Perhaps a graphics library (gtklib?) has a problem?

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

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp