[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

** Description changed:

- It was brought to my attention (by others) that ifupdown runs into race
- conditions on some specific cases.
- 
- [Impact]
- 
- When trying to deploy many servers at once (higher chances of happening)
- or from time-to-time, like any other intermittent race-condition.
- Interfaces are not brought up like they should and this has a big impact
- for servers that cannot rely on network start scripts.
- 
- The problem is caused by a race condition when init(upstart) starts up
- network interfaces in parallel.
- 
- [Test Case]
- 
- Use attached script to reproduce the error (it might take some hours, in
- a single virtual machine, for the error to occur).
- 
  * please consider my bonding examples are using eth1 and eth2 as slave
-  interfaces.
- 
- ifupdown some race conditions explained bellow:
+  interfaces.
+ 
+ ifupdown some race conditions explained bellow. ifenslave does not
+ behave well with sysv networking and upstart network-interface scripts
+ running together.
  
  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
-   1-1. Wait for locking ifstate.lock
-   file.
+   1-1. Wait for locking ifstate.lock
+   file.
  1-2. Read ifstate file to check
-  the target NIC.
+  the target NIC.
  1-3. close(=release) ifstate.lock
-  file.
+  file.
  1-4. Judge that the target NIC
-  isn't processed.
-   1-2. Read ifstate file to check
-    the target NIC.
-   1-3. close(=release) ifstate.lock
-    file.
-   1-4. Judge that the target NIC
-    isn't processed.
+  isn't processed.
+   1-2. Read ifstate file to check
+the target NIC.
+   1-3. close(=release) ifstate.lock
+file.
+   1-4. Judge that the target NIC
+isn't processed.
  2. Lock and update ifstate file.
-    Release the lock.
-   2. Lock and update ifstate file.
-  Release the lock.
+Release the lock.
+   2. Lock and update ifstate file.
+  Release the lock.
  !!!
+ 
+ to be explained
  
  !!!
  case 2)
- (a) ifenslave of eth0 (b) ifenslave of eth0
+ (a) ifenslave of eth0  (b) ifenslave of eth0
  --
- 3. Execute ifenslave of eth0. 3. Execute ifenslave of eth0.
+ 3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
-    /sys/class/net/bond0/bonding
-    /slaves then NIC gets up
-   4. Link down the target NIC.
-   5. Fails to write NIC id to
-  /sys/class/net/bond0/bonding/
-  slaves it is already written.
+/sys/class/net/bond0/bonding
+/slaves then NIC gets up
+   4. Link down the target NIC.
+   5. Fails to write NIC id to
+  /sys/class/net/bond0/bonding/
+  slaves it is already written.
  !!!
+ 
+ #
+ 
+  My setup:
+ 
+ root@provisioned:~# cat /etc/modprobe.d/bonding.conf
+ alias bond0 bonding options bonding mode=1 arp_interval=2000
+ 
+ Both, /etc/init.d/networking and upstart network-interface begin
+ enabled.
+ 
+  Beginning:
+ 
+ root@provisioned:~# cat /etc/network/interfaces
+ # /etc/network/interfaces
+ 
+ auto lo
+ iface lo inet loopback
+ 
+ auto eth0
+ iface eth0 inet dhcp
+ 
+ I'm able to boot with both scripts (networking and network-interface
+ enabled) with no problem. I can also boot with only networking 
+ script enabled:
+ 
+ ---
+ root@provisioned:~# initctl list | grep network
+ network-interface stop/waiting
+ network-interface-security (networking) start/running
+ networking start/running
+ network-interface-container stop/waiting
+ ---
+ 
+ OR only the script network-interface enabled:
+ 
+ ---
+ root@provisioned:~# initctl list | grep network
+ network-interface (eth2) start/running
+ network-interface (lo) start/running
+ network-interface (eth0) start/running
+ network-interface (eth1) start/running
+ networking start/running
+ network-interface-container stop/waiting
+ ---
+ 
+  Enabling bonding:
+ 

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

CORRECT WAY OF SETTING INTERFACES FILE FOR BONDING:

1) This model has race conditions.
2) YOU HAVE to have both scripts running (networking and network-interfaces)

# /etc/network/interfaces

auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

auto eth1
iface eth1 inet manual
bond-master bond0

auto eth2
iface eth2 inet manual
bond-master bond0

auto bond0
iface bond0 inet static
bond-mode 1
bond-miimon 100
bond-primary eth1
bond-slaves eth1 eth2
address 192.168.169.1
netmask 255.255.255.0
broadcast 192.168.169.255

You can expect this to fail from time to time but it works... working on
a fix for this.

** Description changed:

  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.
  
  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.
  
  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!
  
  to be explained
  
  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.
  !!!
  
  #
  
   My setup:
  
  root@provisioned:~# cat /etc/modprobe.d/bonding.conf
  alias bond0 bonding options bonding mode=1 arp_interval=2000
  
  Both, /etc/init.d/networking and upstart network-interface begin
  enabled.
  
   Beginning:
  
  root@provisioned:~# cat /etc/network/interfaces
  # /etc/network/interfaces
  
  auto lo
  iface lo inet loopback
  
  auto eth0
  iface eth0 inet dhcp
  
  I'm able to boot with both scripts (networking and network-interface
  enabled) with no problem. I can also boot with only networking 
  script enabled:
  
  ---
  root@provisioned:~# initctl list | grep network
  network-interface stop/waiting
- network-interface-security (networking) start/running
  networking start/running
- network-interface-container stop/waiting
  ---
  
  OR only the script network-interface enabled:
  
  ---
  root@provisioned:~# initctl list | grep network
  network-interface (eth2) start/running
  network-interface (lo) start/running
  network-interface (eth0) start/running
  network-interface (eth1) start/running
- networking start/running
- network-interface-container stop/waiting
  ---
  
   Enabling bonding:
  
  Following ifenslave configuration example (/usr/share/doc/ifenslave/
  examples/two_hotplug_ethernet), my /etc/network/interfaces has to 
  look like this:
  
  ---
  auto eth1
  iface eth1 inet manual
  bond-master bond0
  
  auto eth2
  iface eth2 inet manual
  bond-master bond0
  
  auto bond0
  iface bond0 inet static
  bond-mode 1
  bond-miimon 100
  bond-primary eth1 eth2
address 192.168.169.1
netmask 255.255.255.0
broadcast 192.168.169.255
  ---
  
  Having both scripts running does not make any difference since we
  are missing bond-slaves keyword on slave interfaces, for ifenslave
  to work, and they are set to manual.
  
  Ifenslave code:
  
  
  for slave in $BOND_SLAVES ; do
  ...
  # Ensure $slave is down.
  ip link set $slave down 2/dev/null
  if ! sysfs_add slaves $slave 2/dev/null ; then
echo Failed to enslave $slave to $BOND_MASTER. Is $BOND_MASTER 
ready and a bonding interface ? 2
  else
# Bring up slave if it is the target of an allow-bondX stanza.
# This is usefull to bring up slaves that need extra setup.
if [ -z $(which ifquery) ] || ifquery --allow \$BOND_MASTER\ 

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

I have introduced one big lock for ifupdown. The ifup, ifdown or ifquery
commands cannot be run simultaneously.

Since SEVERAL ifupdown pre/post scripts do need to make reentrant calls
do these commands I created on environment variable that disabled the
locking when reentrant calls are made to these scripts. This way sysv
and upstart networking scripts will never step into other's feet.

Attaching fix for ifupdown.

PS: This breaks even more ifenslave buggy behavior.. wait for next
comments.

** Patch added: trusty_ifupdown_0.7.47.2ubuntu4.2.debdiff
   
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1337873/+attachment/4200562/+files/trusty_ifupdown_0.7.47.2ubuntu4.2.debdiff

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

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in “ifupdown” package in Ubuntu:
  In Progress
Status in “ifupdown” package in Debian:
  New

Bug description:
  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.

  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.

  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!

  to be explained

  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.
  !!!

  #

   My setup:

  root@provisioned:~# cat /etc/modprobe.d/bonding.conf
  alias bond0 bonding options bonding mode=1 arp_interval=2000

  Both, /etc/init.d/networking and upstart network-interface begin
  enabled.

   Beginning:

  root@provisioned:~# cat /etc/network/interfaces
  # /etc/network/interfaces

  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  I'm able to boot with both scripts (networking and network-interface
  enabled) with no problem. I can also boot with only networking 
  script enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface stop/waiting
  networking start/running
  ---

  OR only the script network-interface enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface (eth2) start/running
  network-interface (lo) start/running
  network-interface (eth0) start/running
  network-interface (eth1) start/running
  ---

   Enabling bonding:

  Following ifenslave configuration example (/usr/share/doc/ifenslave/
  examples/two_hotplug_ethernet), my /etc/network/interfaces has to 
  look like this:

  ---
  auto eth1
  iface eth1 inet manual
  bond-master bond0

  auto eth2
  iface eth2 inet manual
  bond-master bond0

  auto bond0
  iface bond0 inet static
  bond-mode 1
  bond-miimon 100
  bond-primary eth1 eth2
address 192.168.169.1
netmask 255.255.255.0
broadcast 192.168.169.255
  ---

  Having both scripts running does not make any difference since we
  are missing bond-slaves keyword on slave interfaces, for ifenslave
  to work, and they are set to manual.

  Ifenslave code:

  
  for slave in $BOND_SLAVES ; do
  ...
  # Ensure $slave is down.
  ip link set $slave down 2/dev/null
  if ! sysfs_add slaves $slave 2/dev/null ; then
echo Failed to enslave $slave to $BOND_MASTER. Is $BOND_MASTER 
ready and a bonding interface ? 2
  else
# Bring up 

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

Let's try everything again from the beggining but now with a fixed
ifupdown version (no race conditions between upstart and sysv scripts
). My interfaces file will be exactly the same as the one proposed for
ifenslave examples:

---
auto eth1
iface eth1 inet manual
bond-master bond0

auto eth2
iface eth2 inet manual
bond-master bond0

auto bond0
iface bond0 inet static
bond-mode 1
bond-miimon 100
bond-primary eth1 eth2
 address 192.168.169.1
 netmask 255.255.255.0
 broadcast 192.168.169.255
 ---

We do have bond0 created but still no bonding configured:

---
root@provisioned:~# ifconfig bond0
bond0 Link encap:Ethernet  HWaddr 62:64:29:45:df:ef
  BROADCAST MASTER MULTICAST  MTU:1500  Metric:1
  RX packets:0 errors:0 dropped:0 overruns:0 frame:0
  TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

root@provisioned:~# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: load balancing (round-robin)
MII Status: down
MII Polling Interval (ms): 0
Up Delay (ms): 0
Down Delay (ms): 0
---

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

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in “ifupdown” package in Ubuntu:
  In Progress
Status in “ifupdown” package in Debian:
  New

Bug description:
  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.

  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.

  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!

  to be explained

  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.
  !!!

  #

   My setup:

  root@provisioned:~# cat /etc/modprobe.d/bonding.conf
  alias bond0 bonding options bonding mode=1 arp_interval=2000

  Both, /etc/init.d/networking and upstart network-interface begin
  enabled.

   Beginning:

  root@provisioned:~# cat /etc/network/interfaces
  # /etc/network/interfaces

  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  I'm able to boot with both scripts (networking and network-interface
  enabled) with no problem. I can also boot with only networking 
  script enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface stop/waiting
  networking start/running
  ---

  OR only the script network-interface enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface (eth2) start/running
  network-interface (lo) start/running
  network-interface (eth0) start/running
  network-interface (eth1) start/running
  ---

   Enabling bonding:

  Following ifenslave configuration example (/usr/share/doc/ifenslave/
  examples/two_hotplug_ethernet), my /etc/network/interfaces has to 
  look like this:

  ---
  auto eth1
  iface eth1 inet manual
  bond-master bond0

  auto eth2
  iface eth2 inet manual
  bond-master bond0

  auto bond0
  iface bond0 inet static
  bond-mode 1
  bond-miimon 100
  bond-primary eth1 eth2
address 192.168.169.1
netmask 255.255.255.0
broadcast 192.168.169.255
  ---

  Having both scripts 

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

And you can check that upstart got deadlocked:

---
root@provisioned:~# ps -ef | grep ifup
root   618 1  0 10:21 ?00:00:00 ifup --allow auto eth2
root   619 1  0 10:21 ?00:00:00 ifup --allow auto eth1
root   620 1  0 10:21 ?00:00:00 ifup --allow auto lo
root   621 1  0 10:21 ?00:00:00 ifup --allow auto eth0
root   726 1  0 10:21 ?00:00:00 ifup --allow auto bond0
root   739   733  0 10:21 ?00:00:00 ifup -a

root@provisioned:~# for i in `ps -ef | grep ifup | grep -v grep | awk '{print 
$2}'`; do echo $i; cat /proc/$i/environ; done
618
...UPSTART_INSTANCE=eth2...
...UPSTART_INSTANCE=eth1...
...UPSTART_INSTANCE=lo...
...UPSTART_INSTANCE=eth0...
...INSTANCE=UPSTART_JOB=networking...
---

As I said before, sysv scripts and upstart scripts were depending on
each other to run in parallel (unfortunately with race conditions)
to configure bonding. We can see here that one of upstart networking
processes (networking or network-instance) got the lock and is 
on an infinite loop waiting for other instance.. who is waiting for 
the lock.

---
root@provisioned:~# ps -ef | grep ifenslave
root   647   641  0 10:21 ?00:00:00 /bin/sh 
/etc/network/if-pre-up.d/ifenslave
---

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

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in “ifupdown” package in Ubuntu:
  In Progress
Status in “ifupdown” package in Debian:
  New

Bug description:
  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.

  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.

  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!

  to be explained

  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.
  !!!

  #

   My setup:

  root@provisioned:~# cat /etc/modprobe.d/bonding.conf
  alias bond0 bonding options bonding mode=1 arp_interval=2000

  Both, /etc/init.d/networking and upstart network-interface begin
  enabled.

   Beginning:

  root@provisioned:~# cat /etc/network/interfaces
  # /etc/network/interfaces

  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  I'm able to boot with both scripts (networking and network-interface
  enabled) with no problem. I can also boot with only networking 
  script enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface stop/waiting
  networking start/running
  ---

  OR only the script network-interface enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface (eth2) start/running
  network-interface (lo) start/running
  network-interface (eth0) start/running
  network-interface (eth1) start/running
  ---

   Enabling bonding:

  Following ifenslave configuration example (/usr/share/doc/ifenslave/
  examples/two_hotplug_ethernet), my /etc/network/interfaces has to 
  look like this:

  ---
  auto eth1
  iface eth1 inet manual
  bond-master bond0

  auto eth2
  iface eth2 inet manual
  bond-master bond0

  auto bond0
  iface bond0 inet static
  bond-mode 1
  bond-miimon 100
  bond-primary eth1 eth2
address 

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

YES!

---
root@provisioned:~# pstree -a
...
├─ifup --allow auto eth2
│   └─sh -c run-parts  /etc/network/if-pre-up.d
│   └─run-parts /etc/network/if-pre-up.d
│   └─ifenslave /etc/network/if-pre-up.d/ifenslave
│   └─sleep 0.1
---

One slave interface, eth2 in this case, got the ifupdown lock and is
running an infite loop waiting for the master bonding interface which
will never run without the lock.

Resuming:

So bonding had to have both networking scripts running (network-
interface and networking) to work AND having both scripts running 
would case race conditions sometime. Disabling one of the scripts
would also cause race condition if right triggers are set (like i
showed in this example). Fixing ifupdown race conditions led me to 
realize ifenslave is taking wrong decisions and can cause deadlocks.

Ifenslave must be fixed together...

* wait for next comments.

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

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in “ifupdown” package in Ubuntu:
  In Progress
Status in “ifupdown” package in Debian:
  New

Bug description:
  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.

  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.

  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!

  to be explained

  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.
  !!!

  #

   My setup:

  root@provisioned:~# cat /etc/modprobe.d/bonding.conf
  alias bond0 bonding options bonding mode=1 arp_interval=2000

  Both, /etc/init.d/networking and upstart network-interface begin
  enabled.

   Beginning:

  root@provisioned:~# cat /etc/network/interfaces
  # /etc/network/interfaces

  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  I'm able to boot with both scripts (networking and network-interface
  enabled) with no problem. I can also boot with only networking 
  script enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface stop/waiting
  networking start/running
  ---

  OR only the script network-interface enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface (eth2) start/running
  network-interface (lo) start/running
  network-interface (eth0) start/running
  network-interface (eth1) start/running
  ---

   Enabling bonding:

  Following ifenslave configuration example (/usr/share/doc/ifenslave/
  examples/two_hotplug_ethernet), my /etc/network/interfaces has to 
  look like this:

  ---
  auto eth1
  iface eth1 inet manual
  bond-master bond0

  auto eth2
  iface eth2 inet manual
  bond-master bond0

  auto bond0
  iface bond0 inet static
  bond-mode 1
  bond-miimon 100
  bond-primary eth1 eth2
address 192.168.169.1
netmask 255.255.255.0
broadcast 192.168.169.255
  ---

  Having both scripts running does not make any difference since we
  are missing bond-slaves keyword on slave interfaces, for ifenslave
  to work, and they are set to manual.

  Ifenslave code:

  
  for slave in $BOND_SLAVES ; do
  ...
  # Ensure $slave is down.
  ip link set $slave down 

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

Checking Ubuntu bzr tree...

---
inaddy@trusty.00064811:/bugs/00064811/sources/bazaar/ubuntu/$ git clone 
bzr::lp:ubuntu/ifenslave
Cloning into 'ifenslave'...
Most recent Ubuntu version: 3
Packaging branch version: 2.5ubuntu1
Packaging branch status: OUT-OF-DATE
Most recent Ubuntu version: 3
Packaging branch version: 2.5ubuntu1
Packaging branch status: OUT-OF-DATE
Most recent Ubuntu version: 3
Packaging branch version: 2.5ubuntu1
Packaging branch status: OUT-OF-DATE
Most recent Ubuntu version: 3
Packaging branch version: 2.5ubuntu1
Packaging branch status: OUT-OF-DATE
Checking connectivity... done.
---
---
inaddy@trusty.00064811:/bugs/00064811/sources/bazaar/ubuntu/ifenslave$ git tag 
| grep -e 2.4 -e 2.5
2.4
2.4ubuntu1
2.5
2.5ubuntu1
---
---
inaddy@trusty.00064811:/bugs/00064811/sources/bazaar/ubuntu/ifenslave$ git 
checkout 2.4
Previous HEAD position was 64392a5... Re-apply Ubuntu delta to new source.
HEAD is now at 1d22c9b... Added ifenslave-2.6.prerm to remove dangling 
alternatives (Closes: #736668). Thanks to Andreas Beckmann.
inaddy@trusty.00064811:/bugs/00064811/sources/bazaar/ubuntu/ifenslave$ git 
checkout 2.4ubuntu1
Previous HEAD position was 1d22c9b... Added ifenslave-2.6.prerm to remove 
dangling alternatives (Closes: #736668). Thanks to Andreas Beckmann.
HEAD is now at 64392a5... Re-apply Ubuntu delta to new source.
---
---
inaddy@trusty.00064811:/bugs/00064811/sources/bazaar/ubuntu/ifenslave$ git 
checkout 2.5
Previous HEAD position was 64392a5... Re-apply Ubuntu delta to new source.
HEAD is now at 1701e16... * ifupdown (= 0.7.46) compatibility update 
(Closes: #742410).   Thanks to Andrew Shadura. * Added versioned Depends on 
ifupdown (= 0.7.46).
inaddy@trusty.00064811:/bugs/00064811/sources/bazaar/ubuntu/ifenslave$ git 
checkout 2.5ubuntu1
Previous HEAD position was 1701e16... * ifupdown (= 0.7.46) compatibility 
update (Closes: #742410).   Thanks to Andrew Shadura. * Added versioned Depends 
on ifupdown (= 0.7.46).
HEAD is now at e47d568... * Merge from Debian unstable. Remaining changes:   - 
Upstart event based bond bringup: + Drop ethernet+wifi example + Drop 
two_ethernet example + Update ethernet+hotplug_wifi example + Update 
two_hotplug_ethernet example + Update pre-up and post-down scripts for 
event bringup + Update README.Debian examples   - Update scripts to use 
/run/network/ifstate instead of /etc/network/run/ifstate
---

I could see that we diverged from upstream code (Debian's) in favor of some 
other modifications.
Ubuntu fix would be different then a possible upstream fix.

We have nowadays:

inaddy@trusty.00064811:/bugs/00064811/sources/trusty/ifenslave$ rmadison 
ifenslave
 ifenslave | 2.4ubuntu1 | trusty | source, all
 ifenslave | 2.5ubuntu1 | utopic | source, all

Both need fixes for this particular case.

* wait for next comments.

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

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in “ifupdown” package in Ubuntu:
  In Progress
Status in “ifupdown” package in Debian:
  New

Bug description:
  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.

  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.

  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!

  to be explained

  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

After talking to Stéphane Graber, from Ubuntu Core Foundations Team, we
decided that I should implement independent locking for every interface
(like I have already proposed to Debian upstream project) and to
implement locking mechanisms for dependent interfaces inside the hooks.

So:

1) ifupdown would lock every given interface (or all if -a is given).

2) locking for child interfaces (slaves for bonding, attached to
bridges, ...) is going to be done inside hooks. Today most important
hooks for ifupdown are: bridging, vlan and bonding. I have to guarantee
those 3 are ok with any change made to ifupdown tool.

* wait for next comments/patches/actions.

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

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in “ifupdown” package in Ubuntu:
  In Progress
Status in “ifupdown” package in Debian:
  New

Bug description:
  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.

  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.

  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!

  to be explained

  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.
  !!!

  #

   My setup:

  root@provisioned:~# cat /etc/modprobe.d/bonding.conf
  alias bond0 bonding options bonding mode=1 arp_interval=2000

  Both, /etc/init.d/networking and upstart network-interface begin
  enabled.

   Beginning:

  root@provisioned:~# cat /etc/network/interfaces
  # /etc/network/interfaces

  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  I'm able to boot with both scripts (networking and network-interface
  enabled) with no problem. I can also boot with only networking 
  script enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface stop/waiting
  networking start/running
  ---

  OR only the script network-interface enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface (eth2) start/running
  network-interface (lo) start/running
  network-interface (eth0) start/running
  network-interface (eth1) start/running
  ---

   Enabling bonding:

  Following ifenslave configuration example (/usr/share/doc/ifenslave/
  examples/two_hotplug_ethernet), my /etc/network/interfaces has to 
  look like this:

  ---
  auto eth1
  iface eth1 inet manual
  bond-master bond0

  auto eth2
  iface eth2 inet manual
  bond-master bond0

  auto bond0
  iface bond0 inet static
  bond-mode 1
  bond-miimon 100
  bond-primary eth1 eth2
address 192.168.169.1
netmask 255.255.255.0
broadcast 192.168.169.255
  ---

  Having both scripts running does not make any difference since we
  are missing bond-slaves keyword on slave interfaces, for ifenslave
  to work, and they are set to manual.

  Ifenslave code:

  
  for slave in $BOND_SLAVES ; do
  ...
  # Ensure $slave is down.
  ip link set $slave down 2/dev/null
  if ! sysfs_add slaves $slave 2/dev/null ; then
echo Failed to enslave $slave to $BOND_MASTER. Is $BOND_MASTER 
ready and a bonding interface ? 2
  else
# Bring up slave if it is the target of an 

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

This bug is being fixed upstream together with the developer. I'll
provide the fix here as soon as it gets accepted upstream:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=753755

Thank you.

** Patch removed: ifupdown_0.7.47.2ubuntu4.2~lp1337873.diff
   
https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/1337873/+attachment/4145680/+files/ifupdown_0.7.47.2ubuntu4.2%7Elp1337873.diff

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

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in “ifupdown” package in Ubuntu:
  In Progress
Status in “ifupdown” package in Debian:
  New

Bug description:
  It was brought to my attention (by others) that ifupdown runs into
  race conditions on some specific cases.

  [Impact]

  When trying to deploy many servers at once (higher chances of
  happening) or from time-to-time, like any other intermittent race-
  condition. Interfaces are not brought up like they should and this has
  a big impact for servers that cannot rely on network start scripts.

  The problem is caused by a race condition when init(upstart) starts up
  network interfaces in parallel.

  [Test Case]

  Use attached script to reproduce the error (it might take some hours,
  in a single virtual machine, for the error to occur).

  (example 1)

  *** sequence to trigger race-condition ***

  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
    1-1. Wait for locking ifstate.lock
    file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
    1-2. Read ifstate file to check
     the target NIC.
    1-3. close(=release) ifstate.lock
     file.
    1-4. Judge that the target NIC
     isn't processed.
  2. Lock and update ifstate file.
     Release the lock.
    2. Lock and update ifstate file.
   Release the lock.

  (example 2)

  Bonding device using eth0.
  ifenslave for eth0 is also executed in parallel, eth0 remains down.

  *** sequence to trigger race-condition ***

  (a) ifenslave of eth0 (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
     /sys/class/net/bond0/bonding
 /slaves then NIC gets up
    4. Link down the target NIC.
    5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.

  (example 3)

  bonding is not set to active-backup as defined in config file: When
  the init(upstart) executes if-pre-up.d/ifenslave script and if-pre-
  up.d/vlan script for bond0 device in parallel, the if-pre-
  up.d/ifenslave script fails to change the bonding mode with a error
  message, bonding: unable to update mode of bond0 because interface is
  up..

  *** sequence to trigger race-condition ***

  (a)ifup bond0 (b)ifup -a
  ---
  1. Update statefile about bond0.
    1. Does nothing about bond0
   because statefile is already
   updated about it.
  2. ifenslave::setup_master()
     sysfs_change_down mode 1
     and link down bond0.
    2. Link up bond0 by the vlan
   script on the processing
   for linking up bond0.201(*1).
  3. echo 1  .../mode fails.

  [ /etc/network/if-pre-up.d/vlan ]

  46 if [ -n $IF_VLAN_RAW_DEVICE ]  [ ! -d /sys/class/net/$IFACE ]; then
  47 if [ ! -x /sbin/vconfig ]; then
  48 exit 0
  49 fi
  50 if ! ip link show dev $IF_VLAN_RAW_DEVICE  /dev/null; then
  51 echo $IF_VLAN_RAW_DEVICE does not exist, unable to create $IFACE
  52 exit 1
  53 fi
  54 ip link set up dev $IF_VLAN_RAW_DEVICE -- (*1).
  55 vconfig add $IF_VLAN_RAW_DEVICE $VLANID
  56 fi

  
  [Regression Potential]

   * Attaching proposed patch (for upstream as well) and describing
  potential later on today.

  [Other Info]

  Example: [ /etc/network/interfaces ]

  auto lo
  iface lo inet 

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

Im getting back to this after sometime. After the discussion was brought
to upstream we did not get feedback regarding proposed changes but
investigating further it is clear that ifupdown is suffering from race
conditions that cannot be solved simply by creating:

1) big lock - since its ifup/ifdown/ifquery are reentrant*
2) big lock - does not attend to interface order/priority for parallel 
executions**
3) fine-grained lock - does not attend interface order/priority for parallel 
executions**

* could be solved by ENV variable being set not to lock childs) by up/down 
scripts.
**  group of interfaces such as bridges and all interfaces connected to it, 
interfaces and all vlans connected to it

Final approach here will be to guarantee:

1) interfaces should be locked independently on executions
2) locks have to respect interface hierarchy (locking group of inter-connected 
interfaces such as bridges/interfaces, interfaces/vlans)
3) all up/down scripts have to be reviewed after any locking mechanism change 
(deadlock by reentrant calls)

IMO

1) stanzas should be created to group interfaces to be locked (for parallel 
executions) respecting hierarchy/order between them
2) locking/state have to be together and independent 

FINALLY

The change to guarantee all that will involve code AND interfaces file
change (for adding special stanzas to make sure appropriate order and
locking is done during interfaces activation). It is not clear if this
change will be smooth enough for a stable release update. If not I'll
try to provide a PPA to address any needed code-change for those who
suffer from this issue.

BY NOW

The only way to guarantee interfaces activation ordering (without
suffering from intermittent race conditions like the one explained on
this bug) would be to activate interface one by one outside sysv/upstart
scripts OR to use pre/post commands with reentrant calls to ifupdown
based on the desired order.

Any comments here are much appreciated.

Thank you

Rafael Tinoco

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

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in “ifupdown” package in Ubuntu:
  In Progress
Status in “ifupdown” package in Debian:
  New

Bug description:
  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.

  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.

  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!

  to be explained

  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.
  !!!

  #

   My setup:

  root@provisioned:~# cat /etc/modprobe.d/bonding.conf
  alias bond0 bonding options bonding mode=1 arp_interval=2000

  Both, /etc/init.d/networking and upstart network-interface begin
  enabled.

   Beginning:

  root@provisioned:~# cat /etc/network/interfaces
  # /etc/network/interfaces

  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  I'm able to boot with both scripts (networking and network-interface
  enabled) with no problem. I can also boot with only networking 
  script enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface stop/waiting
  networking start/running

[Touch-packages] [Bug 1401141] Re: IPoIB does not work on Ubuntu due to DHCP

[Rafael David Tinoco]

** Changed in: isc-dhcp (Ubuntu)
 Assignee: (unassigned) = Rafael David Tinoco (inaddy)

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

Title:
  IPoIB does not work on Ubuntu due to DHCP

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  =
  From IETF documentation:
  
http://git.openfabrics.org/pub/scm/~rupertd/docs/release_notes/ipoib_release_notes.txt
  ...
  Note: Two patches for DHCP are required for supporting IPoIB. The patch files
  for DHCP v3.0.4 are available under the docs/dhcp/ directory.

  Standard DHCP fields holding MAC addresses are not large enough to contain an
  IPoIB hardware address. To overcome this problem, DHCP over InfiniBand 
messages
  convey a client identifier field used to identify the DHCP session. This 
client
  identifier field can be used to associate an IP address with a client 
identifier
  value, such that the DHCP server will grant the same IP address to any client
  that conveys this client identifier.
  ...
  In order to use a DHCP client identifier, you need to first create a
  configuration file that defines the DHCP client identifier. Then run the DHCP
  client with this file using the following command:
  dhclient cf client conf file IB network interface name
  Example of a configuration file for the ConnectX (PCI Device ID 26428), called
  dhclient.conf:Ubuntu 14.04.1 LTS
  # The value indicates a hexadecimal number
  interface ib1 {
  send dhcp-client-identifier
  ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:00:10:39;
  }
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: IPoIB does not work on Ubuntu due to DHCP

[Rafael David Tinoco]

Tks Mathieu,

Description was made based on a fast look into what was needed. 
Thank you very much for your comment. I'll work on that as soon as I get some 
free time.
Feel free to provide any other comment that might be useful to this.

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

Title:
  IPoIB does not work on Ubuntu due to DHCP

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  =
  From IETF documentation:
  
http://git.openfabrics.org/pub/scm/~rupertd/docs/release_notes/ipoib_release_notes.txt
  ...
  Note: Two patches for DHCP are required for supporting IPoIB. The patch files
  for DHCP v3.0.4 are available under the docs/dhcp/ directory.

  Standard DHCP fields holding MAC addresses are not large enough to contain an
  IPoIB hardware address. To overcome this problem, DHCP over InfiniBand 
messages
  convey a client identifier field used to identify the DHCP session. This 
client
  identifier field can be used to associate an IP address with a client 
identifier
  value, such that the DHCP server will grant the same IP address to any client
  that conveys this client identifier.
  ...
  In order to use a DHCP client identifier, you need to first create a
  configuration file that defines the DHCP client identifier. Then run the DHCP
  client with this file using the following command:
  dhclient cf client conf file IB network interface name
  Example of a configuration file for the ConnectX (PCI Device ID 26428), called
  dhclient.conf:Ubuntu 14.04.1 LTS
  # The value indicates a hexadecimal number
  interface ib1 {
  send dhcp-client-identifier
  ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:00:10:39;
  }
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: IPoIB does not work on Ubuntu due to DHCP

[Rafael David Tinoco]

** Changed in: isc-dhcp (Ubuntu)
   Status: New = In Progress

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

Title:
  IPoIB does not work on Ubuntu due to DHCP

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  =
  From IETF documentation:
  
http://git.openfabrics.org/pub/scm/~rupertd/docs/release_notes/ipoib_release_notes.txt
  ...
  Note: Two patches for DHCP are required for supporting IPoIB. The patch files
  for DHCP v3.0.4 are available under the docs/dhcp/ directory.

  Standard DHCP fields holding MAC addresses are not large enough to contain an
  IPoIB hardware address. To overcome this problem, DHCP over InfiniBand 
messages
  convey a client identifier field used to identify the DHCP session. This 
client
  identifier field can be used to associate an IP address with a client 
identifier
  value, such that the DHCP server will grant the same IP address to any client
  that conveys this client identifier.
  ...
  In order to use a DHCP client identifier, you need to first create a
  configuration file that defines the DHCP client identifier. Then run the DHCP
  client with this file using the following command:
  dhclient cf client conf file IB network interface name
  Example of a configuration file for the ConnectX (PCI Device ID 26428), called
  dhclient.conf:Ubuntu 14.04.1 LTS
  # The value indicates a hexadecimal number
  interface ib1 {
  send dhcp-client-identifier
  ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:00:10:39;
  }
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

** Summary changed:

- IPoIB does not work on Ubuntu due to DHCP
+ DHCP server does not work for IPoIB (Infiniband)

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  =
  From IETF documentation:
  
http://git.openfabrics.org/pub/scm/~rupertd/docs/release_notes/ipoib_release_notes.txt
  ...
  Note: Two patches for DHCP are required for supporting IPoIB. The patch files
  for DHCP v3.0.4 are available under the docs/dhcp/ directory.

  Standard DHCP fields holding MAC addresses are not large enough to contain an
  IPoIB hardware address. To overcome this problem, DHCP over InfiniBand 
messages
  convey a client identifier field used to identify the DHCP session. This 
client
  identifier field can be used to associate an IP address with a client 
identifier
  value, such that the DHCP server will grant the same IP address to any client
  that conveys this client identifier.
  ...
  In order to use a DHCP client identifier, you need to first create a
  configuration file that defines the DHCP client identifier. Then run the DHCP
  client with this file using the following command:
  dhclient cf client conf file IB network interface name
  Example of a configuration file for the ConnectX (PCI Device ID 26428), called
  dhclient.conf:Ubuntu 14.04.1 LTS
  # The value indicates a hexadecimal number
  interface ib1 {
  send dhcp-client-identifier
  ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:00:10:39;
  }
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: IPoIB does not work on Ubuntu due to DHCP

[Rafael David Tinoco]

Hello Brian, sorry I was out due to end-of-year holidays + vacation :o).

I'll be providing them a hotfixed dhcp server and asking for SRU
sponsorship soon.

Tks

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

Title:
  IPoIB does not work on Ubuntu due to DHCP

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  =
  From IETF documentation:
  
http://git.openfabrics.org/pub/scm/~rupertd/docs/release_notes/ipoib_release_notes.txt
  ...
  Note: Two patches for DHCP are required for supporting IPoIB. The patch files
  for DHCP v3.0.4 are available under the docs/dhcp/ directory.

  Standard DHCP fields holding MAC addresses are not large enough to contain an
  IPoIB hardware address. To overcome this problem, DHCP over InfiniBand 
messages
  convey a client identifier field used to identify the DHCP session. This 
client
  identifier field can be used to associate an IP address with a client 
identifier
  value, such that the DHCP server will grant the same IP address to any client
  that conveys this client identifier.
  ...
  In order to use a DHCP client identifier, you need to first create a
  configuration file that defines the DHCP client identifier. Then run the DHCP
  client with this file using the following command:
  dhclient cf client conf file IB network interface name
  Example of a configuration file for the ConnectX (PCI Device ID 26428), called
  dhclient.conf:Ubuntu 14.04.1 LTS
  # The value indicates a hexadecimal number
  interface ib1 {
  send dhcp-client-identifier
  ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:00:10:39;
  }
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: IPoIB does not work on Ubuntu due to DHCP

[Rafael David Tinoco]

I've provided the following PPA:

https://launchpad.net/~inaddy/+archive/ubuntu/lp1401141

# add-apt-repository ppa:inaddy/lp1401141
# apt-get update
# apt-get install isc-dhcp-server

(make sure to have version 4.2.4-7ubuntu13~lp1401141~1 installed)

Could you please test and provide feedback if GPXE patch solves the
issue ?

If it does I'll work together with sponsors to provide SRU to isc-dhcp-
server package.

Thank you

Tinoco

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

Title:
  IPoIB does not work on Ubuntu due to DHCP

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  =
  From IETF documentation:
  
http://git.openfabrics.org/pub/scm/~rupertd/docs/release_notes/ipoib_release_notes.txt
  ...
  Note: Two patches for DHCP are required for supporting IPoIB. The patch files
  for DHCP v3.0.4 are available under the docs/dhcp/ directory.

  Standard DHCP fields holding MAC addresses are not large enough to contain an
  IPoIB hardware address. To overcome this problem, DHCP over InfiniBand 
messages
  convey a client identifier field used to identify the DHCP session. This 
client
  identifier field can be used to associate an IP address with a client 
identifier
  value, such that the DHCP server will grant the same IP address to any client
  that conveys this client identifier.
  ...
  In order to use a DHCP client identifier, you need to first create a
  configuration file that defines the DHCP client identifier. Then run the DHCP
  client with this file using the following command:
  dhclient cf client conf file IB network interface name
  Example of a configuration file for the ConnectX (PCI Device ID 26428), called
  dhclient.conf:Ubuntu 14.04.1 LTS
  # The value indicates a hexadecimal number
  interface ib1 {
  send dhcp-client-identifier
  ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:00:10:39;
  }
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

Attaching fix for Vivid.

Asking for sponsorship and for the Stable Release Update to be accepted.

Thank you

Rafael Tinoco

** Patch added: vivid_isc-dhcp_4.3.1-5ubuntu3.debdiff
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+attachment/4338908/+files/vivid_isc-dhcp_4.3.1-5ubuntu3.debdiff

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

** Patch removed: utopic_isc-dhcp_4.2.4-7ubuntu15.debdiff
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+attachment/4335363/+files/utopic_isc-dhcp_4.2.4-7ubuntu15.debdiff

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

Providing debdiff for Trusty (fixes the issue)

** Patch added: trusty_isc-dhcp_4.2.4-7ubuntu13.debdiff
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+attachment/4335337/+files/trusty_isc-dhcp_4.2.4-7ubuntu13.debdiff

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

Providing debdiff for Utopic (fixes the issue)


** Patch added: utopic_isc-dhcp_4.2.4-7ubuntu15.debdiff
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+attachment/4335363/+files/utopic_isc-dhcp_4.2.4-7ubuntu15.debdiff

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

isc-dhcp-server | 4.2.4-7ubuntu12   | trusty   | amd64, 
arm64, armhf, i386, powerpc, ppc64el
 isc-dhcp-server | 4.2.4-7ubuntu14   | utopic   | amd64, 
arm64, armhf, i386, powerpc, ppc64el

I'll have to adequate the backport to Vivid:

 isc-dhcp-server | 4.3.1-5ubuntu2| vivid|
amd64, arm64, armhf, i386, powerpc, ppc64el

Will provide the merge proposal soon.

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

** Description changed:

+ [Impact]
+ 
+  * DHCP for InfiniBand IPoIB does not work currently.
+  * After providing missing GPXE patch it had problems (by Mellanox tests).
+  * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated. 
+ 
+ [Test Case]
+ 
+  * To have IPoIB devices (2 if possible)
+  * Try to acquire IP using either DHCPv4 or DHCPv6
+ 
+ [Regression Potential]
+ 
+  * DHCP for InfiniBand was not working
+  * Based on already implemented code (Fedora)
+  * Mellanox has tested it
+ 
+ [Other Info]
+ 
+ Original BUG description:
+ 
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12
  
  The current DHCP package in Ubuntu can't handle IPoIB clients.  For IB,
  Mellanox uses IPoIB, which is “Eth emulator” for the control path. DHCP
  is not working in this mode without a patch for DHCP server.
  
- =
- From IETF documentation:
- 
http://git.openfabrics.org/pub/scm/~rupertd/docs/release_notes/ipoib_release_notes.txt
- ...
- Note: Two patches for DHCP are required for supporting IPoIB. The patch files
- for DHCP v3.0.4 are available under the docs/dhcp/ directory.
- 
- Standard DHCP fields holding MAC addresses are not large enough to contain an
- IPoIB hardware address. To overcome this problem, DHCP over InfiniBand 
messages
- convey a client identifier field used to identify the DHCP session. This 
client
- identifier field can be used to associate an IP address with a client 
identifier
- value, such that the DHCP server will grant the same IP address to any client
- that conveys this client identifier.
- ...
- In order to use a DHCP client identifier, you need to first create a
- configuration file that defines the DHCP client identifier. Then run the DHCP
- client with this file using the following command:
- dhclient cf client conf file IB network interface name
- Example of a configuration file for the ConnectX (PCI Device ID 26428), called
- dhclient.conf:Ubuntu 14.04.1 LTS
- # The value indicates a hexadecimal number
- interface ib1 {
- send dhcp-client-identifier
- ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:00:10:39;
- }
- 
+ ISC-DHCP-SERVER Missing GPXE patch.

** Description changed:

  [Impact]
  
-  * DHCP for InfiniBand IPoIB does not work currently.
-  * After providing missing GPXE patch it had problems (by Mellanox tests).
-  * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated. 
+  * DHCP for InfiniBand IPoIB does not work currently.
+  * After providing missing GPXE patch it had problems (by Mellanox tests).
+  * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.
  
  [Test Case]
  
-  * To have IPoIB devices (2 if possible)
-  * Try to acquire IP using either DHCPv4 or DHCPv6
+  * To have IPoIB devices (2 if possible)
+  * Try to acquire IP using either DHCPv4 or DHCPv6
  
  [Regression Potential]
  
-  * DHCP for InfiniBand was not working
-  * Based on already implemented code (Fedora)
-  * Mellanox has tested it
+  * DHCP for InfiniBand was not working
+  * Based on already implemented code (Fedora)
+  * Mellanox has tested it
  
  [Other Info]
  
  Original BUG description:
  
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12
  
  The current DHCP package in Ubuntu can't handle IPoIB clients.  For IB,
  Mellanox uses IPoIB, which is “Eth emulator” for the control path. DHCP
  is not working in this mode without a patch for DHCP server.
  
  ISC-DHCP-SERVER Missing GPXE patch.
+ 
+ After applying GPXE patch only we faced the following problems:
+ 
+ After apply
+ 
+ 1.
+ 
+ dhcp ipoib, does not write in the log on which interface the dhcp work
+ upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
+ start” we don’t see the line that tells on which interfaces the dhcpd is
+ listening on the /var/log/syslog when running it with “dhcpd –d” command
+ – we do see it.
+ 
+ 2.
+ 
+ dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces in
+ a parallel using the following setup:
+ 
+ HOST_A: 
+ acting as a dhcp server, listening on one of its 
+ ipoib (ib0) interfaces.
+ 
+ HOST_B: 
+ running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
+ and ib2 are two ports onf the same HCA both interfaces are
+ configured in /etc/interfaces such as:
+ 
+ auto ib1
+ iface ib1 inet6 dhcp
+both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.
+ 
+ We are running on the client (HOST_B) the following:
+ 
+ $ ifup ib1
+ - ib1 get configured as expected
+ 
+ but then when we run on the other interface:
+ $ ifup ib2
+ - ib2 get configured, but ib1 is losing its configuration

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to isc-dhcp in Ubuntu.

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

Kamal,

Sorry does that mean the issue was fixed or the issue is still there ?
We are finishing setting our IB environment here and I'll be able to
test it myself, just wanted to clarify meanwhile.

Thank you

Rafael Tinoco

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  =
  From IETF documentation:
  
http://git.openfabrics.org/pub/scm/~rupertd/docs/release_notes/ipoib_release_notes.txt
  ...
  Note: Two patches for DHCP are required for supporting IPoIB. The patch files
  for DHCP v3.0.4 are available under the docs/dhcp/ directory.

  Standard DHCP fields holding MAC addresses are not large enough to contain an
  IPoIB hardware address. To overcome this problem, DHCP over InfiniBand 
messages
  convey a client identifier field used to identify the DHCP session. This 
client
  identifier field can be used to associate an IP address with a client 
identifier
  value, such that the DHCP server will grant the same IP address to any client
  that conveys this client identifier.
  ...
  In order to use a DHCP client identifier, you need to first create a
  configuration file that defines the DHCP client identifier. Then run the DHCP
  client with this file using the following command:
  dhclient cf client conf file IB network interface name
  Example of a configuration file for the ConnectX (PCI Device ID 26428), called
  dhclient.conf:Ubuntu 14.04.1 LTS
  # The value indicates a hexadecimal number
  interface ib1 {
  send dhcp-client-identifier
  ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:00:10:39;
  }
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

Awesome!! I'll clarify what was done in this bug case and ask for the
fix to be accepted as a Stable Release Update for our isc-dhcp-package
(showing that our IB support was broken). I may need you to verify the
fix after it gets released to -proposed.

Thank you

Rafael

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  =
  From IETF documentation:
  
http://git.openfabrics.org/pub/scm/~rupertd/docs/release_notes/ipoib_release_notes.txt
  ...
  Note: Two patches for DHCP are required for supporting IPoIB. The patch files
  for DHCP v3.0.4 are available under the docs/dhcp/ directory.

  Standard DHCP fields holding MAC addresses are not large enough to contain an
  IPoIB hardware address. To overcome this problem, DHCP over InfiniBand 
messages
  convey a client identifier field used to identify the DHCP session. This 
client
  identifier field can be used to associate an IP address with a client 
identifier
  value, such that the DHCP server will grant the same IP address to any client
  that conveys this client identifier.
  ...
  In order to use a DHCP client identifier, you need to first create a
  configuration file that defines the DHCP client identifier. Then run the DHCP
  client with this file using the following command:
  dhclient cf client conf file IB network interface name
  Example of a configuration file for the ConnectX (PCI Device ID 26428), called
  dhclient.conf:Ubuntu 14.04.1 LTS
  # The value indicates a hexadecimal number
  interface ib1 {
  send dhcp-client-identifier
  ff:00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:00:10:39;
  }
  

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

Fixed utopic SRU patch and attached it again.

** Patch added: utopic_isc-dhcp_4.2.4-7ubuntu15.debdiff
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+attachment/4335719/+files/utopic_isc-dhcp_4.2.4-7ubuntu15.debdiff

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1337873] Re: Precise, Trusty, Utopic - ifupdown initialization problems caused by race condition

[Rafael David Tinoco]

** Changed in: ifupdown (Ubuntu)
 Assignee: Rafael David Tinoco (inaddy) = (unassigned)

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

Title:
  Precise, Trusty, Utopic - ifupdown initialization problems caused by
  race condition

Status in ifupdown package in Ubuntu:
  In Progress
Status in ifupdown package in Debian:
  New

Bug description:
  * please consider my bonding examples are using eth1 and eth2 as slave
   interfaces.

  ifupdown some race conditions explained bellow. ifenslave does not
  behave well with sysv networking and upstart network-interface scripts
  running together.

  
  case 1)
  (a) ifup eth0 (b) ifup -a for eth0
  -
  1-1. Lock ifstate.lock file.
1-1. Wait for locking ifstate.lock
file.
  1-2. Read ifstate file to check
   the target NIC.
  1-3. close(=release) ifstate.lock
   file.
  1-4. Judge that the target NIC
   isn't processed.
1-2. Read ifstate file to check
 the target NIC.
1-3. close(=release) ifstate.lock
 file.
1-4. Judge that the target NIC
 isn't processed.
  2. Lock and update ifstate file.
 Release the lock.
2. Lock and update ifstate file.
   Release the lock.
  !!!

  to be explained

  !!!
  case 2)
  (a) ifenslave of eth0  (b) ifenslave of eth0
  --
  3. Execute ifenslave of eth0.  3. Execute ifenslave of eth0.
  4. Link down the target NIC.
  5. Write NIC id to
 /sys/class/net/bond0/bonding
 /slaves then NIC gets up
4. Link down the target NIC.
5. Fails to write NIC id to
   /sys/class/net/bond0/bonding/
   slaves it is already written.
  !!!

  #

   My setup:

  root@provisioned:~# cat /etc/modprobe.d/bonding.conf
  alias bond0 bonding options bonding mode=1 arp_interval=2000

  Both, /etc/init.d/networking and upstart network-interface begin
  enabled.

   Beginning:

  root@provisioned:~# cat /etc/network/interfaces
  # /etc/network/interfaces

  auto lo
  iface lo inet loopback

  auto eth0
  iface eth0 inet dhcp

  I'm able to boot with both scripts (networking and network-interface
  enabled) with no problem. I can also boot with only networking 
  script enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface stop/waiting
  networking start/running
  ---

  OR only the script network-interface enabled:

  ---
  root@provisioned:~# initctl list | grep network
  network-interface (eth2) start/running
  network-interface (lo) start/running
  network-interface (eth0) start/running
  network-interface (eth1) start/running
  ---

   Enabling bonding:

  Following ifenslave configuration example (/usr/share/doc/ifenslave/
  examples/two_hotplug_ethernet), my /etc/network/interfaces has to 
  look like this:

  ---
  auto eth1
  iface eth1 inet manual
  bond-master bond0

  auto eth2
  iface eth2 inet manual
  bond-master bond0

  auto bond0
  iface bond0 inet static
  bond-mode 1
  bond-miimon 100
  bond-primary eth1 eth2
address 192.168.169.1
netmask 255.255.255.0
broadcast 192.168.169.255
  ---

  Having both scripts running does not make any difference since we
  are missing bond-slaves keyword on slave interfaces, for ifenslave
  to work, and they are set to manual.

  Ifenslave code:

  
  for slave in $BOND_SLAVES ; do
  ...
  # Ensure $slave is down.
  ip link set $slave down 2/dev/null
  if ! sysfs_add slaves $slave 2/dev/null ; then
echo Failed to enslave $slave to $BOND_MASTER. Is $BOND_MASTER 
ready and a bonding interface ? 2
  else
# Bring up slave if it is the target of an allow-bondX stanza.
# This is usefull to bring up slaves that need extra setup.
if [ -z $(which ifquery) ] || ifquery --allow \$BOND_MASTER\ 
--list | grep -q $slave; then
ifup $v --allow $BOND_MASTER $slave
fi
  

  Without the keyword bond-slaves on the master interface declaration,
  ifenslave will NOT bring any slave interface up on the master 
  interface ifup invocation. 

  *** Part 1

  So, having networking sysv init script AND upstart network-interface
  script running together... the following

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

** Changed in: isc-dhcp (Ubuntu Trusty)
 Assignee: (unassigned) = Rafael David Tinoco (inaddy)

** Changed in: isc-dhcp (Ubuntu Utopic)
 Assignee: (unassigned) = Rafael David Tinoco (inaddy)

** Changed in: isc-dhcp (Ubuntu Vivid)
 Assignee: (unassigned) = Rafael David Tinoco (inaddy)

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  Confirmed
Status in isc-dhcp source package in Utopic:
  Confirmed
Status in isc-dhcp source package in Vivid:
  Confirmed

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

I'm reattaching debdiff for Trusty since a version was uploaded to
-proposed while this was waiting for sponsorship. Please include Trusty
in the affected list and consider this patch, being attached, as the
fix for Trusty.

Thank you

Rafael Tinoco

** Patch removed: trusty_isc-dhcp_4.2.4-7ubuntu13.debdiff
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+attachment/4335337/+files/trusty_isc-dhcp_4.2.4-7ubuntu13.debdiff

** Patch added: trusty_isc-dhcp_4.2.4-7ubuntu12.3.debdiff
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+attachment/4396242/+files/trusty_isc-dhcp_4.2.4-7ubuntu12.3.debdiff

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Utopic:
  New
Status in isc-dhcp source package in Vivid:
  New

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1321418] Re: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk

[Rafael David Tinoco]

Hello, for all those interested..

I'll be providing the fix by backporting/cherry-picking commit
9a1d614df217 from upstream mentioned by Theo so we can create a SRU for
this...

inaddy@xxx:~/sources/upstream/e2fsprogs$ git tag --contains 9a1d614df217
v1.42.12

From rmadison all affected versions are:

- Precise (1.42-1ubuntu2.2)
- Trusty (1.42.9-3ubuntu1.2)
- Utopic (1.42.10-1.1ubuntu1)

Vivid is ok (1.42.12-1ubuntu2)

I already cherry-picked the commit and I'm solving conflicts. Then I'll
test the fsck with the image provided by Theo to see if it solves the
issue and ask for SRU.

Thank you!

Rafael Tinoco

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

** Changed in: e2fsprogs (Ubuntu)
 Assignee: Theodore Ts'o (tytso) = Rafael David Tinoco (inaddy)

** Tags added: cts

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

Title:
  fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk

Status in e2fsprogs package in Ubuntu:
  In Progress

Bug description:
  The last few times my root ext4 filesystem had its regularly-scheduled
  boot-time check, errors were reported. The first time it happened, I
  simply told the system to fix the errors, but since they kept coming
  up again, I decided to look more closely. I booted from a live USB
  drive, assembled my raid partitions, and ran fsck.ext4 manually.

  Without any options, fsck.ext4 simply reported that the filesystem was
  clean, and exited. Things got more interesting when I ran with -f. It
  reported several multiply-claimed blocks, and when I told fsck to go
  ahead and clone them, it failed with an internal error. Repeated runs
  of fsck revealed that the filesystem was still not fixed, and repeated
  attempts to fix the problem also failed, reporting that multiply-
  claimed blocks already reassigned or cloned.

  I was lucky in that the files in question were unimportant, so
  deleting one of them and running fsck again seems to have fixed my
  problem this time. However, fsck's internal error and failure to fix
  the problem in the first place is worrisome.

  Here's the full output:

  $ sudo fsck.ext4 -f /dev/md/1
  e2fsck 1.42.8 (20-Jun-2013)
  Pass 1: Checking inodes, blocks, and sizes

  Running additional passes to resolve blocks claimed by more than one inode...
  Pass 1B: Rescanning for multiply-claimed blocks
  Multiply-claimed block(s) in inode 27528089: 73467268 9287 9288 9289 9290 9291
  9292 9293
  Multiply-claimed block(s) in inode 27528105: 73467268 9287 9288 9289 9290 9291
  9292 9293
  Pass 1C: Scanning directories for inodes with multiply-claimed blocks Pass 1D:
  Reconciling multiply-claimed blocks
  (There are 2 inodes containing multiply-claimed blocks.)

  File
  /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg
  (inode #27528089, mod time Mon Jan 13 02:50:08 2014)
has 7 multiply-claimed block(s), shared with 1 file(s):
  
/home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db
  (inode #27528105, mod time Mon Jan 13 02:50:08 2014)
  Clone multiply-claimed blocksy? yes
  clone_file_block: internal error: can't find dup_blk for 73467268

  clone_file_block: internal error: can't find dup_blk for 73467268

  File
  
/home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db
  (inode #27528105, mod time Mon Jan 13 02:50:08 2014)
has 7 multiply-claimed block(s), shared with 1 file(s):
  /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg
  (inode #27528089, mod time Mon Jan 13 02:50:08 2014)
  Multiply-claimed blocks already reassigned or cloned.

  Pass 2: Checking directory structure
  Pass 3: Checking directory connectivity
  Pass 4: Checking reference counts
  Pass 5: Checking group summary information

  root: * FILE SYSTEM WAS MODIFIED *
  root: 1038356/30285824 files (0.3% non-contiguous), 106319516/121119454 blocks

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

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

[Touch-packages] [Bug 1321418] Re: fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk

[Rafael David Tinoco]

Okay, I have provided one PPA for precise for this particular case:

https://launchpad.net/~inaddy/+archive/ubuntu/lp1321418

Cherry-picking 2 needed patches from upstream.

I have tested also the fsck with the filesystem that Theo provided and
version from PPA fixes the problems.

Second fsck run shows:

inaddy@xxx:~/filesystem$ fsck.ext4 -f ./f_dup5.img
e2fsck 1.42 (29-Nov-2011)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
./f_dup5.img: 13/16 files (15.4% non-contiguous), 65/100 blocks

No errors.

I'm waiting for feedback from some users to provide debdiffs to be
proposed as SRU for Precise, Trusty and Utopic.

Thank you very much for reporting this.

Rafael Tinoco

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

Title:
  fsck.ext4 fails to fix multiply-claimed blocks: can't find dup_blk

Status in e2fsprogs package in Ubuntu:
  In Progress

Bug description:
  The last few times my root ext4 filesystem had its regularly-scheduled
  boot-time check, errors were reported. The first time it happened, I
  simply told the system to fix the errors, but since they kept coming
  up again, I decided to look more closely. I booted from a live USB
  drive, assembled my raid partitions, and ran fsck.ext4 manually.

  Without any options, fsck.ext4 simply reported that the filesystem was
  clean, and exited. Things got more interesting when I ran with -f. It
  reported several multiply-claimed blocks, and when I told fsck to go
  ahead and clone them, it failed with an internal error. Repeated runs
  of fsck revealed that the filesystem was still not fixed, and repeated
  attempts to fix the problem also failed, reporting that multiply-
  claimed blocks already reassigned or cloned.

  I was lucky in that the files in question were unimportant, so
  deleting one of them and running fsck again seems to have fixed my
  problem this time. However, fsck's internal error and failure to fix
  the problem in the first place is worrisome.

  Here's the full output:

  $ sudo fsck.ext4 -f /dev/md/1
  e2fsck 1.42.8 (20-Jun-2013)
  Pass 1: Checking inodes, blocks, and sizes

  Running additional passes to resolve blocks claimed by more than one inode...
  Pass 1B: Rescanning for multiply-claimed blocks
  Multiply-claimed block(s) in inode 27528089: 73467268 9287 9288 9289 9290 9291
  9292 9293
  Multiply-claimed block(s) in inode 27528105: 73467268 9287 9288 9289 9290 9291
  9292 9293
  Pass 1C: Scanning directories for inodes with multiply-claimed blocks Pass 1D:
  Reconciling multiply-claimed blocks
  (There are 2 inodes containing multiply-claimed blocks.)

  File
  /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg
  (inode #27528089, mod time Mon Jan 13 02:50:08 2014)
has 7 multiply-claimed block(s), shared with 1 file(s):
  
/home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db
  (inode #27528105, mod time Mon Jan 13 02:50:08 2014)
  Clone multiply-claimed blocksy? yes
  clone_file_block: internal error: can't find dup_blk for 73467268

  clone_file_block: internal error: can't find dup_blk for 73467268

  File
  
/home/user/.thumbnails/normal/51048a1138d61df87bf3fdc7deed50e3.png/WebpageIcons.db
  (inode #27528105, mod time Mon Jan 13 02:50:08 2014)
has 7 multiply-claimed block(s), shared with 1 file(s):
  /home/user/dir/subdir/05.09.2013_13.15.48.300.jpg
  (inode #27528089, mod time Mon Jan 13 02:50:08 2014)
  Multiply-claimed blocks already reassigned or cloned.

  Pass 2: Checking directory structure
  Pass 3: Checking directory connectivity
  Pass 4: Checking reference counts
  Pass 5: Checking group summary information

  root: * FILE SYSTEM WAS MODIFIED *
  root: 1038356/30285824 files (0.3% non-contiguous), 106319516/121119454 blocks

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

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

I have tested ISC-DHCP for Trusty, Utopic  Vivid for InfiniBand IPoIB
and it is working as expected.

Flagging as verification-done.

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

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  Fix Committed
Status in isc-dhcp source package in Utopic:
  Fix Committed
Status in isc-dhcp source package in Vivid:
  Fix Committed

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

I received good feedback from a User by email:


Dear sir,

A couple of days ago I ran a manual update on Zorin OS 9 32 bits (based on 
Ubuntu 14.04 LTS).
The only update offered at that time was isc-dhcp.

How interesting, I thought ... will this fix my WIFI connection problems?
I think it did!

Before the update, reconnecting automatically to an existing WIFI
connection could take a long time. Sometimes about 10 minutes. As far as
I remember, connection after a clean reboot was usually normal, but
there were problems after the system was suspended or hibernated.  I did
not investigate the problem thouroughly, but I noticed that most people
with this kind of problem blame energy management.

After the update of isc-dhcp, my system reconnects almost instantly.



Thanks for the update(s),


-- 
Hans van der Weij


It looks like this fix also fixed possible regression in isc-dhcp.
Posting here for documentation, hope Hans does not mind.

Thank you

Rafael Tinoco

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  Fix Released
Status in isc-dhcp source package in Utopic:
  Fix Released
Status in isc-dhcp source package in Vivid:
  Fix Released

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  - ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  - ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1292055] Re: dhclient fail on InfiniBand HW

[Rafael David Tinoco]

*** This bug is a duplicate of bug 1401141 ***
https://bugs.launchpad.net/bugs/1401141

** Changed in: isc-dhcp (Ubuntu)
 Assignee: (unassigned) = Rafael David Tinoco (inaddy)

** This bug has been marked a duplicate of bug 1401141
   DHCP server does not work for IPoIB (Infiniband)

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

Title:
  dhclient fail on InfiniBand HW

Status in isc-dhcp package in Ubuntu:
  New

Bug description:
  Issue description:
  when running dhclient on IP-over-Infiniband interface the process immediately 
fails - no packets are sent at all.
  Reproduction:
  # dhclient -v ib0
  Internet Systems Consortium DHCP Client 4.2.4
  Copyright 2004-2012 Internet Systems Consortium.
  All rights reserved.
  For info, please visit https://www.isc.org/software/dhcp/

  Listening on LPF/ib0/
  Sending on   LPF/ib0/
  Sending on   Socket/fallback
  xid: warning: no netdev with useable HWADDR found for seed's uniqueness 
enforcement
  xid: rand init seed (0xd42bc663) built using gethostid
  stgraber: host-name
  dhcp-client-identifier must be specified for InfiniBand

  Additional Host info:
  # lsb_release -rd
  Description: Ubuntu Trusty Tahr (development branch)
  Release: 14.04
  # apt-cache policy isc-dhcp-client
  isc-dhcp-client:
Installed: 4.2.4-7ubuntu8
Candidate: 4.2.4-7ubuntu8
Version table:
   *** 4.2.4-7ubuntu8 0
  500 http://il.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1292055/+subscriptions

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

[Touch-packages] [Bug 1317437] Re: wubi kernel option "rw" required

[Rafael David Tinoco]

** Changed in: initramfs-tools (Ubuntu)
 Assignee: (unassigned) => Rafael David Tinoco (inaddy)

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

Title:
  wubi kernel option "rw" required

Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  We have installed ubuntu beta-64amd.iso (trusty tahr) as wubi on a
  windows 8.1.

  Since upgrade
   * busybox-initramfs from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
   * busybox-static from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
  the wubi installation won't work / start and ends with the massage:
  "Bei der Ueberpruefung des Laufwerkes auf / wurden schwere Fehler gefunden"

  "key: »I« zum Ignorieren, »S« ueberspringt das Einhaengen, »M« fuer
  manuelle Wiederherstellung"

  Changing the sequence of "/boot/grub/grub.cfg" inside the line:
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk ro   quiet splash $vt_handoff
  into
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk rw  quiet splash $vt_handoff
  (kernel option »ro« into »rw«) lets start the wubi installation without any 
restrictions.

  For further system-information see -> annex

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: lupin-support 0.55
  ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  Date: Thu May  8 10:53:53 2014
  ProcEnviron:
   LANGUAGE=de_DE
   TERM=xterm
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: lupin
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1317437/+subscriptions

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

[Touch-packages] [Bug 1317437] Re: wubi kernel option "rw" required

[Rafael David Tinoco]

This bug is being reported to happen also after a clonezilla based
installation for Trusty.

"""
The issue with /tmp will timeout and continue to boot, / will hand the boot up 
unless there is some user intervention to continue the boot. The work around I 
mentioned came from a suggestion in the ‘askubuntu’ link listed below. What we 
did was modify /etc/grub.d/10_linux changing ‘ro’ to ‘rw’, but with the thought 
that this is just a temp patch with possible (unknown) downstream impact. 

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1308152 
(can't boot from kernel 3.13.0.24 after upgrade to ubuntu 14.04 LTS but able to 
boot with kernel 3.11.0.20). 
http://askubuntu.com/questions/453411/ubuntu-14-04-not-booting-after-error-message-tmp-could-not-be-mounted
 

Rebooting the system to get to the boot menu, I used the 'e' option to modify 
the parameters changing 'ro' to 'rw' as suggested in the 2nd thread. This 
temporary change allowed the system to boot. 
"""

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

Title:
  wubi kernel option "rw" required

Status in initramfs-tools package in Ubuntu:
  In Progress

Bug description:
  We have installed ubuntu beta-64amd.iso (trusty tahr) as wubi on a
  windows 8.1.

  Since upgrade
   * busybox-initramfs from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
   * busybox-static from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
  the wubi installation won't work / start and ends with the massage:
  "Bei der Ueberpruefung des Laufwerkes auf / wurden schwere Fehler gefunden"

  "key: »I« zum Ignorieren, »S« ueberspringt das Einhaengen, »M« fuer
  manuelle Wiederherstellung"

  Changing the sequence of "/boot/grub/grub.cfg" inside the line:
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk ro   quiet splash $vt_handoff
  into
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk rw  quiet splash $vt_handoff
  (kernel option »ro« into »rw«) lets start the wubi installation without any 
restrictions.

  For further system-information see -> annex

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: lupin-support 0.55
  ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  Date: Thu May  8 10:53:53 2014
  ProcEnviron:
   LANGUAGE=de_DE
   TERM=xterm
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: lupin
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1317437/+subscriptions

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

[Touch-packages] [Bug 1317437] Re: wubi kernel option "rw" required

[Rafael David Tinoco]

I believe that this comment:

https://code.launchpad.net/~noorez-kassam/ubuntu/utopic/initramfs-tools
/fix-for-1317437/+merge/219927/comments/592175

""""
This is the way I understand this is and my testing is shown below:

Mounting and creating the loop device in the same step with the readonly
option, makes it impossible to remount the loop device later as read-
write.

By creating the loop device separately (which defaults to read-write
capable unless the -r option is supplied), the loop device can then be
mounted readonly, and later remounted as read-write.

This change is needed since release 14.04, which - for unknown reasons -
now won't let the loop device be remounted read-write (perhaps it's
passing the -r option to losetup internally and it's losetup which has
started enforcing this?).

The end result is that Wubi installs cannot boot, because the remount
read-write fails.

My tests confirm this:
Setup:
1. Create a file, format as ext4.
bcbc@neptune:~$ dd if=/dev/zero of=new.disk bs=1MB count=100
bcbc@neptune:~$ mkfs.ext4 -F new.disk

2. Old method, mount and create loop device as read only, then try to remount
bcbc@neptune:~$ sudo mount -r -t ext4 -o loop new.disk /mnt
bcbc@neptune:~$ sudo touch /mnt/test
touch: impossible de faire un touch «/mnt/test»: Système de fichiers accessible 
en lecture seulement
bcbc@neptune:~$ sudo mount -o remount,rw /mnt
mount : impossible de remonter périphérique bloc /dev/loop0 en 
lecture/écriture, est protégé en écriture
bcbc@neptune:~$ sudo umount /mnt

3. New method, first create loop device (defaults to read-write capable), then 
mount as read only, then try to remount read-write
bcbc@neptune:~$ sudo losetup /dev/loop0 new.disk
bcbc@neptune:~$ sudo mount -r -t ext4 /dev/loop0 /mnt
bcbc@neptune:~$ sudo touch /mnt/test
touch: impossible de faire un touch «/mnt/test»: Système de fichiers accessible 
en lecture seulement
bcbc@neptune:~$ sudo mount -o remount,rw /mnt
bcbc@neptune:~$ sudo touch /mnt/test
bcbc@neptune:~$ sudo umount /mnt
bcbc@neptune:~$ sudo losetup -d /dev/loop0

4. To confirm it's probably passing -r to losetup
bcbc@neptune:~$ sudo losetup -r /dev/loop0 new.disk
bcbc@neptune:~$ sudo mount -r -t ext4 /dev/loop0 /mnt
bcbc@neptune:~$ sudo touch /mnt/test
touch: impossible de faire un touch «/mnt/test»: Système de fichiers accessible 
en lecture seulement
bcbc@neptune:~$ sudo mount -o remount,rw /mnt
mount : impossible de remonter périphérique bloc /dev/loop0 en 
lecture/écriture, est protégé en écriture
bcbc@neptune:~$ sudo umount /mnt
bcbc@neptune:~$ sudo losetup -d /dev/loop0

Conclusion:
This fix is appropriate and required for loop mounted installs
""""

>From "bcbc" is what this bug is all about.

** Changed in: initramfs-tools (Ubuntu)
 Assignee: (unassigned) => Rafael David Tinoco (inaddy)

** Changed in: initramfs-tools (Ubuntu)
   Status: Confirmed => In Progress

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

Title:
  wubi kernel option "rw" required

Status in initramfs-tools package in Ubuntu:
  In Progress

Bug description:
  We have installed ubuntu beta-64amd.iso (trusty tahr) as wubi on a
  windows 8.1.

  Since upgrade
   * busybox-initramfs from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
   * busybox-static from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
  the wubi installation won't work / start and ends with the massage:
  "Bei der Ueberpruefung des Laufwerkes auf / wurden schwere Fehler gefunden"

  "key: »I« zum Ignorieren, »S« ueberspringt das Einhaengen, »M« fuer
  manuelle Wiederherstellung"

  Changing the sequence of "/boot/grub/grub.cfg" inside the line:
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk ro   quiet splash $vt_handoff
  into
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk rw  quiet splash $vt_handoff
  (kernel option »ro« into »rw«) lets start the wubi installation without any 
restrictions.

  For further system-information see -> annex

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: lupin-support 0.55
  ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  Date: Thu May  8 10:53:53 2014
  ProcEnviron:
   LANGUAGE=de_DE
   TERM=xterm
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: lupin
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1317437/+subscriptions

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

[Touch-packages] [Bug 1317437] Re: wubi kernel option "rw" required

[Rafael David Tinoco]

** Changed in: initramfs-tools (Ubuntu)
 Assignee: Rafael David Tinoco (inaddy) => (unassigned)

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

Title:
  wubi kernel option "rw" required

Status in initramfs-tools package in Ubuntu:
  Confirmed

Bug description:
  We have installed ubuntu beta-64amd.iso (trusty tahr) as wubi on a
  windows 8.1.

  Since upgrade
   * busybox-initramfs from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
   * busybox-static from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
  the wubi installation won't work / start and ends with the massage:
  "Bei der Ueberpruefung des Laufwerkes auf / wurden schwere Fehler gefunden"

  "key: »I« zum Ignorieren, »S« ueberspringt das Einhaengen, »M« fuer
  manuelle Wiederherstellung"

  Changing the sequence of "/boot/grub/grub.cfg" inside the line:
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk ro   quiet splash $vt_handoff
  into
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk rw  quiet splash $vt_handoff
  (kernel option »ro« into »rw«) lets start the wubi installation without any 
restrictions.

  For further system-information see -> annex

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: lupin-support 0.55
  ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  Date: Thu May  8 10:53:53 2014
  ProcEnviron:
   LANGUAGE=de_DE
   TERM=xterm
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: lupin
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1317437/+subscriptions

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

[Touch-packages] [Bug 1312419] Re: nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

[Rafael David Tinoco]

** Changed in: libnl3 (Ubuntu)
 Assignee: (unassigned) => Rafael David Tinoco (inaddy)

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

Title:
  nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

Status in libnl3 package in Ubuntu:
  Confirmed

Bug description:
  Retrieving information about configured neighbors fail 
  my application is running the following procedure:

  neigh = NULL;
  cache = rtnl_neigh_alloc_cache(sk);
  while(NULL == neigh){
  nl_cache_refill(sk, chache);
  neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
  }

  with libnl3 3.2.21-1 this loop will never end, even when adding a static arp 
entry.
  However, with libnl-3.2.24 the neighbor lookup succeed.

  additional general info:
  $ lsb_release -rd
  Description:Ubuntu 14.04 LTS
  Release:14.04
  $ uname -r
  3.13.0-24-generic
  $ apt-cache policy libnl-genl-3-200 libnl-route-3-200
  libnl-genl-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status
  libnl-route-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status

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

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

[Touch-packages] [Bug 1312419] Re: nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

[Rafael David Tinoco]

Kamal,

As we talked about, I'm making the following PPA available:

https://launchpad.net/~inaddy/+archive/ubuntu/lp1312419

It contains Trusty version + commit:

>From 3700cc1ad3a3b507848deb401b9d0f41ff7010bb Mon Sep 17 00:00:00 2001
From: Thomas Graf 
Date: Fri, 1 Feb 2013 10:41:45 +0100
Subject: [PATCH] neigh: Remove check for AF_UNSPEC in rtnl_neigh_get()

Please test this PPA and provide feedback if it fixes the problem. I'll
suggest SRU as soon as I get confirmation.

Thank you

Best Regards

Rafael

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

Title:
  nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

Status in libnl3 package in Ubuntu:
  Confirmed

Bug description:
  Retrieving information about configured neighbors fail 
  my application is running the following procedure:

  neigh = NULL;
  cache = rtnl_neigh_alloc_cache(sk);
  while(NULL == neigh){
  nl_cache_refill(sk, chache);
  neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
  }

  with libnl3 3.2.21-1 this loop will never end, even when adding a static arp 
entry.
  However, with libnl-3.2.24 the neighbor lookup succeed.

  additional general info:
  $ lsb_release -rd
  Description:Ubuntu 14.04 LTS
  Release:14.04
  $ uname -r
  3.13.0-24-generic
  $ apt-cache policy libnl-genl-3-200 libnl-route-3-200
  libnl-genl-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status
  libnl-route-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status

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

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

[Touch-packages] [Bug 1312419] Re: nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

[Rafael David Tinoco]

It looks like that Trusty version also suffers from:

root@dixie:~# virsh start maas
error: Failed to start domain maas
error: internal error: missing IFLA_VF_INFO in netlink response

Whenever we try to start a VFIO (or KVM passthrough) SR-IOV based
machine.

I don't think this happens under Utopic (beind used before in the same
machine). Fix might be in between 3.2.21 and 3.2.24. Checking...

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

Title:
  nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

Status in libnl3 package in Ubuntu:
  In Progress

Bug description:
  Retrieving information about configured neighbors fail 
  my application is running the following procedure:

  neigh = NULL;
  cache = rtnl_neigh_alloc_cache(sk);
  while(NULL == neigh){
  nl_cache_refill(sk, chache);
  neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
  }

  with libnl3 3.2.21-1 this loop will never end, even when adding a static arp 
entry.
  However, with libnl-3.2.24 the neighbor lookup succeed.

  additional general info:
  $ lsb_release -rd
  Description:Ubuntu 14.04 LTS
  Release:14.04
  $ uname -r
  3.13.0-24-generic
  $ apt-cache policy libnl-genl-3-200 libnl-route-3-200
  libnl-genl-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status
  libnl-route-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status

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

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

[Touch-packages] [Bug 1312419] Re: nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

[Rafael David Tinoco]

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

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

Title:
  nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

Status in libnl3 package in Ubuntu:
  In Progress

Bug description:
  Retrieving information about configured neighbors fail 
  my application is running the following procedure:

  neigh = NULL;
  cache = rtnl_neigh_alloc_cache(sk);
  while(NULL == neigh){
  nl_cache_refill(sk, chache);
  neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
  }

  with libnl3 3.2.21-1 this loop will never end, even when adding a static arp 
entry.
  However, with libnl-3.2.24 the neighbor lookup succeed.

  additional general info:
  $ lsb_release -rd
  Description:Ubuntu 14.04 LTS
  Release:14.04
  $ uname -r
  3.13.0-24-generic
  $ apt-cache policy libnl-genl-3-200 libnl-route-3-200
  libnl-genl-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status
  libnl-route-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status

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

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

Re: [Touch-packages] [Bug 1312419] Re: nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

[Rafael David Tinoco]

Awesome. Thank you Talat. This was actually a simple example I was giving
to Kamal, explaining to him how the SRU process worked and giving him a
real example on how to provide a debdiff and create a PPA. So, I really did
not expect the fix to be "good" but to give him so clue how things worked.

It is good that you are catching up with bugs. I'll compile the testcase,
backport the commits you are mentioning and provide you a PPA to test, okay
? Please expect this to take sometime (a week) because of my Ubuntu
Advantage workload.

Thank you !!

Cheers

Rafael

On Sun, Nov 22, 2015 at 11:41 AM, Talat Batheesh <1312...@bugs.launchpad.net
> wrote:

> Hi Rafael,
>
>  Unfortunately, after installing the PPA, the udaddy test still fail on
> Ubuntu 14.04.3 LTS.
> Tested with ConnectX3-pro.
>
>
> root # udaddy -b 1.1.1.1
> udaddy: starting server
> receiving data transfers
>
> ^C
> root# uname -r
> 3.13.0-68-generic
> root# cat /etc/issue
> Ubuntu 14.04.3 LTS \n \l
>
>
> Client side
> # udaddy  -s 1.1.1.1 -b 1.1.1.2
> udaddy: starting client
> udaddy: connecting
> udaddy: failure creating address handle
> test complete
> return status -1
>
> As a reference, may we need to add the following patches that mentioned in
> Bug #1364442
> “
> Ubuntu is missing some code to make this work. The issue is that libmlx4
> and libibverbs is missing the code for RoCE UD neighboor code.
> Here I found the series of patches needed:
> For libmlx4:
> [PATCH libmlx4 V4 0/2] Add RoCE IP based addressing support for UD QPs
> [PATCH libmlx4 V4 1/2] Add ibv_query_port caching support
> [PATCH libmlx4 V4 2/2] Add RoCE IP based addressing support for UD QPs
> For libibverbs:
> [PATCH libibverbs V5 0/2] Use neighbour lookup for RoCE UD QPs Eth L2
> resolution
> [PATCH libibverbs V5 1/2] Add ibv_port_cap_flags
> [PATCH libibverbs V5 2/2] Use neighbour lookup for RoCE UD QPs Eth L2
> resolution
> ”
>
> Yours,
> Talat
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1312419
>
> Title:
>   nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache
>
> Status in libnl3 package in Ubuntu:
>   In Progress
>
> Bug description:
>   Retrieving information about configured neighbors fail
>   my application is running the following procedure:
>
>   neigh = NULL;
>   cache = rtnl_neigh_alloc_cache(sk);
>   while(NULL == neigh){
>   nl_cache_refill(sk, chache);
>   neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
>   }
>
>   with libnl3 3.2.21-1 this loop will never end, even when adding a static
> arp entry.
>   However, with libnl-3.2.24 the neighbor lookup succeed.
>
>   additional general info:
>   $ lsb_release -rd
>   Description:Ubuntu 14.04 LTS
>   Release:14.04
>   $ uname -r
>   3.13.0-24-generic
>   $ apt-cache policy libnl-genl-3-200 libnl-route-3-200
>   libnl-genl-3-200:
> Installed: 3.2.21-1
> Candidate: 3.2.21-1
> Version table:
>*** 3.2.21-1 0
>   500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64
> Packages
>   100 /var/lib/dpkg/status
>   libnl-route-3-200:
> Installed: 3.2.21-1
> Candidate: 3.2.21-1
> Version table:
>    *** 3.2.21-1 0
>   500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64
> Packages
>   100 /var/lib/dpkg/status
>
> To manage notifications about this bug go to:
>
> https://bugs.launchpad.net/ubuntu/+source/libnl3/+bug/1312419/+subscriptions
>


-- 
--
Rafael David Tinoco
Canonical - Kernel & Userland Sustaining Engineer
Server Tech Lead for SEG - Manager: Brooks Warner
-
# Email: rafael.tin...@canonical.com (GPG: 2B15B499)
# Canonical: +44.20.7537.2822
# Extension: 7684
# Phone: +55.11.9.6777.2727 (Americas/Sao_Paulo)
# LP: ~inaddy | IRC: tinoco

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

Title:
  nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

Status in libnl3 package in Ubuntu:
  In Progress

Bug description:
  Retrieving information about configured neighbors fail 
  my application is running the following procedure:

  neigh = NULL;
  cache = rtnl_neigh_alloc_cache(sk);
  while(NULL == neigh){
  nl_cache_refill(sk, chache);
  neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
  }

  with libnl3 3.2.21-1 this loop will never end, even when adding a static arp 
entry.
  However, with libnl-3.2.24 the neighbor lookup succeed.

  additional general info:
  $ lsb_release -rd
  Description:Ubuntu 14.04 LTS
  Release:14.04
  $ uname -r
  3.13.0-24-generic
  $ apt-cache policy l

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

The PPA for tests is:

https://launchpad.net/~inaddy/+archive/ubuntu/lp1529815

$ sudo add-apt-repository ppa:inaddy/lp1529815
$ sudo apt-get update && sudo apt-get dist-upgrade

Using a versioning schema that will be superseded by the final SRU.

PS: I'm also attaching the Trusty debdiff if this PPA proves to work.

Thank you

Rafael

** Patch added: "trusty_isc-dhcp_4.2.4-7ubuntu12.5.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4568495/+files/trusty_isc-dhcp_4.2.4-7ubuntu12.5.debdiff

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Changed in: isc-dhcp (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: isc-dhcp (Ubuntu Wily)
   Status: New => In Progress

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Attachment added: "dhclient.conf"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4568545/+files/dhclient.conf

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Patch removed: "trusty_isc-dhcp_4.2.4-7ubuntu12.5.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4568495/+files/trusty_isc-dhcp_4.2.4-7ubuntu12.5.debdiff

** Patch added: "trusty_isc-dhcp_4.2.4-7ubuntu12.5.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4568523/+files/trusty_isc-dhcp_4.2.4-7ubuntu12.5.debdiff

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Attachment added: "dhcpd.conf"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4568546/+files/dhcpd.conf

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

Last test I did was to see if IB DHCP would get the BROADCAST flag on IB
interfaces. It did. Now, I removed:

ip->client->config->bootp_broadcast_always = 1;

from setup_ib_interface (when preparing for DHCP REQUEST), so I could
check if the option:

bootp-broadcast-always

from the config file (added by this patch also) to check if it makes a
difference.



## without bootp-broadcast-always

tcpdump: listening on ib0, link-type LINUX_SLL (Linux cooked), capture size 
65535 bytes
13:34:47.376362 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 
300, htype 32, hlen 0, xid 0x5f7f9774, Flags [none] (0x)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 5: "dixie"
Parameter-Request Option 55, length 13:
  Subnet-Mask, BR, Time-Zone, Default-Gateway
  Domain-Name, Domain-Name-Server, Option 119, Hostname
  Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
  NTP
Client-ID Option 61, length 17: hardware-type 56, 
30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
END Option 255, length 0
PAD Option 0, length 0, occurs 15

## with bootp-broadcast-always

13:51:10.735292 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 
300, htype 32, hlen 0, xid 0x5bbf492d, Flags [Broadcast] (0x8000)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 5: "dixie"
Parameter-Request Option 55, length 13:
  Subnet-Mask, BR, Time-Zone, Default-Gateway
  Domain-Name, Domain-Name-Server, Option 119, Hostname
  Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
  NTP
Client-ID Option 61, length 17: hardware-type 56, 
30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
END Option 255, length 0
PAD Option 0, length 0, occurs 15



So the following statement in dhclient.conf

interface "ib0" {
send dhcp-client-identifier = "80:00:00:48:FE:80";
bootp-broadcast-always;
}

Is working good also.

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Changed in: isc-dhcp (Ubuntu)
   Status: Confirmed => In Progress

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1401141] Re: DHCP server does not work for IPoIB (Infiniband)

[Rafael David Tinoco]

I think during the fix of:

https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815

I accidentally missed the following:

> + /* Set the broadcast flag */
> + ip->client->config->bootp_broadcast_always = 1;
> +

in find_subnet.

This comes from: dhcp-4.2.5-lpf-ib.patch in tag "dhcp-4.2.5-30.fc20" from 
pkgs.fedoraproject.org/git/rpms/dhcp.git (since all IB patches are coming
from fedora project). 

I'll review this and provide a PPA, asking for feedback.

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

Title:
  DHCP server does not work for IPoIB (Infiniband)

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  Fix Released
Status in isc-dhcp source package in Utopic:
  Fix Released
Status in isc-dhcp source package in Vivid:
  Fix Released

Bug description:
  [Impact]

   * DHCP for InfiniBand IPoIB does not work currently.
   * After providing missing GPXE patch it had problems (by Mellanox tests).
   * IPoIB patches from Fedora project (out-of-upstream-tree) were outdated.

  [Test Case]

   * To have IPoIB devices (2 if possible)
   * Try to acquire IP using either DHCPv4 or DHCPv6

  [Regression Potential]

   * DHCP for InfiniBand was not working
   * Based on already implemented code (Fedora)
   * Mellanox has tested it

  [Other Info]

  Original BUG description:

  Release:  Ubuntu 14.04.1 LTS
  Version:  4.2.4-7ubuntu12

  The current DHCP package in Ubuntu can't handle IPoIB clients.  For
  IB, Mellanox uses IPoIB, which is “Eth emulator” for the control path.
  DHCP is not working in this mode without a patch for DHCP server.

  ISC-DHCP-SERVER Missing GPXE patch.

  After applying GPXE patch only we faced the following problems:

  After apply

  1.

  dhcp ipoib, does not write in the log on which interface the dhcp work
  upon when starting the dhcp server using “/etc/init.d/isc-dhcp-server
  start” we don’t see the line that tells on which interfaces the dhcpd
  is listening on the /var/log/syslog when running it with “dhcpd –d”
  command – we do see it.

  2.

  dhcp ipoib ipv6, it did not provide ip6 when we start 2 ib interfaces
  in a parallel using the following setup:

  HOST_A: 
  acting as a dhcp server, listening on one of its 
  ipoib (ib0) interfaces.

  HOST_B: 
  running dhcp clients on two ipoib interfaces (ib1, ib2) ib1 
  and ib2 are two ports onf the same HCA both interfaces are
  configured in /etc/interfaces such as:

  auto ib1
  iface ib1 inet6 dhcp
 both 
interfaces are configured in /etc/dhcp/dhclient.conf with their 
dhcp-client-identifier Ib0@HOST_A, Ib1@HOST_B and Ib2@HOST_B are connected to 
an infiniband switch.

  We are running on the client (HOST_B) the following:

  $ ifup ib1
  -> ib1 get configured as expected

  but then when we run on the other interface:
  $ ifup ib2
  -> ib2 get configured, but ib1 is losing its configuration

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

## RHEL broadcast flag set during DHCP DISCOVER: 
(this will tell DHCP server that DHCP response should come as a broadcast BOOT 
REPLY)

12:29:42.653772 IP (tos 0x0, ttl 128, id 16963, offset 0, flags [none], proto 
UDP (17), length 341)
0.0.0.0.68 > 255.255.255.255.67: [no cksum] BOOTP/DHCP, Request, length 
313, htype 32, hlen 0, xid 0x1f49749f, secs 1024, Flags [Broadcast] (0x8000)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 9: "l-supp-22"
Vendor-Class Option 60, length 8: "MSFT 5.0"
Parameter-Request Option 55, length 13:
  Subnet-Mask, Domain-Name, Default-Gateway, Domain-Name-Server
  Netbios-Name-Server, Netbios-Node, Netbios-Scope, Router-Discovery
  Static-Route, Classless-Static-Route, 
Classless-Static-Route-Microsoft, Option 252
  Vendor-Option
Client-ID Option 61, length 20: hardware-type 255, 
00:00:00:00:00:02:00:00:02:c9:00:00:02:c9:03:00:fc:78:32
END Option 255, length 0
TTL Option 23, length 0
PAD Option 0, length 0, occurs 6
T254 Option 254, length 128: [|rfc1048 128]

## UBUNTU broadcast flag not set during DHCP DISCOVER

06:42:18.949401 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 
300, htype 32, hlen 0, xid 0x52bc6268, secs 17, Flags [none] (0
x)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Lease-Time Option 51, length 4: 86400
Parameter-Request Option 55, length 7:
  Subnet-Mask, BR, Time-Zone, Default-Gateway
  Domain-Name, Domain-Name-Server, Hostname
Client-ID Option 61, length 20: hardware-type 255, 
00:00:00:00:00:02:00:00:02:c9:00:f4:52:14:03:00:33:d1:91
END Option 255, length 0
PAD Option 0, length 0, occurs 19

** Changed in: isc-dhcp (Ubuntu)
 Assignee: (unassigned) => Rafael David Tinoco (inaddy)

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

RFC 4390 from 2006:

https://tools.ietf.org/html/rfc4390
(Dynamic Host Configuration Protocol (DHCP) over InfiniBand) also stipulates:

As described above, the link-layer address is unavailable to the DHCP
   server because the link-layer address is larger than the "chaddr"
   field length.  As a result, the server cannot unicast its reply to
   the client.  Therefore, a DHCP client MUST request that the server
   send a broadcast reply by setting the BROADCAST flag when IPoIB
   Address Resolution Protocol (ARP) is not possible, i.e., in
   situations where the client does not know its IP address.

   [RFC1542] discourages the use of a broadcast reply.  But in the case
   of IPoIB, this is a necessity because the server does not receive the
   link-layer address.

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

I think during the fix of:

https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141

I accidentally missed the following:

> + /* Set the broadcast flag */
> + ip->client->config->bootp_broadcast_always = 1;
> +

in find_subnet.

This comes from: dhcp-4.2.5-lpf-ib.patch in tag "dhcp-4.2.5-30.fc20" from
pkgs.fedoraproject.org/git/rpms/dhcp.git (since all IB patches are coming
from fedora project).

I'll review this and provide a PPA, asking for feedback.

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

Talat,

I was able to set the Broadcast flag in a DHCP negotiation when using IB
interface.

Trusty patch is possibly ready.

TCPDUMP from the OFFER and ACK:

$ sudo tcpdump -i ib0 -nn -vvv -S
tcpdump: listening on ib0, link-type LINUX_SLL (Linux cooked), capture size 
65535 bytes

04:38:01.051682 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 
300, htype 32, hlen 0, xid 0xb48b8735, Flags [Broadcast] (0x8000)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 5: "dixie"
Parameter-Request Option 55, length 13:
  Subnet-Mask, BR, Time-Zone, Default-Gateway
  Domain-Name, Domain-Name-Server, Option 119, Hostname
  Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
  NTP
Client-ID Option 61, length 17: hardware-type 56, 
30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
END Option 255, length 0
PAD Option 0, length 0, occurs 15


04:38:01.051936 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 
300, htype 32, hlen 0, xid 0xb48b8735, Flags [Broadcast] (0x8000)
  Your-IP 172.16.0.19
  Server-IP 172.16.0.1
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.16.0.1
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 172.16.0.255
Domain-Name Option 15, length 7: "myib.cu"
END Option 255, length 0
PAD Option 0, length 0, occurs 23


04:38:01.052215 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 
300, htype 32, hlen 0, xid 0xb48b8735, Flags [Broadcast] (0x8000)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Server-ID Option 54, length 4: 172.16.0.1
Requested-IP Option 50, length 4: 172.16.0.19
Hostname Option 12, length 5: "dixie"
Parameter-Request Option 55, length 13:
  Subnet-Mask, BR, Time-Zone, Default-Gateway
  Domain-Name, Domain-Name-Server, Option 119, Hostname
  Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
  NTP
Client-ID Option 61, length 17: hardware-type 56, 
30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
END Option 255, length 0
PAD Option 0, length 0, occurs 3


04:38:01.052342 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 
300, htype 32, hlen 0, xid 0xb48b8735, Flags [Broadcast] (0x8000)
  Your-IP 172.16.0.19
  Server-IP 172.16.0.1
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.16.0.1
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 172.16.0.255
Domain-Name Option 15, length 7: "myib.cu"
END Option 255, length 0
PAD Option 0, length 0, occurs 23


I'll review this tomorrow and release the PPA for you to test.

I have also to review isc-dhcp IB support for Vivid/Wily/Xenial.

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client   

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

As David stated,

Per RFC 1541:

https://tools.ietf.org/html/rfc1541

"DHCP uses the 'flags' field [21].  The leftmost bit is defined as the
BROADCAST (B) flag"

Taking us to RFC 1542:

https://tools.ietf.org/html/rfc1542

3.1 Client use of the 'flags' field

3.1.1 The BROADCAST flag

   Normally, BOOTP servers and relay agents attempt to deliver BOOTREPLY
   messages directly to a client using unicast delivery.  The IP
   destination address (in the IP header) is set to the BOOTP 'yiaddr'
   address and the link-layer destination address is set to the BOOTP
   'chaddr' address.  Unfortunately, some client implementations are
   unable to receive such unicast IP datagrams until they know their own
   IP address (thus we have a "chicken and egg" issue).  Often, however,
   they can receive broadcast IP datagrams (those with a valid IP
   broadcast address as the IP destination and the link-layer broadcast
   address as the link-layer destination).

   If a client falls into this category, it SHOULD set (to 1) the
   newly-defined BROADCAST flag in the 'flags' field of BOOTREPLY
   messages it generates.  This will provide a hint to BOOTP servers and
   relay agents that they should attempt to broadcast their BOOTREPLY
   messages to the client.

   If a client does not have this limitation (i.e., it is perfectly able
   to receive unicast BOOTREPLY messages), it SHOULD NOT set the
   BROADCAST flag (i.e., it SHOULD clear the BROADCAST flag to 0).

  DISCUSSION:

 This addition to the protocol is a workaround for old host
 implementations.  Such implementations SHOULD be modified so
 that they may receive unicast BOOTREPLY messages, thus making
 use of this workaround unnecessary.  In general, the use of
 this mechanism is discouraged.

I'll check DHCP IB implementation from my previous SRU from:

https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141

For this BROADCAST flag distinction on IB DHCP requests.

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

Continuation of RFC 1541 is RFC 2131:

https://tools.ietf.org/html/rfc2131 (adding DHCP INFORM msg type)

RFC 4390 from 2006:

https://tools.ietf.org/html/rfc4390
(Dynamic Host Configuration Protocol (DHCP) over InfiniBand) stipulates:

2.2.  Use of the BROADCAST flag

   A DHCP client on IPoIB MUST set the BROADCAST flag in DHCPDISCOVER
   and DHCPREQUEST messages (and set "ciaddr" to zero) to ensure that
   the server (or the relay agent) broadcasts its reply to the client.

   Note: As described in [RFC2131], "ciaddr" MUST be filled in with the
 client's IP address during BOUND, RENEWING or REBINDING states;
 therefore, the BROADCAST flag MUST NOT be set.  In these cases,
 the DHCP server unicasts DHCPACK message to the address in
 "ciaddr".  The link address will be resolved by ARP.

Meaning that, during discovery, specifically for InfiniBand, the BROADCAST
flag must be turned on (MUST is used in RFC).

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

Okay, I just provisioned 2 servers (ConnectX-3 & ConnectX-4) so I could
reproduce this issue and work on it. I'll try to start reproducing the
issue now.

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  Confirmed

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1317437] Re: wubi kernel option "rw" required

[Rafael David Tinoco]

** Changed in: initramfs-tools (Ubuntu)
   Status: In Progress => Incomplete

** Changed in: initramfs-tools (Ubuntu)
 Assignee: Rafael David Tinoco (inaddy) => (unassigned)

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

Title:
  wubi kernel option "rw" required

Status in initramfs-tools package in Ubuntu:
  Incomplete

Bug description:
  We have installed ubuntu beta-64amd.iso (trusty tahr) as wubi on a
  windows 8.1.

  Since upgrade
   * busybox-initramfs from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
   * busybox-static from "1.20.0-8.1ubuntu1" to "1.21.0-1ubuntu1"
  the wubi installation won't work / start and ends with the massage:
  "Bei der Ueberpruefung des Laufwerkes auf / wurden schwere Fehler gefunden"

  "key: »I« zum Ignorieren, »S« ueberspringt das Einhaengen, »M« fuer
  manuelle Wiederherstellung"

  Changing the sequence of "/boot/grub/grub.cfg" inside the line:
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk ro   quiet splash $vt_handoff
  into
   * linux  /boot/vmlinuz-3.13.0-24-generic root=UUID=B65449E05449A449 
loop=/ubuntu/disks/root.disk rw  quiet splash $vt_handoff
  (kernel option »ro« into »rw«) lets start the wubi installation without any 
restrictions.

  For further system-information see -> annex

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: lupin-support 0.55
  ProcVersionSignature: Ubuntu 3.13.0-24.47-generic 3.13.9
  Uname: Linux 3.13.0-24-generic x86_64
  ApportVersion: 2.14.1-0ubuntu3
  Architecture: amd64
  Date: Thu May  8 10:53:53 2014
  ProcEnviron:
   LANGUAGE=de_DE
   TERM=xterm
   PATH=(custom, no user)
   LANG=de_DE.UTF-8
   SHELL=/bin/bash
  SourcePackage: lupin
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1317437/+subscriptions

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

[Touch-packages] [Bug 1373070] Re: full fix for disconnected path (paths)

[Rafael David Tinoco]

Though,

For comments:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1373070/comments/7

If you remove /dev/log rwx from /etc/apparmor.d/usr.sbin.rsyslog :

Using kernel Ubuntu-3.13.x DOES NOT show any DENIALS (Ubuntu-3.16,
Ubuntu-3.19 and Ubuntu-4.2 HWE kernels shows).

Using upstream kernels 3.13, 3.16, 3.19 and 4.2 DOES NOT show any
DENIALS.

I wonder why only Ubuntu >= 3.16 kernels show the denials.

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

Title:
  full fix for disconnected path (paths)

Status in cups package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Triaged
Status in rsyslog package in Ubuntu:
  New

Bug description:
  With the apparmor 3 RC1 upload, there is an incomplete bug fix for
  disconnected paths. This bug is to track that work.

  This denial may be related:
  Sep 23 10:10:50 localhost kernel: [40262.517799] audit: type=1400 
audit(1411485050.722:2862): apparmor="DENIED" operation="sendmsg" info="Failed 
name lookup - disconnected path" error=-13 profile="/usr/sbin/rsyslogd" 
name="dev/log" pid=7011 comm="logger" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=0

  This is related to bug 1375410

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

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

[Touch-packages] [Bug 1373070] Re: full fix for disconnected path (paths)

[Rafael David Tinoco]

Yep, you're right. It was getting /dev/log from abstractions/base for
write only. My bad.

Though,

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1373070/comments/6

Shows same issue.

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

Title:
  full fix for disconnected path (paths)

Status in cups package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Triaged
Status in rsyslog package in Ubuntu:
  New

Bug description:
  With the apparmor 3 RC1 upload, there is an incomplete bug fix for
  disconnected paths. This bug is to track that work.

  This denial may be related:
  Sep 23 10:10:50 localhost kernel: [40262.517799] audit: type=1400 
audit(1411485050.722:2862): apparmor="DENIED" operation="sendmsg" info="Failed 
name lookup - disconnected path" error=-13 profile="/usr/sbin/rsyslogd" 
name="dev/log" pid=7011 comm="logger" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=0

  This is related to bug 1375410

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

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

[Touch-packages] [Bug 1373070] Re: full fix for disconnected path (paths)

[Rafael David Tinoco]

I am able to reproduce this just by having apparmor.d profile
usr.sbin.rsyslogd removed from disable/ directory.

[  674.165128] audit: type=1400 audit(1456491880.616:134): apparmor="DENIED" 
operation="sendmsg" profile="/usr/sbin/rsyslogd" name="/dev/log" pid=3639 
comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[  674.165178] audit: type=1400 audit(1456491880.616:135): apparmor="DENIED" 
operation="sendmsg" profile="/usr/sbin/rsyslogd" name="/dev/log" pid=3639 
comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

OR

[  522.429097] audit: type=1400 audit(1456491728.880:113): apparmor="DENIED" 
operation="sendmsg" profile="/usr/sbin/rsyslogd" name="/dev/log" pid=3184 
comm="sshd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
[  527.268883] audit: type=1400 audit(1456491733.720:114): apparmor="DENIED" 
operation="sendmsg" profile="/usr/sbin/rsyslogd" name="/dev/log" pid=3239 
comm="sshd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0

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

Title:
  full fix for disconnected path (paths)

Status in cups package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Triaged
Status in rsyslog package in Ubuntu:
  New

Bug description:
  With the apparmor 3 RC1 upload, there is an incomplete bug fix for
  disconnected paths. This bug is to track that work.

  This denial may be related:
  Sep 23 10:10:50 localhost kernel: [40262.517799] audit: type=1400 
audit(1411485050.722:2862): apparmor="DENIED" operation="sendmsg" info="Failed 
name lookup - disconnected path" error=-13 profile="/usr/sbin/rsyslogd" 
name="dev/log" pid=7011 comm="logger" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=0

  This is related to bug 1375410

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

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

[Touch-packages] [Bug 1373070] Re: full fix for disconnected path (paths)

[Rafael David Tinoco]

Pavel, Déziel,

Im reproducing the same issue with dnsmasq + openstack + neutron:

Feb 16 18:35:01 juju-inaddy-machine-12 kernel: [ 4357.680900] audit:
type=1400 audit(1455647701.796:121): apparmor="DENIED"
operation="sendmsg" info="Failed name lookup - disconnected path"
error=-13 profile="/usr/sbin/dnsmasq" name="dev/log" pid=15176
comm="dnsmasq" requested_mask="w" denied_mask="w" fsuid=65534 ouid=0

AND when using :

/usr/sbin/dnsmasq flags=(attach_disconnected) {

in usr.sbin.dnsmasq profile, I'm mitigating the problem (just as the
cups patch).

I'll try reproducing using rsyslog so I can have a simple reproducer in
order to bisect kernel 3.13 -> 3.19 and check what caused apparmor's
regression (likely related to apparmor's filesystem labeling mechanism).

Thank you

-inaddy

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

Title:
  full fix for disconnected path (paths)

Status in cups package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Triaged
Status in rsyslog package in Ubuntu:
  New

Bug description:
  With the apparmor 3 RC1 upload, there is an incomplete bug fix for
  disconnected paths. This bug is to track that work.

  This denial may be related:
  Sep 23 10:10:50 localhost kernel: [40262.517799] audit: type=1400 
audit(1411485050.722:2862): apparmor="DENIED" operation="sendmsg" info="Failed 
name lookup - disconnected path" error=-13 profile="/usr/sbin/rsyslogd" 
name="dev/log" pid=7011 comm="logger" requested_mask="r" denied_mask="r" 
fsuid=0 ouid=0

  This is related to bug 1375410

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

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

[Touch-packages] [Bug 1373070] Re: full fix for disconnected path (paths)

[Rafael David Tinoco]

Okay, so, I had more time to dig a bit into this and, after some
analysis, I got:

Errors being reproduced:

[1668392.078137] audit: type=1400 audit(1459311786.129:1375455):
apparmor="DENIED" operation="sendmsg" info="Failed name lookup -
disconnected path" error=-13 profile="/usr/sbin/dnsmasq" name="dev/log"
pid=15735 comm="dnsmasq" requested_mask="w" denied_mask="w" fsuid=0
ouid=0

And apparmor dnsmasq profile:

#/usr/sbin/dnsmasq flags=(attach_disconnected) {
#/usr/sbin/dnsmasq flags=(complain) {
/usr/sbin/dnsmasq {

Without any flags.

And the command causing the apparmor errors:

root 16877  0.0  0.2  66416  3648 ?S13:23   0:00 sudo
/usr/bin/neutron-rootwrap /etc/neutron/rootwrap.conf ip netns exec
qdhcp-37d013b6-f6fa-4652-8073-5e7d2c418a9d env
NEUTRON_NETWORK_ID=37d013b6-f6fa-4652-8073-5e7d2c418a9d dnsmasq --no-
hosts --no-resolv --strict-order --bind-interfaces --interface=ns-
aa95fe20-ff --except-interface=lo --pid-
file=/var/lib/neutron/dhcp/37d013b6-f6fa-4652-8073-5e7d2c418a9d/pid
--dhcp-
hostsfile=/var/lib/neutron/dhcp/37d013b6-f6fa-4652-8073-5e7d2c418a9d/host
--addn-
hosts=/var/lib/neutron/dhcp/37d013b6-f6fa-4652-8073-5e7d2c418a9d/addn_hosts
--dhcp-
optsfile=/var/lib/neutron/dhcp/37d013b6-f6fa-4652-8073-5e7d2c418a9d/opts
--dhcp-
leasefile=/var/lib/neutron/dhcp/37d013b6-f6fa-4652-8073-5e7d2c418a9d/leases
--dhcp-range=set:tag0,192.168.21.0,static,86400s --dhcp-lease-max=256
--conf-file=/etc/neutron/dnsmasq.conf --domain=openstacklocal

It is a "sudo-like" approach from openstack (rootwrap) to execute
dnsmasq in a new network namespace with different privileges.

Ubuntu kernel 3.13.X has apparmor 3 alpha 6 code: 
https://pastebin.canonical.com/152812/
Ubuntu kernel 3.16 and 3.19 has apparmor 3 rc 1 code: 
https://pastebin.canonical.com/152813/

>From apparmor I could see that the error comes from "aa_path_name"
called by either:

- path_name *
- aa_remount
- aa_bind_mount
- aa_mount_change_type
- aa_move_mount
- aa_new_mount
- aa_unmount
- aa_pivotroot

So, since the job is being restarted by neutron (or at least it is
trying to re-start it, causing the apparmor to block the access), I
created a systemtap script to monitor path_name and check for dnsmasq
trying to open "log" (allegedly /dev/log) file.

probe kernel.function("path_name").call {
funcname = execname();
if (funcname == "dnsmasq") {
filename = reverse_path_walk($path->dentry);
if (filename == "log") {
printf("(%s) %s\n", execname(), filename);
print_backtrace();
}
}
}

And got the backtrace from the denials:

(dnsmasq) log

 0x8132deb0 : path_name+0x0/0x140 [kernel]
 0x8132e413 : aa_path_perm+0xa3/0x130 [kernel]
 0x81337e26 : aa_unix_peer_perm+0x536/0x990 [kernel]
 0x8132c653 : apparmor_unix_may_send+0x73/0x150 [kernel]
 0x812eb8a6 : security_unix_may_send+0x16/0x20 [kernel]
 0x817019db : unix_dgram_connect+0x23b/0x250 [kernel]
 0x8164a987 : SYSC_connect+0xe7/0x120 [kernel]
 0x8164b68e : sys_connect+0xe/0x10 [kernel]
 0x817700cd : system_call_fastpath+0x1a/0x1f [kernel]

 When trying to check if "log" could be converted to "fullpath" by using
systemtap function:

return task_dentry_path(task_current(),
@cast(path,"path","kernel:nfs:kernel")->dentry,
@cast(path,"path","kernel:nfs:kernel")->mnt)

I saw that I could resolve path for all other files but "/dev/log":

(dnsmasq) /usr/lib/x86_64-linux-gnu/libnfnetlink.so.0.2.0
(dnsmasq) /usr/lib/x86_64-linux-gnu/libmnl.so.0.1.0
(dnsmasq) /usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache
(dnsmasq) /etc/neutron/dnsmasq.conf
(dnsmasq) /etc/neutron/dnsmasq.conf
(dnsmasq) /etc/localtime
(dnsmasq) /etc/localtime
(dnsmasq) /etc/localtime
(dnsmasq) 

Because

function task_dentry_path:string(task:long,dentry:long,vfsmnt:long)

Couldn't handle the udev (vfsmnt) path. With that, I thought apparmor
couldn't be handling udev path for different root vfsmnt (like a
different FS namespace).

Checking iproute2 ipnetns.c I saw that executing a command in a new
network namespace causes:

unshare(CLONE_NEWNS) AND
mount("", "/", "none", MS_SLAVE | MS_REC, NULL)

This second being possibly the "problem" - its intent is not to allow
mounts to propagate back to parent task - since it basically removes a
root vfsmnt from the execution taken in place, breaking apparmor (or
even dentry cache) path resolution logic. Here, the needed flag
"attach_disconnected" (present in apparmor path resolution logic) comes
in place, to allow "/" to be added in path names missing leading / due
to missing root vfsmnt from dentry cache.

To observe: 3.13 (apparmor 3 alpha 6) doesn't complain on disconnected
paths but 3.16 and beyond (rc1) does (needing the flag
"attach_disconnected").

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which 

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Tags added: sts sts-sponsor

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Infiniband users relying on DHCP can't use DHCP relay.

  [Test Case]

   * Comment #13
   * Mellanox has tested themselves. 
   * Clear way of knowing if fix worked (tcpdump).

  [Regression Potential]

   * Only related to Infiniband.
   * Infiniband support could stop working (unlikely, already tested).

  [Other Info]

  None

  [ Original Description ]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

  DHCP client is sending discover with Unicast type request for the
  offer, in this configuration of IB to ETH through a relay we need the
  type to be broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1565567] Re: segv in sudo_getgrgid

[Rafael David Tinoco]

It was brought to my attention a crash just like this one. Here is my
analsysis:

## INTRODUCTION

# From plugins/sudoers/pwutil.c:

/*
 * Get a password entry by uid and allocate space for it.
 */
struct passwd *
sudo_getpwuid(uid_t uid)
{
struct cache_item key, *item;
struct rbnode *node;
debug_decl(sudo_getpwuid, SUDOERS_DEBUG_NSS)

key.k.uid = uid;
getauthregistry(IDtouser(uid), key.registry);
if ((node = rbfind(pwcache_byuid, )) != NULL) {
item = node->data;
sudo_debug_printf(SUDO_DEBUG_DEBUG,
"%s: uid %u [%s] -> user %s [%s] (cache hit)", __func__,
(unsigned int)uid, key.registry, item->d.pw->pw_name,
item->registry);
goto done;
}

being the last frame in the debugger:

#0  0x7fa01c0a6944 in sudo_getgrgid (gid=7241) at 
/build/sudo-g3ghsu/sudo-1.8.16/plugins/sudoers/pwutil.c:462
key = {refcnt = 1275378544, registry = 
"\000V\000\000\330\f\005L\027V\000\000\000\000\000", k = {uid = 7241,
gid = 7241, name = 0x28b4cb571c49 }, d = {
pw = 0x7d9d43d0, gr = 0x7d9d43d0, grlist = 0x7d9d43d0}}
item = 0x56174c050700
node = 
sudo_debug_subsys = 0
__func__ = "sudo_getgrgid"

We can see that all local variables are accessible but an union:

/*
 * Generic cache element.
 */
struct cache_item {
unsigned int refcnt;
char registry[16];
/* key */
union {
uid_t uid;
gid_t gid;
char *name;
} k;
/* datum */
union {
struct passwd *pw;
struct group *gr;
struct group_list *grlist;
} d;
};

(gdb) print item
$35 = (struct cache_item *) 0x56174c050700

(gdb) print item->d
$36 = {pw = 0x0, gr = 0x0, grlist = 0x0}

The union pointer "d" could be either a struct passwd, a struct group or
a struct group_list (union nature).

BUT, we can see that, from sudo_getpwuid, it is being used as a struct
passwd (d.pw):

sudo_debug_printf(SUDO_DEBUG_DEBUG,
"%s: uid %u [%s] -> user %s [%s] (cache hit)", __func__,
(unsigned int)uid, key.registry, item->d.pw->pw_name,
item->registry);

Meaning that, probably, the password structure, for this user, wasn't
filled in.

I can tell that because the "node" (from the tree) seems good:

if ((node = rbfind(pwcache_byuid, )) != NULL) {
item = node->data;

(gdb) print item->k
$38 = {uid = 7241, gid = 7241, name = 0x1c49 ""}

since uid 7241 and gid 7241 seems reasonable.

But not the "item->d" union.

So we are only missing:

struct passwd *pw;

>From the node.

"struct passwd" is (from /usr/include/pwd.h):

/* The passwd structure.  */
struct passwd
{
  char *pw_name;/* Username.  */
  char *pw_passwd;  /* Password.  */
  __uid_t pw_uid;   /* User ID.  */
  __gid_t pw_gid;   /* Group ID.  */
  char *pw_gecos;   /* Real name.  */
  char *pw_dir; /* Home directory.  */
  char *pw_shell;   /* Shell program.  */
};

And tells us that it is/was an easy way for the debug message to get
username from uid.

Now, lets check when this struct should have been filled in:
item comes from "node->data", a generic redblack tree node.

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

Title:
  segv in sudo_getgrgid

Status in sudo package in Ubuntu:
  Confirmed

Bug description:
  If the user is in a group with no name (because libnss-db got removed
  and the group was defined there, for example...) then:

  the call to sudo_debug_printf in sudo_getgrgid
  (plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
  item->d.gr->gr_name (since item->d.gr is NULL).

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

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

[Touch-packages] [Bug 1565567] Re: segv in sudo_getgrgid

[Rafael David Tinoco]

Summary:

Users coming from LDAP in groups ADMIN or SUDO will experience this
problem.

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

Title:
  segv in sudo_getgrgid

Status in sudo package in Ubuntu:
  Confirmed

Bug description:
  If the user is in a group with no name (because libnss-db got removed
  and the group was defined there, for example...) then:

  the call to sudo_debug_printf in sudo_getgrgid
  (plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
  item->d.gr->gr_name (since item->d.gr is NULL).

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

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

[Touch-packages] [Bug 1387347] Re: sudo doesn't check for sudo group

[Rafael David Tinoco]

This patch caused a regression that I'm going to fully explain in case:

https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1565567

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

Title:
  sudo doesn't check for sudo group

Status in sudo package in Ubuntu:
  Fix Released

Bug description:
  In Ubuntu, sudo is built with --enable-admin-flag to create the
  ~/.sudo_as_admin_successful after being run the first time.

  At some point, to align with Debian, the group changed from "admin" to
  "sudo", so this no longer works. A recent bash upload has fixed
  printing the blurb about using sudo in the terminal, but since the
  flag file isn't being created, the blurb always gets printed.

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

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

[Touch-packages] [Bug 1565567] Re: segv in sudo_getgrgid

[Rafael David Tinoco]

(2)

Going back to backtrace we have:

mode_run -> policy_check -> sudoers_policy_main -
>create_admin_success_flag -> user_in_group (global sudo_user)

   /* Check whether the user is in the admin group. */
   if (!user_in_group(sudo_user.pw, "admin") &&
   !user_in_group(sudo_user.pw, "sudo"))
   debug_return_int(true);

and then user_in_group calls:

   if ((grlist = sudo_get_grlist(pw)) != NULL) {

if "admin" == pw->pw_gid: matched = 1, goto done.

(gdb) print sudo_user->pw->pw_gid
$5 = 7241
Not the case.

   /*
* Next check the supplementary group vector.
* It usually includes the password db group too.
*/

   for (i = 0; i < grlist->ngroups; i++) {
   if (strcasecmp(group, grlist->groups[i]) == 0) {
   matched = true;
   goto done;
   }
   }

(gdb) frame 1
#1  0x7fa01c0a7ab1 in user_in_group (pw=0x56174c050ca8, 
group=group@entry=0x7fa01c0b14c4 "admin")
at /build/sudo-g3ghsu/sudo-1.8.16/plugins/sudoers/pwutil.c:842
842 if ((grp = sudo_getgrgid(pw->pw_gid)) != NULL) {
(gdb) print grlist->ngroups
$6 = 1
(gdb) print grlist->groups[0]
$7 = 0x56174c050d7f "sudo"

This should have gone to "done" because it is "sudo".
But we are checking for "admin":

(gdb) print group
$12 = 0x7fa01c0b14c4 "admin"

In both cases it should have finished and not continued. If it
continued, it would go to “PROBLEM" (comment #6)

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

Title:
  segv in sudo_getgrgid

Status in sudo package in Ubuntu:
  Confirmed

Bug description:
  If the user is in a group with no name (because libnss-db got removed
  and the group was defined there, for example...) then:

  the call to sudo_debug_printf in sudo_getgrgid
  (plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
  item->d.gr->gr_name (since item->d.gr is NULL).

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

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

[Touch-packages] [Bug 1565567] Re: segv in sudo_getgrgid

[Rafael David Tinoco]

(3)

Unfortunately this was caused by patch:

"also_check_sudo_group.diff"

Description: also check the sudo group to create the admin flag file
Author: Marc Deslauriers 
Bug-Ubuntu: https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1387347
Updated: 2016-03-30

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

Title:
  segv in sudo_getgrgid

Status in sudo package in Ubuntu:
  Confirmed

Bug description:
  If the user is in a group with no name (because libnss-db got removed
  and the group was defined there, for example...) then:

  the call to sudo_debug_printf in sudo_getgrgid
  (plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
  item->d.gr->gr_name (since item->d.gr is NULL).

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

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

[Touch-packages] [Bug 1565567] Re: segv in sudo_getgrgid

[Rafael David Tinoco]

Following execution path I get:



(1)

mode_run -> policy_check -> sudoers_policy_main -> sudoers_policy_init:
 - init_vars (fills global variable sudo_user)
 - sudo_user->pwd (from global struct passwd) will be used in "user_in_group" 
as "struct passwd" of executing user 
 - it will check whether the executing user is in a certain group (pre-reqs for 
sudo execution)

/*
 * Get a local copy of the user's struct passwd if we don't already
 * have one.
 */
if (sudo_user.pw == NULL) {
if ((sudo_user.pw = sudo_getpwnam(user_name)) == NULL) {
/*
 * It is not unusual for users to place "sudo -k" in a .logout
 * file which can cause sudo to be run during reboot after the
 * YP/NIS/NIS+/LDAP/etc daemon has died.
 */
if (sudo_mode == MODE_KILL || sudo_mode == MODE_INVALIDATE) {
sudo_warnx(U_("unknown uid: %u"), (unsigned int) user_uid);
debug_return_bool(false);
}

/* Need to make a fake struct passwd for the call to log_warningx(). */
sudo_user.pw = sudo_mkpwent(user_name, user_uid, user_gid, NULL, NULL);
unknown_user = true;
}
}

so sudo_user->pwd comes from sudo_mkpwent(user_name).

At this time, impossible that sudo_mkpwent has cached values so we have:

...
item = sudo_make_pwitem((uid_t)-1, name);

if (item == NULL) {
const size_t len = strlen(name) + 1;
if (errno != ENOENT || (item = calloc(1, sizeof(*item) + len)) == NULL) {
sudo_warnx(U_("unable to cache user %s, out of memory"), name);
debug_return_ptr(NULL);
}
item->refcnt = 1;
item->k.name = (char *) item + sizeof(*item);
memcpy(item->k.name, name, len);
/* item->d.pw = NULL; */
}
strlcpy(item->registry, key.registry, sizeof(item->registry));
switch (rbinsert(pwcache_byname, item, NULL)) {
...

Since sudo_make_pwitem relies on local authentication, and user is
coming from ldap... item = NULL.

With item being NULL, cache item item->d (union) will be filled of zeroes.
With that, item->d>pw will be a NULL pointer. 

PROBLEM:

In the future, when this cache item is recovered from redblack tree, any
reference to item->d>pw will fail.

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

Title:
  segv in sudo_getgrgid

Status in sudo package in Ubuntu:
  Confirmed

Bug description:
  If the user is in a group with no name (because libnss-db got removed
  and the group was defined there, for example...) then:

  the call to sudo_debug_printf in sudo_getgrgid
  (plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
  item->d.gr->gr_name (since item->d.gr is NULL).

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

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Description changed:

+ [Impact]
  
- DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.
+  * Infiniband users relying on DHCP can't use DHCP relay.
+ 
+ [Test Case]
+ 
+  * Comment #13
+  * Mellanox has tested themselves. 
+  * Clear way of knowing if fix worked (tcpdump).
+ 
+ [Regression Potential]
+ 
+  * Only related to Infiniband.
+  * Infiniband support could stop working (unlikely, already tested).
+ 
+ [Other Info]
+ 
+ None
+ 
+ [ Original Description ]
+  
+  * Anything else you think is useful to include
+  * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
+  * and address these questions in advance
+ 
+ DHCP client is sending discover with Unicast type request for the offer,
+ in this configuration of IB to ETH through a relay we need the type to
+ be broadcast.
  
  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.
  
  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.
  
- 
- DHCP CLIENT (IPoIB) 
+ DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

** Changed in: isc-dhcp (Ubuntu Wily)
 Assignee: (unassigned) => Rafael David Tinoco (inaddy)

** Changed in: isc-dhcp (Ubuntu Trusty)
 Assignee: (unassigned) => Rafael David Tinoco (inaddy)

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Infiniband users relying on DHCP can't use DHCP relay.

  [Test Case]

   * Comment #13
   * Mellanox has tested themselves. 
   * Clear way of knowing if fix worked (tcpdump).

  [Regression Potential]

   * Only related to Infiniband.
   * Infiniband support could stop working (unlikely, already tested).

  [Other Info]

  None

  [ Original Description ]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

  DHCP client is sending discover with Unicast type request for the
  offer, in this configuration of IB to ETH through a relay we need the
  type to be broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Patch removed: "trusty_isc-dhcp_4.2.4-7ubuntu12.5.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4568523/+files/trusty_isc-dhcp_4.2.4-7ubuntu12.5.debdiff

** Patch added: "trusty_isc-dhcp_4.2.4-7ubuntu12.6.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4656420/+files/trusty_isc-dhcp_4.2.4-7ubuntu12.6.debdiff

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Infiniband users relying on DHCP can't use DHCP relay.

  [Test Case]

   * Comment #13
   * Mellanox has tested themselves. 
   * Clear way of knowing if fix worked (tcpdump).

  [Regression Potential]

   * Only related to Infiniband.
   * Infiniband support could stop working (unlikely, already tested).

  [Other Info]

  None

  [ Original Description ]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

  DHCP client is sending discover with Unicast type request for the
  offer, in this configuration of IB to ETH through a relay we need the
  type to be broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Patch added: "wily_isc-dhcp_4.3.1-5ubuntu3.2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4656430/+files/wily_isc-dhcp_4.3.1-5ubuntu3.2.debdiff

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Infiniband users relying on DHCP can't use DHCP relay.

  [Test Case]

   * Comment #13
   * Mellanox has tested themselves. 
   * Clear way of knowing if fix worked (tcpdump).

  [Regression Potential]

   * Only related to Infiniband.
   * Infiniband support could stop working (unlikely, already tested).

  [Other Info]

  None

  [ Original Description ]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

  DHCP client is sending discover with Unicast type request for the
  offer, in this configuration of IB to ETH through a relay we need the
  type to be broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

** Patch added: "xenial_isc-dhcp_4.3.3-5ubuntu13.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+attachment/4656431/+files/xenial_isc-dhcp_4.3.3-5ubuntu13.debdiff

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  [Impact]

   * Infiniband users relying on DHCP can't use DHCP relay.

  [Test Case]

   * Comment #13
   * Mellanox has tested themselves. 
   * Clear way of knowing if fix worked (tcpdump).

  [Regression Potential]

   * Only related to Infiniband.
   * Infiniband support could stop working (unlikely, already tested).

  [Other Info]

  None

  [ Original Description ]
   
   * Anything else you think is useful to include
   * Anticipate questions from users, SRU, +1 maintenance, security teams and 
the Technical Board
   * and address these questions in advance

  DHCP client is sending discover with Unicast type request for the
  offer, in this configuration of IB to ETH through a relay we need the
  type to be broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1565567] Re: segv in sudo_getgrgid

[Rafael David Tinoco]

I just verified that sudo fix seems good within yakkety. Marking it as
verification-done.

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

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

Title:
  segv in sudo_getgrgid

Status in sudo:
  Unknown
Status in sudo package in Ubuntu:
  Fix Released
Status in sudo source package in Xenial:
  Fix Committed

Bug description:
  [Impact]

  In certain environments, for example when using LDAP, users can end up
  in a group with no name. When that happens, sudo crashes when
  attempting to look up the group name for the debug log.

  Upstream has commited a simple fix for this issue, it has been
  commited to Yakkety, and uploaded to Xenial.

  [Test Case]

  I currently don't know an easy way to reproduce this, it is
  environment-specific. A package containing the fix was successfully
  tested in the problematic environment.

  [Regression Potential]

  A regression in the patch would prevent users from using sudo. The
  risk of regression is low since the patch only changes the debug log.


  Original report:

  If the user is in a group with no name (because libnss-db got removed
  and the group was defined there, for example...) then:

  the call to sudo_debug_printf in sudo_getgrgid
  (plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
  item->d.gr->gr_name (since item->d.gr is NULL).

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

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

Okay, Tks Talat.

Ill propose this fix into all versions relying on the IB patches
submitted in fix:

https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1401141

Check:

https://bugs.launchpad.net/ubuntu/+source/isc-
dhcp/+bug/1401141/comments/31

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  In Progress
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  In Progress
Status in isc-dhcp source package in Xenial:
  In Progress

Bug description:
  
  DHCP client is sending discover with Unicast type request for the offer, in 
this configuration of IB to ETH through a relay we need the type to be 
broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  
  DHCP CLIENT (IPoIB) 
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1387347] Re: sudo doesn't check for sudo group

[Rafael David Tinoco]

Pls check:

https://bugs.launchpad.net/ubuntu/+source/sudo/+bug/1565567

If facing seg-faults in Xenial.

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

Title:
  sudo doesn't check for sudo group

Status in sudo package in Ubuntu:
  Fix Released

Bug description:
  In Ubuntu, sudo is built with --enable-admin-flag to create the
  ~/.sudo_as_admin_successful after being run the first time.

  At some point, to align with Debian, the group changed from "admin" to
  "sudo", so this no longer works. A recent bash upload has fixed
  printing the blurb about using sudo in the terminal, but since the
  flag file isn't being created, the blurb always gets printed.

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

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

[Touch-packages] [Bug 1565567] Re: segv in sudo_getgrgid

[Rafael David Tinoco]

This patch was exposed by:

"also_check_sudo_group.diff"

(since user was in "sudo" group and should have stopped user_in_group
before)

Right after being caused by:

commit a1663632dc5ab7e7c01e17206854b6f0ba0347dd
Author: Todd C. Miller 
Date:   Fri Jan 22 17:04:59 2016 -0700

Additional debugging for pwutil functions.

When debug messages accessed non-referenced pointer (struct passwd)
inside the node.

---

Note:

Users that can't have "struct passwd" solved should explore something
like:

---

commit d0c0662fda02260f8ffa4f59133bfe19ccd075a2
Author: Todd C. Miller 
Date:   Sun Sep 25 06:35:40 2011 -0400

If the invoking user cannot be resolved by uid fake the struct
passwd and store it in the cache so we can delref it on exit.

---

Faking it, so any other function relying on accessing the node's
structure will succeed.

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

Title:
  segv in sudo_getgrgid

Status in sudo package in Ubuntu:
  Confirmed

Bug description:
  If the user is in a group with no name (because libnss-db got removed
  and the group was defined there, for example...) then:

  the call to sudo_debug_printf in sudo_getgrgid
  (plugins/sudoers/pwutil.c, line 462) causes a SEGV when trying to get
  item->d.gr->gr_name (since item->d.gr is NULL).

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

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

Verification for Xenial:

ubuntu@dixie:~$ uname -a
Linux dixie 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 
x86_64 x86_64 GNU/Linux

ubuntu@dixie:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 16.04.1 LTS
Release:16.04
Codename:   xenial

ubuntu@dixie:~$ dpkg -l | grep isc-dhcp
ii  isc-dhcp-client4.3.3-5ubuntu12.1   amd64
DHCP client for automatically obtaining an IP address
ii  isc-dhcp-common4.3.3-5ubuntu12.1   amd64
common files used by all of the isc-dhcp packages
ii  isc-dhcp-server4.3.3-5ubuntu12.1   amd64
ISC DHCP server for automatic IP address assignment

You can observe that DHCP works AND broadcast flag is set (by sniffing
dhcp server ib0 interface):

ubuntu@dixie:~$ sudo tcpdump -i ib0 -nn -vvv -S
tcpdump: listening on ib0, link-type LINUX_SLL (Linux cooked), capture size 
262144 bytes
16:21:22.603191 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 
300, htype 32, hlen 0, xid 0x6775c96f, Flags [Broadcast] (0x8000)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 5: "hertz"
Parameter-Request Option 55, length 13: 
  Subnet-Mask, BR, Time-Zone, Default-Gateway
  Domain-Name, Domain-Name-Server, Option 119, Hostname
  Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
  NTP
Client-ID Option 61, length 17: hardware-type 56, 
30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
END Option 255, length 0
PAD Option 0, length 0, occurs 15
16:21:22.603401 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 
300, htype 32, hlen 0, xid 0x6775c96f, Flags [Broadcast] (0x8000)
  Your-IP 172.16.0.19
  Server-IP 172.16.0.1
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.16.0.1
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 172.16.0.255
Domain-Name Option 15, length 7: "myib.cu"
END Option 255, length 0
PAD Option 0, length 0, occurs 23
16:21:22.603586 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 
300, htype 32, hlen 0, xid 0x6775c96f, Flags [Broadcast] (0x8000)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Server-ID Option 54, length 4: 172.16.0.1
Requested-IP Option 50, length 4: 172.16.0.19
Hostname Option 12, length 5: "hertz"
Parameter-Request Option 55, length 13: 
  Subnet-Mask, BR, Time-Zone, Default-Gateway
  Domain-Name, Domain-Name-Server, Option 119, Hostname
  Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
  NTP
Client-ID Option 61, length 17: hardware-type 56, 
30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
END Option 255, length 0
PAD Option 0, length 0, occurs 3
16:21:22.603758 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 
300, htype 32, hlen 0, xid 0x6775c96f, Flags [Broadcast] (0x8000)
  Your-IP 172.16.0.19
  Server-IP 172.16.0.1
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 172.16.0.1
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 172.16.0.255
Domain-Name Option 15, length 7: "myib.cu"
END Option 255, length 0
PAD Option 0, length 0, occurs 23

Everything looks good!!


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

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  Fix Committed
Status in isc-dhcp source 

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

I think I should skip Wily verification (EOL) and pursue Trusty verification.
It looks like Trusty fix wasn't committed. Could you commit Trusty so I can 
verify it ?

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Infiniband users relying on DHCP can't use DHCP relay.

  [Test Case]

   * Comment #13
   * Mellanox has tested themselves.
   * Clear way of knowing if fix worked (tcpdump).

  [Regression Potential]

   * Only related to Infiniband.
   * Infiniband support could stop working (unlikely, already tested).

  [Other Info]

  DHCP client is sending discover with Unicast type request for the
  offer, in this configuration of IB to ETH through a relay we need the
  type to be broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

Subscribing sponsors again so Trusty can be sponsored. Still waiting on
SRU for Trusty.

** Tags removed: verification-needed-trusty

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  In Progress
Status in isc-dhcp source package in Wily:
  Fix Committed
Status in isc-dhcp source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Infiniband users relying on DHCP can't use DHCP relay.

  [Test Case]

   * Comment #13
   * Mellanox has tested themselves.
   * Clear way of knowing if fix worked (tcpdump).

  [Regression Potential]

   * Only related to Infiniband.
   * Infiniband support could stop working (unlikely, already tested).

  [Other Info]

  DHCP client is sending discover with Unicast type request for the
  offer, in this configuration of IB to ETH through a relay we need the
  type to be broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1550983] Re: Fails to start with "Couldn't open libGL.so.1" (missing dependency?)

[Rafael David Tinoco]

** Tags added: sts-sponsor

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

Title:
  Fails to start with "Couldn't open libGL.so.1" (missing dependency?)

Status in One Hundred Papercuts:
  Confirmed
Status in gtk+3.0 package in Ubuntu:
  Fix Released
Status in gtk+3.0 source package in Xenial:
  New
Status in gtk+3.0 source package in Yakkety:
  New
Status in gtk+3.0 package in Debian:
  Fix Released

Bug description:
  [Impact] 
  There are some unlinked calls to libGL.so.1 undetected in the build process 
because of using libepoxy. Running an application that does not depend on 
libgl1 (directly or indirectly) may lead to aborting the process with an 
undefined reference to libGL.so.1.

  [Test Case]
  1. Deploy a server / cloud image of Xenial or Yakkety.
  2. Use a Windows or a Mac client with Cygwin/X and ssh -XY to Ubuntu machine.
  3. sudo apt install firefox; firefox

  Expected result:
  firefox is launched on the client machine.

  Actual result:
  "Couldn't open libGL.so.1" message is printed.

  [Regression Potential] 
  Minimal

  [Other Info]
  Original bug description:

  virt-manager fails to start:

  $ virt-manager --debug --no-fork
  [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (cli:256) Launched with 
command line: /usr/share/virt-manager/virt-manager --debug --no-fork
  [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:143) 
virt-manager version: 1.3.2
  [Sun, 28 Feb 2016 19:18:22 virt-manager 7592] DEBUG (virt-manager:144) 
virtManager import: 
  Couldn't open libGL.so.1: libGL.so.1: cannot open shared object file: No such 
file or directory
  $

  Installing the 'libgl1-mesa-glx' package resolves the issue.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: virt-manager 1:1.3.2-0ubuntu1
  ProcVersionSignature: Ubuntu 4.4.0-8.23-generic 4.4.2
  Uname: Linux 4.4.0-8-generic x86_64
  ApportVersion: 2.20-0ubuntu3
  Architecture: amd64
  Date: Sun Feb 28 19:19:27 2016
  InstallationDate: Installed on 2016-02-27 (0 days ago)
  InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 
(20160206)
  PackageArchitecture: all
  SourcePackage: virt-manager
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

After long time I got the lab back so I'm verifying Trusty right now.

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  Fix Committed
Status in isc-dhcp source package in Wily:
  Won't Fix
Status in isc-dhcp source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Infiniband users relying on DHCP can't use DHCP relay.

  [Test Case]

   * Comment #13
   * Mellanox has tested themselves.
   * Clear way of knowing if fix worked (tcpdump).

  [Regression Potential]

   * Only related to Infiniband.
   * Infiniband support could stop working (unlikely, already tested).

  [Other Info]

  DHCP client is sending discover with Unicast type request for the
  offer, in this configuration of IB to ETH through a relay we need the
  type to be broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

Okay, bug:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1496942

Is avoiding me to verify this. 
The lab I was able to get was a ConnectX-4 HCA lab (I was planning to use 
SR-IOV). 
I'll check if I can have two ConnectX-3 servers to verify this.

Be back soon.

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

Title:
  InfiniBand DHCP flow with PRA and DHCP relay not working

Status in isc-dhcp package in Ubuntu:
  Fix Released
Status in isc-dhcp source package in Trusty:
  Fix Committed
Status in isc-dhcp source package in Wily:
  Won't Fix
Status in isc-dhcp source package in Xenial:
  Fix Released

Bug description:
  [Impact]

   * Infiniband users relying on DHCP can't use DHCP relay.

  [Test Case]

   * Comment #13
   * Mellanox has tested themselves.
   * Clear way of knowing if fix worked (tcpdump).

  [Regression Potential]

   * Only related to Infiniband.
   * Infiniband support could stop working (unlikely, already tested).

  [Other Info]

  DHCP client is sending discover with Unicast type request for the
  offer, in this configuration of IB to ETH through a relay we need the
  type to be broadcast.

  The issue is that when using dhclient from the client on Ubuntu (and only on 
Ubuntu) with MOFED or inbox driver, we see that that DHCP server offers in 
unicast instead of broadcast. It seems there is no way to correct this from the 
client side using dhclient configuration file.
  this issue exist even when we use always-broadcast statement in configuration 
file.

  in other vendors we see that discover request type is broadcast.
  attached pcap files from working (other vendor) and not working (Ubuntu) 
clients.

  DHCP CLIENT (IPoIB)
  Ubuntu 14.04  kernel 3.13.0-74
  Mellanox OFED 3.1-1.0.3 or inbox driver
  isc-dhcp-client  4.2.4-7ubuntu12.3

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1529815/+subscriptions

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

[Touch-packages] [Bug 1529815] Re: InfiniBand DHCP flow with PRA and DHCP relay not working

[Rafael David Tinoco]

Verification for Trusty:

## server

root@dixie:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.5 LTS
Release:14.04
Codename:   trusty

root@dixie:~# dpkg -l | grep dhcp
ii  isc-dhcp-client 4.2.4-7ubuntu12.6amd64  
  ISC DHCP client
ii  isc-dhcp-common 4.2.4-7ubuntu12.6amd64  
  common files used by all the isc-dhcp* packages
ii  isc-dhcp-server 4.2.4-7ubuntu12.6amd64  
  ISC DHCP server for automatic IP address assignment

## client

root@hertz:~# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 14.04.5 LTS
Release:14.04
Codename:   trusty

root@hertz:~# dpkg -l | grep dhcp
ii  isc-dhcp-client 4.2.4-7ubuntu12.6amd64  
  ISC DHCP client
ii  isc-dhcp-common 4.2.4-7ubuntu12.6amd64  
  common files used by all the isc-dhcp* packages

--

## tcpdump showing broadcast flag set (client was able to get IP)

root@dixie:~# tcpdump -i ib0 -nn -vvv -S
Sep  8 12:31:32 dixie kernel: [ 1763.559815] device ib0 entered promiscuous mode
tcpdump: listening on ib0, link-type LINUX_SLL (Linux cooked), capture size 
65535 bytes
Sep  8 12:31:36 dixie dhcpd: DHCPDISCOVER from  via ib0
Sep  8 12:31:36 dixie dhcpd: DHCPOFFER on 172.16.0.19 to  via ib0
Sep  8 12:31:36 dixie dhcpd: Dynamic and static leases present for 172.16.0.19.
Sep  8 12:31:36 dixie dhcpd: Remove host declaration dixie or remove 172.16.0.19
Sep  8 12:31:36 dixie dhcpd: from the dynamic address pool for 172.16.0.0/24
Sep  8 12:31:36 dixie dhcpd: DHCPREQUEST for 172.16.0.19 (172.16.0.1) from  via 
ib0
Sep  8 12:31:36 dixie dhcpd: DHCPACK on 172.16.0.19 to  via ib0
12:31:36.612464 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 
300, htype 32, hlen 0, xid 0x6189781a, Flags [Broadcast] (0x8000)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Hostname Option 12, length 5: "hertz"
Parameter-Request Option 55, length 13:
  Subnet-Mask, BR, Time-Zone, Default-Gateway
  Domain-Name, Domain-Name-Server, Option 119, Hostname
  Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
  NTP
Client-ID Option 61, length 17: hardware-type 56, 
30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
END Option 255, length 0
PAD Option 0, length 0, occurs 15
12:31:36.612713 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 
300, htype 32, hlen 0, xid 0x6189781a, Flags [Broadcast] (0x8000)
  Your-IP 172.16.0.19
  Server-IP 172.16.0.1
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 172.16.0.1
Lease-Time Option 51, length 4: 600
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 172.16.0.255
Domain-Name Option 15, length 7: "myib.cu"
END Option 255, length 0
PAD Option 0, length 0, occurs 23
12:31:36.612957 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request, length 
300, htype 32, hlen 0, xid 0x6189781a, Flags [Broadcast] (0x8000)
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Server-ID Option 54, length 4: 172.16.0.1
Requested-IP Option 50, length 4: 172.16.0.19
Hostname Option 12, length 5: "hertz"
Parameter-Request Option 55, length 13:
  Subnet-Mask, BR, Time-Zone, Default-Gateway
  Domain-Name, Domain-Name-Server, Option 119, Hostname
  Netbios-Name-Server, Netbios-Scope, MTU, Classless-Static-Route
  NTP
Client-ID Option 61, length 17: hardware-type 56, 
30:3a:30:30:3a:30:30:3a:34:38:3a:46:45:3a:38:30
END Option 255, length 0
PAD Option 0, length 0, occurs 3
12:31:36.613122 IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP 
(17), length 328)
172.16.0.1.67 > 255.255.255.255.68: [udp sum ok] BOOTP/DHCP, Reply, length 
300, htype 32, hlen 0, xid 0x6189781a, Flags [Broadcast] (0x8000)
  Your-IP 172.16.0.19
  Server-IP 172.16.0.1
  Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 

[Touch-packages] [Bug 1635812] Re: atril-thumbnailer crashed with SIGSEGV in cmsGetColorSpace()

[Rafael David Tinoco]

@Sponsors

(Yakkety) Facing intermittent seg faults in multiple PDFs here. If
opening it with strace it rarely occurs, suggesting it is a timing/sync
issue.

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x7f3e05ed1940 in cmsGetColorSpace () from 
/usr/lib/x86_64-linux-gnu/liblcms2.so.2
[Current thread is 1 (Thread 0x7f3e06ffb700 (LWP 6665))]
(gdb) info threads
  Id   Target Id Frame 
* 1Thread 0x7f3e06ffb700 (LWP 6665) 0x7f3e05ed1940 in cmsGetColorSpace 
()

Foud this bug, the fix looks good for me, fixed the issue for my case.

I have an easy way to verify it when it lands -proposed, if needed.

Thank you!

Rafael

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

Title:
  atril-thumbnailer crashed with SIGSEGV in cmsGetColorSpace()

Status in Poppler:
  Unknown
Status in poppler package in Ubuntu:
  Fix Released

Bug description:
  atril-thumbnailer crashed with SIGSEGV in cmsGetColorSpace()

  ProblemType: Crash
  DistroRelease: Ubuntu 16.04
  Package: atril 1.12.2-1
  ProcVersionSignature: Ubuntu 4.4.0-45.66-generic 4.4.21
  Uname: Linux 4.4.0-45-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.1
  Architecture: amd64
  CrashCounter: 1
  CurrentDesktop: MATE
  Date: Sat Oct 22 09:43:08 2016
  ExecutablePath: /usr/bin/atril-thumbnailer
  InstallationDate: Installed on 2016-05-14 (160 days ago)
  InstallationMedia: Ubuntu-MATE 16.04 LTS "Xenial Xerus" - Release amd64 
(20160420.1)
  ProcCmdline: atril-thumbnailer -s 128 
file:///home/username/Documents/jedi_complaint.pdf 
/tmp/.mate_desktop_thumbnail.8JDPPY
  SegvAnalysis:
   Segfault happened at: 0x7fdcb0258990 : mov
0x50(%rdi),%eax
   PC (0x7fdcb0258990) ok
   source "0x50(%rdi)" (0x0050) not located in a known VMA region (needed 
readable region)!
   destination "%eax" ok
  SegvReason: reading NULL VMA
  Signal: 11
  SourcePackage: atril
  StacktraceTop:
   cmsGetColorSpace () from /usr/lib/x86_64-linux-gnu/liblcms2.so.2
   GfxICCBasedColorSpace::parse(Array*, OutputDev*, GfxState*, int) () from 
/usr/lib/x86_64-linux-gnu/libpoppler.so.58
   GfxColorSpace::parse(GfxResources*, Object*, OutputDev*, GfxState*, int) () 
from /usr/lib/x86_64-linux-gnu/libpoppler.so.58
   Page::loadThumb(unsigned char**, int*, int*, int*) () from 
/usr/lib/x86_64-linux-gnu/libpoppler.so.58
   poppler_page_get_thumbnail () from 
/usr/lib/x86_64-linux-gnu/libpoppler-glib.so.8
  Title: atril-thumbnailer crashed with SIGSEGV in cmsGetColorSpace()
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo wireshark

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

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

[Touch-packages] [Bug 1569925] Re: Shutdown hang on 16.04 with iscsi targets

[Rafael David Tinoco]

Another thing. Please check for containers referencing the filesystems
in question. When you have _netdev filesystems, it is possible that the
"mount --shared" characteristics of containers (different mount
namescapes) are holding references to the filesystem in question.

A good test is to test the filesystem being mounted by /etc/fstab AND
manually. If mounted with _netdev, by /etc/fstab, then the containers
will have reference to the same filesystems as a shared mount. This will
cause a shutdown problem if you don't remove the container reference as
well.

Please do test this as well.

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

Title:
  Shutdown hang on 16.04 with iscsi targets

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed

Bug description:
  I have 4 servers running the latest 16.04 updates from the development
  branch (as of right now).

  Each server is connected to NetApp storage using iscsi software
  initiator.  There are a total of 56 volumes spread across two NetApp
  arrays.  Each volume has 4 paths available to it which are being
  managed by device mapper.

  While logged into the iscsi sessions all I have to do is reboot the
  server and I get a hang.

  I see a message that says:

    "Reached target Shutdown"

  followed by

    "systemd-shutdown[1]: Failed to finalize DM devices, ignoring"

  and then I see 8 lines that say:

    "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    NOTE: the actual values of the *'s differ for each line above.

  This seems like a bug somewhere but I am unaware of any additional
  logging that I could turn on to pinpoint the problem.

  Note I also have similar setups that are not doing iscsi and they
  don't have this problem.

  Here is a screenshot of what I see on the shell when I try to reboot:

  (https://launchpadlibrarian.net/291303059/Screenshot.jpg)

  This is being tracked in NetApp bug tracker CQ number 860251.

  If I log out of all iscsi sessions before rebooting then I do not
  experience the hang:

  iscsiadm -m node -U all

  We are wondering if this could be some kind of shutdown ordering
  problem.  Like the network devices have already disappeared and then
  iscsi tries to perform some operation (hence the ping timeouts).

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

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

[Touch-packages] [Bug 1569925] Re: Shutdown hang on 16.04 with iscsi targets

[Rafael David Tinoco]

Anyone facing this..

Could you please make sure to propagate I/O errors properly to
filesystem in order for it to call its automatically shutdown procedure.
After that, the mount won't reference the super block in kernel and that
will allow the device mapper to be closed/destroyed (this can be seen by
checking existence of device-mapper node in
/sys/fs/{xfs,ext3,ext4}/node, saying that the super block is still being
referenced).

I had a recent case where not propagating the error would cause the
filesystem to hang forever, causing lockups and not allowing the device-
mapper tables to be flushed by multipath. In this case, if the network
was turned off before the iscsi was logged, the multipath (dm) and iscsi
(transport) layers HAVE TO propagate the I/O error to the filesystem for
it to shutdown.

This is can be done by:

node.session.timeo.replacement_timeout = 0 (iscsid.conf)

USE: iscsiadm -m node -T $target_name -p $target_ip:$port  -o update -n \
node.session.timeo.replacement_timeout -v $timeout_value on already 
logged/discovered LUNs. This parameter might be persistent on already 
discovered LUNs.

AND:

dev_loss_tmo 10 (multipath.conf)


OBS: node.session.timeo.replacement_timeout has to be changed per 

The fact that the network was removed BEFORE the iscsi logout could
happen is NOT an issue if ROOT device is not ISCSI, you just have to
allow the block device <-> device mapper <-> transport layer logic
shutdown to work.

Pay attention because if filesystem is umounted and iscsi is gone, the
timeout will have to be waited before the error is propagated to other
layer. So if filesystem is umounted a last superblock inode update will
be attempted (if no cache in pagecache). This will make the I/O error
for the superblock inode to fail (after time timeout you configured).
This will make the filesystem to be shutdown (a half unmounted state).
After shutdown, the logic trying to umount (synchronously) the
filesystem will continue (possibly in systemd).

If the problem is because of you tried to flush the device mapper and
the filesystem was still referencing the device mapper super block, this
will fade away if the error is propagated and the filesystem is
shutdown, you can attempt doing the flush of device-mapper right after
filesystem shutdown happened.

Could you please try setting the timeouts properly for lower timings and
let me know if that mitigated the issue ?

Thank you

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

Title:
  Shutdown hang on 16.04 with iscsi targets

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed

Bug description:
  I have 4 servers running the latest 16.04 updates from the development
  branch (as of right now).

  Each server is connected to NetApp storage using iscsi software
  initiator.  There are a total of 56 volumes spread across two NetApp
  arrays.  Each volume has 4 paths available to it which are being
  managed by device mapper.

  While logged into the iscsi sessions all I have to do is reboot the
  server and I get a hang.

  I see a message that says:

    "Reached target Shutdown"

  followed by

    "systemd-shutdown[1]: Failed to finalize DM devices, ignoring"

  and then I see 8 lines that say:

    "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    NOTE: the actual values of the *'s differ for each line above.

  This seems like a bug somewhere but I am unaware of any additional
  logging that I could turn on to pinpoint the problem.

  Note I also have similar setups that are not doing iscsi and they
  don't have this problem.

  Here is a screenshot of what I see on the shell when I try to reboot:

  (https://launchpadlibrarian.net/291303059/Screenshot.jpg)

  This is being tracked in NetApp bug tracker CQ number 860251.

  If I log out of all iscsi sessions before rebooting then I do not
  experience the hang:

  

[Touch-packages] [Bug 1569925] Re: Shutdown hang on 16.04 with iscsi targets

[Rafael David Tinoco]

Anyone facing this..

Could you please make sure to propagate I/O errors properly to
filesystem in order for it to call its automatically shutdown procedure.
After that, the mount won't reference the super block in kernel and that
will allow the device mapper to be destroyed (this can be seen by
checking existence of device-mapper node in
/sys/fs/{xfs,ext3,ext4}/node, saying that the super block is still being
referenced).

I had a recent case where not propagating the error would cause the
filesystem to hang forever, causing lockups and not allowing the device-
mapper tables to be flushed by multipath (or even the OS to be
operational). In this case, if the network is turned off (or
interrupted) before the ISCSI is logged out, then the multipath (dm) and
iscsi (transport) layers HAVE TO propagate the I/O error to the
filesystem for it to shutdown BEFORE the device mapper flush logic is
attempted (by issuing ioctls to /dev/dm-X by multipath or lvm, example).

This is can be done by:

node.session.timeo.replacement_timeout = 0 (iscsid.conf)
(This parameter might be persistent on already discovered LUNs)

USAGE:
iscsiadm -m node -T $target_name -p $target_ip:$port -o update -n \
node.session.timeo.replacement_timeout -v $timeout_value 
on already logged/discovered LUNs. 

 AND 

dev_loss_tmo 10 (multipath.conf)

The fact that the network was removed BEFORE the ISCSI logout happened
is NOT an issue if ROOT device is NOT on ISCSI: You just have to allow
the block device <-> device mapper <-> transport layer SHUTDOWN logic to
WORK before flushing the device-mapper. (Hopefully the umount on _netdev
devices is done, causes an I/O error, filesystem shuts down, multipath
service closes multipath device-mapper devices).

Pay attention because if filesystem is umounted and ISCSI is gone, the
timeout will have to be waited before the error is PROPAGATED to other
layer. So if filesystem is umounted, ONE last superblock inode UPDATE
will be attempted (if no cache in pagecache). This update is to sync
superblock state and update metadata for the filesystem itself. This
update attempt will create an I/O error for the superblock inode (after
time timeout you configured). This will make the filesystem to be
shutdown (a half unmounted state). After shutdown, the logic trying to
umount (synchronously) the filesystem will continue (possibly in
systemd).

If the problem is because of you tried to flush the device mapper and
the filesystem was still referencing the device mapper super block, this
will fade away if the error is propagated and the filesystem is
shutdown, you can attempt doing the flush of device-mapper right after
filesystem shutdown happened.

Could you please try setting the timeouts properly for lower timings and
let me know if that mitigated the issue ?

Thank you

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

Title:
  Shutdown hang on 16.04 with iscsi targets

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed

Bug description:
  I have 4 servers running the latest 16.04 updates from the development
  branch (as of right now).

  Each server is connected to NetApp storage using iscsi software
  initiator.  There are a total of 56 volumes spread across two NetApp
  arrays.  Each volume has 4 paths available to it which are being
  managed by device mapper.

  While logged into the iscsi sessions all I have to do is reboot the
  server and I get a hang.

  I see a message that says:

    "Reached target Shutdown"

  followed by

    "systemd-shutdown[1]: Failed to finalize DM devices, ignoring"

  and then I see 8 lines that say:

    "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    NOTE: the actual values of the *'s differ for each line above.

  This seems like a bug somewhere but I am unaware of any additional
  logging that I could turn on to pinpoint the problem.

 

[Touch-packages] [Bug 1569925] Re: Shutdown hang on 16.04 with iscsi targets

[Rafael David Tinoco]

** Changed in: systemd (Ubuntu Xenial)
 Assignee: (unassigned) => Rafael David Tinoco (inaddy)

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

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

Title:
  Shutdown hang on 16.04 with iscsi targets

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Xenial:
  In Progress

Bug description:
  I have 4 servers running the latest 16.04 updates from the development
  branch (as of right now).

  Each server is connected to NetApp storage using iscsi software
  initiator.  There are a total of 56 volumes spread across two NetApp
  arrays.  Each volume has 4 paths available to it which are being
  managed by device mapper.

  While logged into the iscsi sessions all I have to do is reboot the
  server and I get a hang.

  I see a message that says:

    "Reached target Shutdown"

  followed by

    "systemd-shutdown[1]: Failed to finalize DM devices, ignoring"

  and then I see 8 lines that say:

    "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    NOTE: the actual values of the *'s differ for each line above.

  This seems like a bug somewhere but I am unaware of any additional
  logging that I could turn on to pinpoint the problem.

  Note I also have similar setups that are not doing iscsi and they
  don't have this problem.

  Here is a screenshot of what I see on the shell when I try to reboot:

  (https://launchpadlibrarian.net/291303059/Screenshot.jpg)

  This is being tracked in NetApp bug tracker CQ number 860251.

  If I log out of all iscsi sessions before rebooting then I do not
  experience the hang:

  iscsiadm -m node -U all

  We are wondering if this could be some kind of shutdown ordering
  problem.  Like the network devices have already disappeared and then
  iscsi tries to perform some operation (hence the ping timeouts).

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

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

[Touch-packages] [Bug 1569925] Re: Shutdown hang on 16.04 with iscsi targets

[Rafael David Tinoco]

Hello Matt,

Good to read your feedback. When you have multipath AND iscsi, the error
propagation timeout can be given by one or both, that is why I explained
both. This issue is not an iscsi or multipath problem, it is a systemd
problem related to the fact that the network is removed before the disks
are unmounted. Good to know you don't have containers, that is something
that could hold the disk superblock reference as well (even not having
containers, filesystems mounted by _netdev can hold reference by
different mount namespaces started by systemd itself, not the case
here).

Could you do me a favor. Are you reproducing this issue in a constant
basis ? If you are, could you please reduce your replacement_timeout to
0 and see if you can reproduce it again ? Please be aware that, after
changing replacement_timeout = 0 in iscsid.conf, you will have to change
the parameter for the disks already discovered:

## example

Change iscsid.conf AND:

$ sudo iscsiadm -m node
192.168.48.1:3260,1 iqn.2017.tgtd:tid2.lun
192.168.48.1:3260,1 iqn.2017.tgtd:tid1.lun

$ sudo iscsiadm -m node -o show | grep node.session.timeo.replacement_timeout
node.session.timeo.replacement_timeout = 20
node.session.timeo.replacement_timeout = 20

$ sudo iscsiadm -m node -o update -n node.session.timeo.replacement_timeout -v 0
$ sudo iscsiadm -m node -o show | grep node.session.timeo.replacement_timeout
node.session.timeo.replacement_timeout = 0
node.session.timeo.replacement_timeout = 0

This will cause the I/O errors to be propagated right away - when
systemd disconnects the interface - and cause the later umount - done by
other systemd service - to succeed without waiting for pagecache timeout
+ iscsi timeout (20 for you). Hopefully the "0" will be fast enough to
make systemd to continue all the times.

Could you please let me know if it mitigates the issue ? If it does,
I'll work in the actual fix. This will just confirm hypothesis and help
in diagnose (and serve as a workaround if anyone cares).

Thank you
-Rafael

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

Title:
  Shutdown hang on 16.04 with iscsi targets

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Xenial:
  In Progress

Bug description:
  I have 4 servers running the latest 16.04 updates from the development
  branch (as of right now).

  Each server is connected to NetApp storage using iscsi software
  initiator.  There are a total of 56 volumes spread across two NetApp
  arrays.  Each volume has 4 paths available to it which are being
  managed by device mapper.

  While logged into the iscsi sessions all I have to do is reboot the
  server and I get a hang.

  I see a message that says:

    "Reached target Shutdown"

  followed by

    "systemd-shutdown[1]: Failed to finalize DM devices, ignoring"

  and then I see 8 lines that say:

    "connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection2:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection4:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection5:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection6:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection7:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    "connection8:0: ping timeout of 5 secs expired, recv timeout 5, last rx 
4311815***, last ping 43118164**, now 4311817***"
    NOTE: the actual values of the *'s differ for each line above.

  This seems like a bug somewhere but I am unaware of any additional
  logging that I could turn on to pinpoint the problem.

  Note I also have similar setups that are not doing iscsi and they
  don't have this problem.

  Here is a screenshot of what I see on the shell when I try to reboot:

  (https://launchpadlibrarian.net/291303059/Screenshot.jpg)

  This is being tracked in NetApp bug tracker CQ number 860251.

  If I log out of all iscsi sessions before rebooting then I do not
  experience the hang:

  iscsiadm -m node -U all

  We are wondering if this could be some kind of shutdown ordering
  problem.  Like the network devices have already disappeared and then
  iscsi tries to perform some operation (hence the ping timeouts).

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

-- 
Mailing list: 

[Touch-packages] [Bug 1718966] Re: Cannot install snaps on Ubuntu 14.04 with /var on its own partition

[Rafael David Tinoco]

I've made a small change creating a unit file slightly different from
the one already present in systemd-204, considering different
dependencies for this usage (mounting/umounting volumes when upstart has
already taken part on it).

The result is here: http://pastebin.ubuntu.com/25663762/

As you can see, after installing the new packages, being proposed in
this fix, snapd can work again mounting all new squash filesystems it
depends on.

- Attaching the debdiff for SRU.
- Requesting SRU sponsoring.
- Will verify once it gets uploaded to -proposed.

** Patch added: "trusty_systemd_204-5ubuntu20.25.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1718966/+attachment/4960880/+files/trusty_systemd_204-5ubuntu20.25.debdiff

** Tags added: sts sts-sponsor

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

Title:
  Cannot install snaps on Ubuntu 14.04 with /var on its own partition

Status in snapd:
  Invalid
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress

Bug description:
  Installing snaps is not possible on Ubuntu 14.04 when having /var on
  its own partition, whether its LVM or not.

  The issue is with the core snap being unable to mount:

  The error with /var isolated and using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  The error with /var isolated but without using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service
 failed to load: No such file or directory. See system logs and 'systemctl 
status 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service'
 for details.
  )

  The same error happens if I try to install the hello-world snap (with
  LVM in this example):

  root@ubuntu:~# snap install hello-world
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  I cannot reproduce the issue in Ubuntu 16.04.

  I couldn't reproduce this issue by using the Ubuntu 14.04 cloud image
  which doesn't isolate /var on its own partition. I tried adding a
  secondary disk to that cloud image VM and create a dummy VG and LV,
  but couldn't reproduce the issue.

  Also could not reproduce using Ubuntu 14.04 (with LVM or not) but with
  only a / partition and swap.

  
  Steps to reproduce:
  ===

  # Install Ubuntu 14.04 in KVM (I used the 14.04.4 server iso) and
  configure /, /var and swap on their own partitions (with LVM or not,
  the issue happens in both situations).

  root@ubuntu:~# lvs
  LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
  rootvol vg00 -wi-ao--- 3.72g 
  swap vg00 -wi-ao--- 3.72g 
  varvol vg00 -wi-ao--- 3.72g 

  root@ubuntu:~# df -h
  Filesystem   Size  Used Avail Use% Mounted on
  udev 484M  4.0K  484M   1% /dev
  tmpfs100M  988K   99M   1% /run
  /dev/dm-03.7G  1.7G  1.8G  49% /
  none 4.0K 0  4.0K   0% /sys/fs/cgroup
  none 5.0M 0  5.0M   0% /run/lock
  none 497M 0  497M   0% /run/shm
  none 100M 0  100M   0% /run/user
  /dev/mapper/vg00-varvol  3.7G  716M  2.8G  21% /var

  
  # Upgrade system, install snapd and reboot

  root@ubuntu:~# apt update
  root@ubuntu:~# apt upgrade -y
  root@ubuntu:~# apt install -y snapd
  root@ubuntu:~# reboot

  
  # After reboot, check kernel version and try to install the 
canonical-livepatch snap:

  root@ubuntu:~# uname -a
  Linux ubuntu 4.4.0-96-generic #119~14.04.1-Ubuntu SMP Wed Sep 13 08:40:48 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

  root@ubuntu:~# snap list
  No snaps are installed yet. Try "snap install hello-world".

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed 

[Touch-packages] [Bug 1718966] Re: Cannot install snaps on Ubuntu 14.04 with /var on its own partition

[Rafael David Tinoco]

Meanwhile I have created a PPA containing the fix for all those affected
users:

https://launchpad.net/~inaddy/+archive/ubuntu/lp1718966

$ sudo add-apt-repository ppa:inaddy/lp1718966
$ sudo apt-get update
$ sudo apt-get dist-upgrade

Is likely enough for you to have a temporary fix.

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

Title:
  Cannot install snaps on Ubuntu 14.04 with /var on its own partition

Status in snapd:
  Invalid
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress

Bug description:
  Installing snaps is not possible on Ubuntu 14.04 when having /var on
  its own partition, whether its LVM or not.

  The issue is with the core snap being unable to mount:

  The error with /var isolated and using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  The error with /var isolated but without using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service
 failed to load: No such file or directory. See system logs and 'systemctl 
status 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service'
 for details.
  )

  The same error happens if I try to install the hello-world snap (with
  LVM in this example):

  root@ubuntu:~# snap install hello-world
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  I cannot reproduce the issue in Ubuntu 16.04.

  I couldn't reproduce this issue by using the Ubuntu 14.04 cloud image
  which doesn't isolate /var on its own partition. I tried adding a
  secondary disk to that cloud image VM and create a dummy VG and LV,
  but couldn't reproduce the issue.

  Also could not reproduce using Ubuntu 14.04 (with LVM or not) but with
  only a / partition and swap.

  
  Steps to reproduce:
  ===

  # Install Ubuntu 14.04 in KVM (I used the 14.04.4 server iso) and
  configure /, /var and swap on their own partitions (with LVM or not,
  the issue happens in both situations).

  root@ubuntu:~# lvs
  LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
  rootvol vg00 -wi-ao--- 3.72g 
  swap vg00 -wi-ao--- 3.72g 
  varvol vg00 -wi-ao--- 3.72g 

  root@ubuntu:~# df -h
  Filesystem   Size  Used Avail Use% Mounted on
  udev 484M  4.0K  484M   1% /dev
  tmpfs100M  988K   99M   1% /run
  /dev/dm-03.7G  1.7G  1.8G  49% /
  none 4.0K 0  4.0K   0% /sys/fs/cgroup
  none 5.0M 0  5.0M   0% /run/lock
  none 497M 0  497M   0% /run/shm
  none 100M 0  100M   0% /run/user
  /dev/mapper/vg00-varvol  3.7G  716M  2.8G  21% /var

  
  # Upgrade system, install snapd and reboot

  root@ubuntu:~# apt update
  root@ubuntu:~# apt upgrade -y
  root@ubuntu:~# apt install -y snapd
  root@ubuntu:~# reboot

  
  # After reboot, check kernel version and try to install the 
canonical-livepatch snap:

  root@ubuntu:~# uname -a
  Linux ubuntu 4.4.0-96-generic #119~14.04.1-Ubuntu SMP Wed Sep 13 08:40:48 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

  root@ubuntu:~# snap list
  No snaps are installed yet. Try "snap install hello-world".

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

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

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

[Touch-packages] [Bug 1312419] Re: nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

[Rafael David Tinoco]

** Changed in: libnl3 (Ubuntu)
 Assignee: Rafael David Tinoco (inaddy) => (unassigned)

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

Title:
  nl_cache_refill; rtnl_neigh_get fail to find neighbors in cache

Status in libnl3 package in Ubuntu:
  In Progress

Bug description:
  Retrieving information about configured neighbors fail 
  my application is running the following procedure:

  neigh = NULL;
  cache = rtnl_neigh_alloc_cache(sk);
  while(NULL == neigh){
  nl_cache_refill(sk, chache);
  neigh = rtnl_neigh_get(cache, ifindex, dst_addr);
  }

  with libnl3 3.2.21-1 this loop will never end, even when adding a static arp 
entry.
  However, with libnl-3.2.24 the neighbor lookup succeed.

  additional general info:
  $ lsb_release -rd
  Description:Ubuntu 14.04 LTS
  Release:14.04
  $ uname -r
  3.13.0-24-generic
  $ apt-cache policy libnl-genl-3-200 libnl-route-3-200
  libnl-genl-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status
  libnl-route-3-200:
Installed: 3.2.21-1
Candidate: 3.2.21-1
Version table:
   *** 3.2.21-1 0
  500 http://us.archive.ubuntu.com/ubuntu/ trusty/main amd64 Packages
  100 /var/lib/dpkg/status

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

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

[Touch-packages] [Bug 1718966] Re: Cannot install snaps on Ubuntu 14.04 with /var on its own partition

[Rafael David Tinoco]

After fixing this BUG (for canonical-livepatch snap to work, but being
affected by broken systemd in Trusty due to the lack of systemd-
fsck@.service unit file, I'm facing the following opened BUG:
https://bugs.launchpad.net/snapd/+bug/1721518 for canonical-livepatch
(or any other snap) to work).

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

Title:
  Cannot install snaps on Ubuntu 14.04 with /var on its own partition

Status in snapd:
  Invalid
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress

Bug description:
  [Impact]

  Installing snaps is not possible on Ubuntu 14.04 when having /var on
  its own partition, whether its LVM or not.

  The issue is with the core snap being unable to mount:

  The error with /var isolated and using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  The error with /var isolated but without using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service
 failed to load: No such file or directory. See system logs and 'systemctl 
status 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service'
 for details.
  )

  The same error happens if I try to install the hello-world snap (with
  LVM in this example):

  root@ubuntu:~# snap install hello-world
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  I cannot reproduce the issue in Ubuntu 16.04.

  I couldn't reproduce this issue by using the Ubuntu 14.04 cloud image
  which doesn't isolate /var on its own partition. I tried adding a
  secondary disk to that cloud image VM and create a dummy VG and LV,
  but couldn't reproduce the issue.

  Also could not reproduce using Ubuntu 14.04 (with LVM or not) but with
  only a / partition and swap.

  [Test Case]

  # Install Ubuntu 14.04 in KVM (I used the 14.04.4 server iso) and
  configure /, /var and swap on their own partitions (with LVM or not,
  the issue happens in both situations).

  root@ubuntu:~# lvs
  LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
  rootvol vg00 -wi-ao--- 3.72g
  swap vg00 -wi-ao--- 3.72g
  varvol vg00 -wi-ao--- 3.72g

  root@ubuntu:~# df -h
  Filesystem Size Used Avail Use% Mounted on
  udev 484M 4.0K 484M 1% /dev
  tmpfs 100M 988K 99M 1% /run
  /dev/dm-0 3.7G 1.7G 1.8G 49% /
  none 4.0K 0 4.0K 0% /sys/fs/cgroup
  none 5.0M 0 5.0M 0% /run/lock
  none 497M 0 497M 0% /run/shm
  none 100M 0 100M 0% /run/user
  /dev/mapper/vg00-varvol 3.7G 716M 2.8G 21% /var

  # Upgrade system, install snapd and reboot

  root@ubuntu:~# apt update
  root@ubuntu:~# apt upgrade -y
  root@ubuntu:~# apt install -y snapd
  root@ubuntu:~# reboot

  # After reboot, check kernel version and try to install the canonical-
  livepatch snap:

  root@ubuntu:~# uname -a
  Linux ubuntu 4.4.0-96-generic #119~14.04.1-Ubuntu SMP Wed Sep 13 08:40:48 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

  root@ubuntu:~# snap list
  No snaps are installed yet. Try "snap install hello-world".

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  [Regression Potential]

  - Unit file has been added to systemd, could cause an error in some units 
initialization. Since systemd is not used as "init" system for Trusty, this is 
minor regression.
  - Could break all systemd units depending (After=/Wants=) 
systemd-fsck@.service but they are already broken.

  ** A "pre-SRU" test package provided in Tinoco's PPA has been also
  intensively tested with success, which bring even more confidence for
  this change. Note that the same level/quality of testing will be
  performed one more time when the 

[Touch-packages] [Bug 1718966] Re: Cannot install snaps on Ubuntu 14.04 with /var on its own partition

[Rafael David Tinoco]

Verifying...

http://pastebin.ubuntu.com/25753116/

After using -proposed version:

http://paste.ubuntu.com/25753146/

Considering this fixed. Verified!

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

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

Title:
  Cannot install snaps on Ubuntu 14.04 with /var on its own partition

Status in snapd:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in systemd source package in Trusty:
  Fix Committed

Bug description:
  [Impact]

  Installing snaps is not possible on Ubuntu 14.04 when having /var on
  its own partition, whether its LVM or not.

  The issue is with the core snap being unable to mount:

  The error with /var isolated and using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  The error with /var isolated but without using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service
 failed to load: No such file or directory. See system logs and 'systemctl 
status 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service'
 for details.
  )

  The same error happens if I try to install the hello-world snap (with
  LVM in this example):

  root@ubuntu:~# snap install hello-world
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  I cannot reproduce the issue in Ubuntu 16.04.

  I couldn't reproduce this issue by using the Ubuntu 14.04 cloud image
  which doesn't isolate /var on its own partition. I tried adding a
  secondary disk to that cloud image VM and create a dummy VG and LV,
  but couldn't reproduce the issue.

  Also could not reproduce using Ubuntu 14.04 (with LVM or not) but with
  only a / partition and swap.

  [Test Case]

  # Install Ubuntu 14.04 in KVM (I used the 14.04.4 server iso) and
  configure /, /var and swap on their own partitions (with LVM or not,
  the issue happens in both situations).

  root@ubuntu:~# lvs
  LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
  rootvol vg00 -wi-ao--- 3.72g
  swap vg00 -wi-ao--- 3.72g
  varvol vg00 -wi-ao--- 3.72g

  root@ubuntu:~# df -h
  Filesystem Size Used Avail Use% Mounted on
  udev 484M 4.0K 484M 1% /dev
  tmpfs 100M 988K 99M 1% /run
  /dev/dm-0 3.7G 1.7G 1.8G 49% /
  none 4.0K 0 4.0K 0% /sys/fs/cgroup
  none 5.0M 0 5.0M 0% /run/lock
  none 497M 0 497M 0% /run/shm
  none 100M 0 100M 0% /run/user
  /dev/mapper/vg00-varvol 3.7G 716M 2.8G 21% /var

  # Upgrade system, install snapd and reboot

  root@ubuntu:~# apt update
  root@ubuntu:~# apt upgrade -y
  root@ubuntu:~# apt install -y snapd
  root@ubuntu:~# reboot

  # After reboot, check kernel version and try to install the canonical-
  livepatch snap:

  root@ubuntu:~# uname -a
  Linux ubuntu 4.4.0-96-generic #119~14.04.1-Ubuntu SMP Wed Sep 13 08:40:48 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

  root@ubuntu:~# snap list
  No snaps are installed yet. Try "snap install hello-world".

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  [Regression Potential]

  - Unit file has been added to systemd, could cause an error in some units 
initialization. Since systemd is not used as "init" system for Trusty, this is 
minor regression.
  - Could break all systemd units depending (After=/Wants=) 
systemd-fsck@.service but they are already broken.

  ** A "pre-SRU" test package provided in Tinoco's PPA has been also
  intensively tested with success, which bring even more confidence for
  this change. Note that the same level/quality of testing will be
  performed one more time when the package will be found in 

[Touch-packages] [Bug 1718966] Re: Cannot install snaps on Ubuntu 14.04 with /var on its own partition

[Rafael David Tinoco]

** Changed in: systemd (Ubuntu Trusty)
 Assignee: (unassigned) => Rafael David Tinoco (inaddy)

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

Title:
  Cannot install snaps on Ubuntu 14.04 with /var on its own partition

Status in snapd:
  Confirmed
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  Confirmed

Bug description:
  Installing snaps is not possible on Ubuntu 14.04 when having /var on
  its own partition, whether its LVM or not.

  The issue is with the core snap being unable to mount:

  The error with /var isolated and using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  The error with /var isolated but without using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service
 failed to load: No such file or directory. See system logs and 'systemctl 
status 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service'
 for details.
  )

  The same error happens if I try to install the hello-world snap (with
  LVM in this example):

  root@ubuntu:~# snap install hello-world
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  I cannot reproduce the issue in Ubuntu 16.04.

  I couldn't reproduce this issue by using the Ubuntu 14.04 cloud image
  which doesn't isolate /var on its own partition. I tried adding a
  secondary disk to that cloud image VM and create a dummy VG and LV,
  but couldn't reproduce the issue.

  Also could not reproduce using Ubuntu 14.04 (with LVM or not) but with
  only a / partition and swap.

  
  Steps to reproduce:
  ===

  # Install Ubuntu 14.04 in KVM (I used the 14.04.4 server iso) and
  configure /, /var and swap on their own partitions (with LVM or not,
  the issue happens in both situations).

  root@ubuntu:~# lvs
  LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
  rootvol vg00 -wi-ao--- 3.72g 
  swap vg00 -wi-ao--- 3.72g 
  varvol vg00 -wi-ao--- 3.72g 

  root@ubuntu:~# df -h
  Filesystem   Size  Used Avail Use% Mounted on
  udev 484M  4.0K  484M   1% /dev
  tmpfs100M  988K   99M   1% /run
  /dev/dm-03.7G  1.7G  1.8G  49% /
  none 4.0K 0  4.0K   0% /sys/fs/cgroup
  none 5.0M 0  5.0M   0% /run/lock
  none 497M 0  497M   0% /run/shm
  none 100M 0  100M   0% /run/user
  /dev/mapper/vg00-varvol  3.7G  716M  2.8G  21% /var

  
  # Upgrade system, install snapd and reboot

  root@ubuntu:~# apt update
  root@ubuntu:~# apt upgrade -y
  root@ubuntu:~# apt install -y snapd
  root@ubuntu:~# reboot

  
  # After reboot, check kernel version and try to install the 
canonical-livepatch snap:

  root@ubuntu:~# uname -a
  Linux ubuntu 4.4.0-96-generic #119~14.04.1-Ubuntu SMP Wed Sep 13 08:40:48 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux

  root@ubuntu:~# snap list
  No snaps are installed yet. Try "snap install hello-world".

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

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

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

[Touch-packages] [Bug 1718966] Re: Cannot install snaps on Ubuntu 14.04 with /var on its own partition

[Rafael David Tinoco]

Ok so in systemd-204, in TRUSTY, you will find the following logic to
create the mount units:

- manager_loop
  - process-event (WATCH_MOUNT)
- mount_fd_event
  - mount_load_proc_self_mountinfo
- mount_add_one (if load_extras == true)
  - mount_add_extras
- mount_add_device_links

The last function will add: device/mount/socket/swap/path/requires/...
dependencies in the mount unit to be created. The first one "device" is
handled by "mount_add_device_links" and, according to logic:

if (p->passno > 0 &&
UNIT(m)->manager->running_as == SYSTEMD_SYSTEM) {
char *name;
Unit *fsck;
/* Let's add in the fsck service */

/* aka SPECIAL_FSCK_SERVICE */
name = unit_name_from_path_instance("systemd-fsck", p->what, 
".service");
if (!name)
return -ENOMEM;

If filesystem option passno is 0, it won't have the systemd-fsck unit as
a requirement, meaning that no error will be given, allowing the mount
unit, created by snappy, to work.



Check it out:

1)

## /etc/fstab

LABEL=LVROOT / ext4 errors=remount-ro 0 1
LABEL=LVVAR /var ext4 defaults 0 1
LABEL=TESTE /teste ext4 defaults 0 1

$ sudo snap install hello-world

error: cannot perform the following tasks:
- Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-disk-by\x2dlabel-LVVAR.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-disk-by\x2dlabel-LVVAR.service' for details.

2)

## /etc/fstab

LABEL=LVROOT / ext4 errors=remount-ro 0 1
LABEL=LVVAR /var ext4 defaults 0 0
LABEL=TESTE /teste ext4 defaults 0 0

$ sudo snap install hello-world
hello-world 6.3 from 'canonical' installed



Now I'm checking why debian/rules in systemd-204 didn't include
fsck@.service files in the final .deb for "systemd" package. Possibly
this wasn't noticed because at the time systemd was running in Trusty,
it wasn't imagined that mount units would be managed by systemd (like
snappy is doing now). I'll check if adding the units for fsck (plus
having systemd-fsck binary, already there) is enough for the mount logic
to work.

For now, use the workaround above ^.

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

** Changed in: snapd
   Status: Confirmed => In Progress

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

Title:
  Cannot install snaps on Ubuntu 14.04 with /var on its own partition

Status in snapd:
  In Progress
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress

Bug description:
  Installing snaps is not possible on Ubuntu 14.04 when having /var on
  its own partition, whether its LVM or not.

  The issue is with the core snap being unable to mount:

  The error with /var isolated and using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  The error with /var isolated but without using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service
 failed to load: No such file or directory. See system logs and 'systemctl 
status 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service'
 for details.
  )

  The same error happens if I try to install the hello-world snap (with
  LVM in this example):

  root@ubuntu:~# snap install hello-world
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  I cannot reproduce the issue in Ubuntu 16.04.

  I couldn't reproduce this issue by using the Ubuntu 14.04 cloud image
  which doesn't isolate /var on its own partition. I tried adding a
  secondary disk to that cloud image VM and create a dummy VG and LV,
  but couldn't reproduce the issue.

  Also could not reproduce using Ubuntu 14.04 (with LVM or not) but with
  only a / partition and swap.

  
  Steps to 

[Touch-packages] [Bug 1718966] Re: Cannot install snaps on Ubuntu 14.04 with /var on its own partition

[Rafael David Tinoco]

Okay, so another quick workaround, now keeping the fsck enabled for the
volumes:

Create a file called "/lib/systemd/upstart/systemd-fsck@.service" with:


#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=File System Check on %f
Documentation=man:systemd-fsck@.service(8)
DefaultDependencies=no
BindsTo=%i.device
After=systemd-readahead-collect.service systemd-readahead-replay.service 
%i.device
Before=shutdown.target

[Service]
Type=oneshot
RemainAfterExit=no
ExecStart=/lib/systemd/systemd-fsck %f
StandardOutput=journal+console
TimeoutSec=0


and then do:

$ sudo ln -s /lib/systemd/upstart/systemd-fsck@.service 
/lib/systemd/upstart/multi-user.target.wants/systemd-fsck@.service
$ sudo systemctl daemon-reload

This will allow the mount units to work using systemd in Trusty:

inaddy@trustylivepatch:~$ sudo systemctl start teste.mount
inaddy@trustylivepatch:~$ df -kh | grep teste
/dev/sdb2   976M  1.3M  908M   1% /teste
inaddy@trustylivepatch:~$ sudo systemctl stop teste.mount
inaddy@trustylivepatch:~$ cat /etc/fstab| grep teste
LABEL=TESTE /teste ext4 defaults 0 1

While still having fsck enabled in /etc/fstab.

I'll provide a SRU patch for systemd in Trusty and it shall solve this
issue.

** Changed in: snapd
   Status: In Progress => Invalid

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

Title:
  Cannot install snaps on Ubuntu 14.04 with /var on its own partition

Status in snapd:
  Invalid
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress

Bug description:
  Installing snaps is not possible on Ubuntu 14.04 when having /var on
  its own partition, whether its LVM or not.

  The issue is with the core snap being unable to mount:

  The error with /var isolated and using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  The error with /var isolated but without using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service
 failed to load: No such file or directory. See system logs and 'systemctl 
status 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service'
 for details.
  )

  The same error happens if I try to install the hello-world snap (with
  LVM in this example):

  root@ubuntu:~# snap install hello-world
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )

  I cannot reproduce the issue in Ubuntu 16.04.

  I couldn't reproduce this issue by using the Ubuntu 14.04 cloud image
  which doesn't isolate /var on its own partition. I tried adding a
  secondary disk to that cloud image VM and create a dummy VG and LV,
  but couldn't reproduce the issue.

  Also could not reproduce using Ubuntu 14.04 (with LVM or not) but with
  only a / partition and swap.

  
  Steps to reproduce:
  ===

  # Install Ubuntu 14.04 in KVM (I used the 14.04.4 server iso) and
  configure /, /var and swap on their own partitions (with LVM or not,
  the issue happens in both situations).

  root@ubuntu:~# lvs
  LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
  rootvol vg00 -wi-ao--- 3.72g 
  swap vg00 -wi-ao--- 3.72g 
  varvol vg00 -wi-ao--- 3.72g 

  root@ubuntu:~# df -h
  Filesystem   Size  Used Avail Use% Mounted on
  udev 484M  4.0K  484M   1% /dev
  tmpfs100M  988K   99M   1% /run
  /dev/dm-03.7G  1.7G  1.8G  49% /
  none 4.0K 0  4.0K   0% /sys/fs/cgroup
  none 5.0M 0  5.0M   0% /run/lock
  none 497M 0  497M   0% /run/shm
  none 100M 0  100M   0% /run/user
  /dev/mapper/vg00-varvol  3.7G  716M  2.8G  21% /var

  
  

[Touch-packages] [Bug 1718966] Re: Cannot install snaps on Ubuntu 14.04 with /var on its own partition

[Rafael David Tinoco]

** Description changed:

  [Impact]
  
  Installing snaps is not possible on Ubuntu 14.04 when having /var on its
  own partition, whether its LVM or not.
  
  The issue is with the core snap being unable to mount:
  
  The error with /var isolated and using LVM:
  
  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )
  
  The error with /var isolated but without using LVM:
  
  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service
 failed to load: No such file or directory. See system logs and 'systemctl 
status 
systemd-fsck@dev-disk-by\x2duuid-7383abd2\x2d019c\x2d46c2\x2d8b36\x2d34633cc8f3ca.service'
 for details.
  )
  
  The same error happens if I try to install the hello-world snap (with
  LVM in this example):
  
  root@ubuntu:~# snap install hello-world
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )
  
  I cannot reproduce the issue in Ubuntu 16.04.
  
  I couldn't reproduce this issue by using the Ubuntu 14.04 cloud image
  which doesn't isolate /var on its own partition. I tried adding a
  secondary disk to that cloud image VM and create a dummy VG and LV, but
  couldn't reproduce the issue.
  
  Also could not reproduce using Ubuntu 14.04 (with LVM or not) but with
  only a / partition and swap.
  
  [Test Case]
  
  # Install Ubuntu 14.04 in KVM (I used the 14.04.4 server iso) and
  configure /, /var and swap on their own partitions (with LVM or not, the
  issue happens in both situations).
  
  root@ubuntu:~# lvs
  LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert
  rootvol vg00 -wi-ao--- 3.72g
  swap vg00 -wi-ao--- 3.72g
  varvol vg00 -wi-ao--- 3.72g
  
  root@ubuntu:~# df -h
  Filesystem Size Used Avail Use% Mounted on
  udev 484M 4.0K 484M 1% /dev
  tmpfs 100M 988K 99M 1% /run
  /dev/dm-0 3.7G 1.7G 1.8G 49% /
  none 4.0K 0 4.0K 0% /sys/fs/cgroup
  none 5.0M 0 5.0M 0% /run/lock
  none 497M 0 497M 0% /run/shm
  none 100M 0 100M 0% /run/user
  /dev/mapper/vg00-varvol 3.7G 716M 2.8G 21% /var
  
  # Upgrade system, install snapd and reboot
  
  root@ubuntu:~# apt update
  root@ubuntu:~# apt upgrade -y
  root@ubuntu:~# apt install -y snapd
  root@ubuntu:~# reboot
  
  # After reboot, check kernel version and try to install the canonical-
  livepatch snap:
  
  root@ubuntu:~# uname -a
  Linux ubuntu 4.4.0-96-generic #119~14.04.1-Ubuntu SMP Wed Sep 13 08:40:48 UTC 
2017 x86_64 x86_64 x86_64 GNU/Linux
  
  root@ubuntu:~# snap list
  No snaps are installed yet. Try "snap install hello-world".
  
  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the following tasks:
  - Mount snap "core" (2898) ([start snap-core-2898.mount] failed with exit 
status 6: Failed to issue method call: Unit 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service failed to load: No such file or 
directory. See system logs and 'systemctl status 
systemd-fsck@dev-mapper-vg00\x2dvarvol.service' for details.
  )
  
  [Regression Potential]
  
+ - Unit file has been added to systemd, could cause an error in some units 
initialization. Since systemd is not used as "init" system for Trusty, this is 
minor regression.
+ - Could break all systemd units depending (After=/Wants=) 
systemd-fsck@.service but they are already broken.
  
  [Other Info]
  
  [Original Description]
  
  Installing snaps is not possible on Ubuntu 14.04 when having /var on its
  own partition, whether its LVM or not.

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

Title:
  Cannot install snaps on Ubuntu 14.04 with /var on its own partition

Status in snapd:
  Invalid
Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Trusty:
  In Progress

Bug description:
  [Impact]

  Installing snaps is not possible on Ubuntu 14.04 when having /var on
  its own partition, whether its LVM or not.

  The issue is with the core snap being unable to mount:

  The error with /var isolated and using LVM:

  root@ubuntu:~# snap install canonical-livepatch
  error: cannot perform the