Bug 1859897

This may be a limitation in RHCOS 4.5 about which parameters passed to dracut during the install are propagated to the real root.  BZ#1857532 seems to complain of a similar problem.

In RHCOS 4.6, we will have better support for complex network configurations.

Since a workaround was found (understandably, not a desirable one), going to set the priority as medium and target for 4.6

This bug has not been selected for work in the current sprint.

Hey Ahmed,

As Micah mentioned in comment 1, the networking transition between the initramfs and real root in 4.6 got overhauled for the better so this problem might be already solved. I have a few questions for you:

1. Do you mind trying your setup with a 4.6 image to see if it works now? You can use a simple ignition config based on spec 3 (ignition spec changed to spec 3 in 4.6). Something like this should work:

```
{
    "ignition": {
        "version": "3.1.0"
    },
    "passwd": {
        "users": [
            {
                "groups": [
                    "sudo"
                ],
                "name": "core",
                "sshAuthorizedKeys": [
                    "ssh-rsa AAAA..."
                ]
            }
        ]
    }
}
```

2. On the 4.5 system you are having trouble with, can you get into the system? If so can you tell me the contents of the files in the `/etc/sysconfig/network-scripts/` directory?

Hey Dusty,

I clarified this to the customer and he's okay with it as long as it'll be supported in a future release.

For #1, I disengaged from the customer and I have some limitation in reproducing a similar environment.

For #2, the problem occured when RHCOS fully boots, the network connectivity is completely lost. What happened was that when the system boots we got couple of ping responses. After that when the console is at the login prompt, the IPs didn't show up and the network connectivity to the node is lost.

We tried another round of deploying OCP with configuring VLANs only, and not using LACP bonds. This time RHCOS was installed from an ISO, and upon the first boot the network connectivity is lost (much like what happened with bonds). At this point we rebooted the node by hand, and on the second boot the network is configured properly with VLANs, and I was able to ssh into the system. However the bootstrap didn't progress properly, probably because the first boot wasn't carried out successfully.

I didn't have time to further troubleshoot while with the customer, but if I had the chance I would have boot the node in another run level, modify the `core` user's password and grant it the ability to login from the console, reboot the node and login to investigate.

Thanks Ahmed for the information.

There are several bugs related to VLANs and I think I'm going to try to get them all moved into the same bug (assuming they are the same root cause). Right now I'm focusing on https://bugzilla.redhat.como/show_bug.cgi?id=1857532#c4 to see if we can get more feedback. If those efforts seem promising I'll probably close this out as a duplicate.

Dusty

I'm going to close this and a few other bugs as a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1857532. Unless more information comes to light, I think that is the case.

*** This bug has been marked as a duplicate of bug 1857532 ***