Bug#747931: network-manager: very many IPV6 addresses on eth0

[Gunnar Thorburn]

Package: network-manager
Version: 0.9.4.0-10
Severity: normal
Tags: ipv6

Dear Maintainer,

These lines appear in /var/log/syslog every 5 min
May 12 07:52:11 sleipnir NetworkManager[6719]: info Policy set
'Wired connection 1' (eth0) as default for IPv4 routing and DNS.
May 12 07:52:11 sleipnir NetworkManager[6719]: info Policy set
'Wired connection 1' (eth0) as default for IPv6 routing and DNS.

When it happens, eth0 gets another IPV6 address, for example:
eth0  Link encap:Ethernet  HWaddr 00:0a:95:66:9c:38
  inet addr:192.168.8.14  Bcast:192.168.8.255  Mask:255.255.255.0
  inet6 addr: 2002::61ef:1:c20:268e:2d67:67a8/64 Scope:Global
  inet6 addr: 2002::61ef:1:188b:efac:7164:7dd8/64 Scope:Global
  inet6 addr: 2002::61ef:1:569:ac30:a77e:7b90/64 Scope:Global
  inet6 addr: 2002::61ef:1:503b:ffd9:1adc:c27c/64 Scope:Global
  inet6 addr: 2002::61ef:1:20a:95ff:fe66:9c38/64 Scope:Global
  inet6 addr: fe80::20a:95ff:fe66:9c38/64 Scope:Link
  inet6 addr: 2002::61ef:1:5441:2c23:a00b:cdd8/64 Scope:Global
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:24328 errors:0 dropped:0 overruns:0 frame:0
  TX packets:20851 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:3793711 (3.6 MiB)  TX bytes:5166528 (4.9 MiB)
  Interrupt:41 Base address:0x4800

This system was installed a few weeks ago. I believe I have made no
network configuration whatsoever -
just relying on standrad DHCP for IPv4 and Autoconfigure for IPv6.
I have one other Debain 7.5 system (an armv5tel system, not a PowerPC)
on the network, without this problem.
I have a very simple 6to4-configured OpenWRT router that advertises
the IPV6 network. The clients autoconfigure.
I also have several other computers with different operating systems
(Xubuntu, Mac OS X, Windows 7) on the
network - none of them have problems with several IPV6 addresses.

I noticed this problem because the avahi-deamon consumed 99% cpu when
I had almost 200 IPv6 addresses:
/var/log/syslog:
  (almost 200 lines like the next line)
May 11 07:44:28 sleipnir avahi-daemon[2350]: Withdrawing address
record for 2002::61ef:1:90d1:46d6:3b17:5f0a on eth0.
  (then)
May 11 07:44:28 sleipnir rsyslogd-2177: imuxsock begins to drop
messages from pid 2350 due to rate-limiting
May 11 07:44:45 sleipnir NetworkManager[2174]: warn error monitoring
device for netlink events: No buffer space available
May 11 07:44:45 sleipnir minissdpd[3915]: recvmsg(s, hdr, 0): No
buffer space available

I understand I may be better off without the avahi-daemon, but
switching it off does not fix the problem.
Restarting Network Manager brings me down to TWO IPV6-addresses (which
is one too much, as I understand it):
root@sleipnir:~# service network-manager restart ; /sbin/ifconfig
[ ok ] Stopping network connection manager: NetworkManager.
[ ok ] Starting network connection manager: NetworkManager.
eth0  Link encap:Ethernet  HWaddr 00:0a:95:66:9c:38
  inet addr:192.168.8.14  Bcast:192.168.8.255  Mask:255.255.255.0
  inet6 addr: 2002::61ef:1:20a:95ff:fe66:9c38/64 Scope:Global
  inet6 addr: fe80::20a:95ff:fe66:9c38/64 Scope:Link
  inet6 addr: 2002::61ef:1:8431:f293:326a:4e5/64 Scope:Global
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:35676 errors:0 dropped:0 overruns:0 frame:0
  TX packets:28823 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:5006172 (4.7 MiB)  TX bytes:6793477 (6.4 MiB)
  Interrupt:41 Base address:0x4800

According to syslog the problem appeared for the first time on 2014-05-09.
According to /etc/apt/history.log the system had not been updated
since 2014-05-01.
I updated it as soon as I found the problem, but with no success.
I belive the problem with TWO addresses has been present since I
installed the system. At that time
I just found it peculiar. But getting more and more addresses with
time is new since May 9.

This is an Apple PowerBook. The wireless network (eth1) is disabled.
The computer is on 24/7, acting as a test webserver.

Workaround: add to /etc/crontab
59 ** * *   rootservice network-manager restart

Restarting the computer also takes me down to two addresses, but does
not solve the problem.

Below is standard reportbug output, run as root, otherwise I got
permission error with:
/etc/polkit-1/localauthority/10-vendor.d/org.freedesktop.NetworkManager.pkla

I find this all strange enough to file a bug report.

Thank you all for making a fantastic job with Debian!

  Regards
  Gunnar

-- System Information:
Debian Release: 7.5
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: powerpc (ppc)

Kernel: Linux 3.2.0-4-powerpc
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to 

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Gunnar Thorburn]

Package: flash-kernel
Version: 3.79
Severity: critical
Justification: breaks the whole system

Dear Maintainer,

I have been running Debian on a QNAP TS109 for many years.
I successfully upgraded from Squeeze to Wheezy in 2013 and to Jessie in 2015.

As I now upgrade to Stretch (basically following Debian Upgrade Guide, it
is a very simple system) I now get:

== from apt-get dist-upgrade ==
update-initramfs: Generating /boot/initrd.img-4.9.0-5-marvell
flash-kernel: installing version 4.9.0-5-marvell

The initial ramdisk is too large. This is often due to the unnecessary inclusion
of all kernel modules in the image. To fix this set MODULES=dep in one or both
/etc/initramfs-tools/conf.d/driver-policy (if it exists) and
/etc/initramfs-tools/initramfs.conf and then run 'update-initramfs -u
-k 4.9.0-5-marvell'

Not enough space for initrd in MTD 'RootFS1' (need 4210887 but is
actually 4194304).
run-parts: /etc/initramfs/post-update.d//flash-kernel exited with return code 1
dpkg: error processing package initramfs-tools (--configure):
 subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
 initramfs-tools
E: Sub-process /usr/bin/dpkg returned an error code (1)
== end of output

That was (obviously) after
 - editing /etc/apt/sources.list (changing jessie to stretch)
 - apt-get update
 - apt-get upgrade

I am completely aware how old and obsolete this QNAP TS109 is.
It would make complete sense to me if it was not supported anymore.
And I would completely understand if you dont want to fix this problem.

But given that TS-109 appears supported
  http://www.cyrius.com/debian/orion/qnap/ts-109/install/
and with no major issues
  http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
I would not expect this problem well into the upgrade.

To other users, it would be helpful to advice them not to upgrade to Stretch.

I guess my system would reboot if I try (but I have not tried)
I guess Debain 9.3 can run with Linux 3.16.0-5-orion5x from Debian 8, but
to me (I have used Debian for 20 years) the system seems to be in a rather
bad state. (if it fails to boot a serial cable for direct UBOOT is necessary)

I have not tried editing
  /etc/initramfs-tools/initramfs.conf

I suppose i could try to change MODULES=most to MODULES=dep.

However, if I break the system completely it will be much harder for me
to give you any more useful information.


  Best Regards
  Gunnar Thorburn


-- System Information:
Debian Release: 9.3
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: armel (armv5tel)

Kernel: Linux 3.16.0-5-orion5x
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages flash-kernel depends on:
ii  debconf [debconf-2.0]  1.5.61
ii  devio  1.2-1.2+b1
ih  initramfs-tools0.130
ii  linux-base 4.5
ii  mtd-utils  1:2.0.0-1
ii  ucf3.0036

Versions of packages flash-kernel recommends:
ii  u-boot-tools  2016.11+dfsg1-4

flash-kernel suggests no packages.

-- debconf information:
  flash-kernel/linux_cmdline: quiet

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Gunnar Thorburn]

Hi,

Creating this file with COMPRESS=xz worked fine
/etc/initramfs-tools/conf.d/compress

Obviously, with xz there is plenty of space left. There was a little
warning though (see below).

Generating kernel u-boot image... done.
Flashing kernel (using 2050440/2097152 bytes)... done.
Flashing initramfs (using 2870792/4194304 bytes)... done.
W: APT had planned for dpkg to do more than it reported back (0 vs 7).
   Affected packages: flash-kernel:armel initramfs-tools:armel


Yes, this system has been upgraded several time. I think your web page
even said that that is the correct/only way to do it.

I guess installing Stretch does COMPRESS=xz on its own.

Thank you so much. My problem is now solved. But perhaps xz could be
part of the upgrade process.

On 12 February 2018 at 22:05, Gunnar Thorburn <gunnar.thorb...@gmail.com> wrote:
> Hi Martin,
>
> I sincerely apologize for setting the wrong severity to the wrong
> package in the original report.
> (I thought the system could be in a state where it would not reboot at all)
>
> I am sorry to inform you that changing to MODULES=dep in
> initramfs.conf did not help.
> (driver-policy already had MODULES=dep).
>
> And no, I am not using LVM or RAID (just a standard ext2-partitions
> for /, /boot, /home/ and one for swap on a single SATA drive).
>
> The good thing is that the system reboots properly and seems to work
> fine with the old 3.16 kernel.
>
> There is no
> /etc/initramfs-tools/conf.d/compress
>
> I will try it out and get back.
>
> Thank you very much!
>
>
>
>
>
> On 12 February 2018 at 21:57, Martin Michlmayr <t...@cyrius.com> wrote:
>> Unfortunately my memory is quite bad.  I *thought* the current
>> installer configured XZ compression by default but it seems that's not
>> the case.  So the documentation on my web site is correct.
>>
>> * The installer sets MODULES=dep
>> * It has done so for a long time
>> * But you've upgraded from a really old release where this wasn't the case 
>> (I believe)
>>
>> * The installer doesn't configure XZ compression
>> * You don't need it for a normal installation
>> * If you want LVM or RAID, you have to use XZ, as per the hint at 
>> http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
>>
>> At least I *believe* that's the case.  I didn't investigate in detail.
>>
>> --
>> Martin Michlmayr
>> http://www.cyrius.com/

Bug#890262: flash-kernel: QNAP TS109, Not enough space for initrd in MTD

[Gunnar Thorburn]

Hi Martin,

I sincerely apologize for setting the wrong severity to the wrong
package in the original report.
(I thought the system could be in a state where it would not reboot at all)

I am sorry to inform you that changing to MODULES=dep in
initramfs.conf did not help.
(driver-policy already had MODULES=dep).

And no, I am not using LVM or RAID (just a standard ext2-partitions
for /, /boot, /home/ and one for swap on a single SATA drive).

The good thing is that the system reboots properly and seems to work
fine with the old 3.16 kernel.

There is no
/etc/initramfs-tools/conf.d/compress

I will try it out and get back.

Thank you very much!





On 12 February 2018 at 21:57, Martin Michlmayr  wrote:
> Unfortunately my memory is quite bad.  I *thought* the current
> installer configured XZ compression by default but it seems that's not
> the case.  So the documentation on my web site is correct.
>
> * The installer sets MODULES=dep
> * It has done so for a long time
> * But you've upgraded from a really old release where this wasn't the case (I 
> believe)
>
> * The installer doesn't configure XZ compression
> * You don't need it for a normal installation
> * If you want LVM or RAID, you have to use XZ, as per the hint at 
> http://www.cyrius.com/debian/orion/qnap/ts-109/known-issues/
>
> At least I *believe* that's the case.  I didn't investigate in detail.
>
> --
> Martin Michlmayr
> http://www.cyrius.com/