Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 1909213 - s390x systems lost link-local IPv6 addresses
Summary: s390x systems lost link-local IPv6 addresses
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: NetworkManager
Version: 8.4
Hardware: s390x
OS: Linux
Target Milestone: rc
: 8.0
Assignee: Thomas Haller
QA Contact: Desktop QE
Depends On:
TreeView+ depends on / blocked
Reported: 2020-12-18 16:13 UTC by Florian Weimer
Modified: 2021-02-15 09:37 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2021-02-15 09:37:37 UTC
Type: Bug
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1848943 1 None None None 2022-05-16 11:32:56 UTC
Red Hat Bugzilla 1908036 0 low VERIFIED openssl listens on IPv4 "any" socket only not on IPv6 2023-07-13 02:42:48 UTC
Red Hat Bugzilla 1908334 0 low VERIFIED gnutls-serv doesn't listen on IPvN loopback addresses if there are no IPvN external addresses configured 2023-07-12 08:39:44 UTC

Internal Links: 1908036 1908334

Description Florian Weimer 2020-12-18 16:13:29 UTC
It seems that when provisioning current Red Hat Enterprise Linux 8.4 versions in Beaker, the installed system does not have link-local IPv6 addresses anymore. This is a regression from Red Hat Enterprise Linux 8.3. This confuses various test suites because they (implicitly) assume that such addresses exist.

The symptoms are very similar to bug 1848943.

Comment 5 Thomas Haller 2021-02-02 10:12:51 UTC
(In reply to Florian Weimer from comment #0)
> The symptoms are very similar to bug 1848943.

yes, it's exactly the same issue as bug 1848943.

So, historically with dracut's network module, ip=none means to configure static addresses (if any).
The dracut module would however not reset "accept_ra" sysctl, so this mode also meant to do autoconf.

Now we use NetworkManager's dracut module.

Originally, we set either ipv6.method=link-local or ipv6.method=disabled, depending on whether static IPv6 addresses are configured.
That was the regression in bug 1848943, and the fix was to set ipv6.method=auto.

But that causes different problems, for example NetworkManager will wait up to 30 seconds to get an IPv6 address (unless it already got an IPv4 address earlier). That is undesirable (bug 1883958). Also, it seems wrong to configure ip=none and still have NetworkManager doing autoconf. So, we decided to break bug-compatibility and do [1].


This is the reason for this bug and for regressing bug 1848943. The proposed solution how to handle this with 8.4 was to document it in the release notes. This is tracked by bug 1883958.

Yes, it's a change in behavior and it's painful. If you think this must not be done, then please discuss.

What makes this especially painful is that ipv6.method=disabled in NetworkManager means to set /proc/sys/net/ipv6/conf/$IFNAME/disable_ipv6. That means, if you later run your scripts to setup the interface, you would have to enable it first -- which may not be obvious.

Comment 10 Thomas Haller 2021-02-05 09:55:54 UTC
Thanks Florian.

I was asking, because the command line in comment 1 does not have ip=...:none, so I was confused whether this is the same issue.

But the latest run (comment 9), under "Installation" it seems to have command line 

>  DASD=120,121,122,123 MACADDR=02:DE:BD:BE:EF:83 RUNKS=1 ks= ksdevice=bootif nameserver= netbootloader= ramdisk_size=40000 rd.znet=qeth,0.0.8000,0.0.8001,0.0.8002,layer2=1,portname=z-131,portno=0 ro

But when I then look at dmesg logfile, it says:

[    0.241539] Kernel command line: root=/dev/mapper/rhel_ibm--z--131-root crashkernel=auto rd.dasd=0.0.0120 rd.dasd=0.0.0121 rd.dasd=0.0.0122 rd.dasd=0.0.0123 rd.znet=qeth,0.0.8000,0.0.8001,0.0.8002,layer2=1,portname=z-131,portno=0 BOOT_IMAGE=0

With this configuration, I don't think that NetworkManager should do any network setup in initrd.

Could you install my ssh-key on that machine? "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGO5ve3AN8ynbd6/0DfG0Vm9mVxBKvO0oVERpkqj+sfO thaller". Or just share the password... Or should I somehow be able to see that in beaker? Where?

Comment 11 Florian Weimer 2021-02-05 10:02:41 UTC
Thomas, I've added your key.

The root password is the default one, shown under User Preferences in Beaker.

Thanks for investigating this issue.

Comment 12 Thomas Haller 2021-02-05 11:35:48 UTC
autopsy report:

the machine is currently running. The interface has disable_ipv6=1, as there is a profile active with ipv6.method=disabled.

That profile is stored in ifcfg format:

# cat /etc/sysconfig/network-scripts/ifcfg-enc8000
OPTIONS="layer2=1 portno=0"

also, the kernel command line is

  Kernel command line: root=/dev/mapper/rhel_ibm--z--131-root crashkernel=auto rd.dasd=0.0.0120 rd.dasd=0.0.0121 rd.dasd=0.0.0122 rd.dasd=0.0.0123 rd.znet=qeth,0.0.8000,0.0.8001,0.0.8002,layer2=1,portname=z-131,portno=0 BOOT_IMAGE=0

and (of course), NetworkManager was not running in initrd.

So, I think what happend is that during installation NetworkManager was running in initrd, and with ip=...:none it created a profile in /run with ipv6.method=disabled. Then, Anaconda modified that profile and persisted it to disk -- so that the only profile on the installed system ends up IPv6 disabled too.

@bgalvani, WDYT?

Comment 13 Beniamino Galvani 2021-02-05 12:49:41 UTC
Yes, that matches what I described here:

Comment 14 Thomas Haller 2021-02-05 13:01:36 UTC
(In reply to Beniamino Galvani from comment #13)
> Yes, that matches what I described here:


Then I think this works as expected...

- I guess, it makes sense that anaconda copies the profile from the installation over to the installed system (whatever it is).

- I guess, it also makes sense that we now treat ip=...:none as IPv6 disabled. It's unfortunate change in behavior, but having IPv6 enable also seems wrong on such a system.

The fix would be to update the kernel command line during boot. Or to modify (and reactivate) the profile on the running system.

Does that sound acceptable? bug 1883958 is tracking this and we will to document this change in behavior in the 8.4 documentation.
The alternative is to revert the patch again (and instead WONTFIX bug 1883958 in rhel-8).

Comment 15 Florian Weimer 2021-02-05 13:25:11 UTC
I *suspect* the change in behavior disproportionately impacts Red Hat due to the Beaker provisioning system we use. Most customers are likely less impacted. Since this is down to installer behavior, in-place upgrades are not affected.

If that is actually true, changing behavior in 8.4 and documenting it should be acceptable.

But I think we still need to adjust our Beaker provisioning process to restore the old behavior (see the internal thread referenced in comment 7).

Comment 17 Antonio Cardace 2021-02-15 09:37:37 UTC
Closing as this is a result of a breaking change in NM that will be documented in the RHEL 8.4 release.

Note You need to log in before you can comment on or make changes to this bug.