← Back to team overview

kernel-packages team mailing list archive

[Bug 1552788] Re: network lost after large number of reboots



Is the system fully updated since installing, or only selectively? I ask
this, because i would expect the interface name to have been renamed and
migrated to encf5f0 -> shorter prefix, and leading zeros stripped as of
systemd 228-4ubuntu2. Installation was done with  systemd just before
that one. Just a curious note, not assuming it will actually fix this.

The fact that link state is down, and there is no ipv6 address
configured is disturbing.

Three units did fail:
  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
* console-setup.service        loaded failed failed Set console keymap
* multipath-tools-boot.service loaded failed failed LSB: early multipath boot script
* networking.service           loaded failed failed Raise network interfaces

Fist one is mostly harmless, and should be fixed in latest console-setup.
Last one is disturbing.

And second one:
Is multipath expected to be setup on the system? There are errors from parsing the config files:
"Feb 24 08:03:28 | error parsing config file"



You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.

  network lost after large number of reboots

Status in linux package in Ubuntu:

Bug description:
  ---Problem Description---
  network lost after large number of reboots (>500)
  Contact Information = pschmidt@xxxxxxxxxx 
  ---uname output---
  Linux s8330025 4.4.0-2-generic #16-Ubuntu SMP Thu Jan 28 15:44:18 UTC 2016 s390x s390x s390x GNU/Linux
  Machine Type = s390 z/VM Guest 
  ---Steps to Reproduce---
   reboot z/VM guest several times >500. After a large number of reboots the network interfaces doesn't come up any more. The z/VM guest boots fine, unless the missing network. Impossible to bring up network again manually.


  Further debug shows that it is the "ip link set enccw0.0.f5f0 up" that
  is failing with "RTNETLINK answers: Operation not permitted".  Looking
  for further debug assistance in determining why the CAP_NET_ADMIN
  check for the root user running ip might be failing.

To manage notifications about this bug go to: