Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rd.neednet=1 should be a soft requirement #388

Closed
Tracked by #7
mudler opened this issue Jul 8, 2021 · 3 comments
Closed
Tracked by #7

rd.neednet=1 should be a soft requirement #388

mudler opened this issue Jul 8, 2021 · 3 comments
Labels
kind/enhancement New feature or request
Projects

Comments

@mudler
Copy link
Contributor

mudler commented Jul 8, 2021

Is your feature request related to a problem? Please describe.
Currently, if we fail to get an IP via DHCP during initramfs, we drop to the emergency shell. To boot up the system is sufficient to type "exit"

Describe the solution you'd like
The network error shouldn't prevent the full booting of the system, we use rd.neednet=1 by default as boot params which enables this behavior. The system might be configured also via cloud-init to set ip addresses, so we shouldn't assume we are always getting one (and we have network access). Ideally I would see a default option to be "permissive" but optionally that could be set in "enforced" (like SELinux, for e.g.)

Describe alternatives you've considered
Keep failing hardly. This might be a good idea for the Cloud, as without any IP assigned, we might not want to have workload to start.

Additional context

Screenshot from 2021-07-08 10-20-13
Screenshot from 2021-07-08 10-22-56

Relates to #7

@mudler mudler added the kind/enhancement New feature or request label Jul 8, 2021
@mudler mudler self-assigned this Jul 8, 2021
@mudler mudler mentioned this issue Jul 8, 2021
5 tasks
@mudler mudler added this to 💡 Untriaged in Releases Jul 8, 2021
@mudler mudler removed their assignment Jul 8, 2021
@davidcassany
Copy link
Contributor

davidcassany commented Jul 8, 2021

I did a quick search about this topic and it looks like it might not be simple to fix without making an explicit choice on the network management system. In 15.3 we have network-legacy and network-manager dracut modules, and in TW we have an extra network-wicked. 15.3 series default into network-legacy and TW defaults to network-wicked. I did a quick search and I am not sure we can find a solution that is not coupled to a specific dracut module.

@davidcassany
Copy link
Contributor

Just for the records the failed test in https://github.com/rancher-sandbox/cOS-toolkit/actions/runs/1026705261 looks like it could have failed due a not having eth0 properly configured.

@mudler mudler moved this from 💡 Untriaged to ❆ Icebox in Releases Oct 11, 2021
@mudler mudler moved this from ❆ Icebox to 💡 Untriaged in Releases Nov 22, 2021
@Itxaka
Copy link
Contributor

Itxaka commented Aug 1, 2022

we now dropped this on elemental....

@Itxaka Itxaka closed this as completed Aug 1, 2022
frelon pushed a commit to frelon/elemental-toolkit that referenced this issue May 12, 2023
* Fixes the state yaml upgrade

This commit makes sure the passive image data in state yaml after
upgrade is updated to the old active data besides the passive label
which should remain untouched.


Signed-off-by: David Cassany <dcassany@suse.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
kind/enhancement New feature or request
Projects
Archived in project
Releases
💡 Untriaged
Development

No branches or pull requests

3 participants