-
Notifications
You must be signed in to change notification settings - Fork 158
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
05core: add coreos-network-initramfs-etc.service #1374
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,26 @@ | ||
[Unit] | ||
Description=CoreOS Enable Network Initramfs-Etc | ||
# All services which use ConditionFirstBoot=yes should use | ||
# Before=first-boot-complete.target, which is a target that | ||
# was introduced in https://github.com/systemd/systemd/issues/4511 | ||
# and hasn't propagated everywhere yet. Once the target propagates | ||
# everywhere, we can drop the systemd-machine-id-commit.service | ||
# from the Before= line. | ||
Before=first-boot-complete.target systemd-machine-id-commit.service | ||
Wants=first-boot-complete.target | ||
# If there are custom NM connection files, | ||
ConditionDirectoryNotEmpty=/etc/NetworkManager/system-connections/ | ||
# and they come from `--copy-network` or `iso network embed`, | ||
ConditionPathExists=/run/coreos/firstboot-network-src | ||
ConditionPathExists=/run/coreos/network-propagated | ||
# and it's the first boot, | ||
ConditionFirstBoot=true | ||
|
||
# then automatically turn on initramfs-etc tracking of the NM configs. | ||
[Service] | ||
Type=oneshot | ||
ExecStart=/usr/libexec/coreos-network-initramfs-etc | ||
RemainAfterExit=yes | ||
|
||
[Install] | ||
WantedBy=multi-user.target |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
#!/bin/bash | ||
set -euo pipefail | ||
|
||
# Would've been really nice to be able to use | ||
# `ConditionKernelCommandLine=rd.neednet=1` for this, but that doesn't work | ||
# because the current boot doesn't have it; the *next* boot will. | ||
|
||
karg() { | ||
local name="$1" value="${2:-}" | ||
local cmdline=( $(rpm-ostree kargs) ) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We paste this function all over the place, so it might be worth calling out that we're not reading |
||
for arg in "${cmdline[@]}"; do | ||
if [[ "${arg%%=*}" == "${name}" ]]; then | ||
value="${arg#*=}" | ||
fi | ||
done | ||
echo "${value}" | ||
} | ||
|
||
if [[ $(karg rd.neednet) == 1 ]]; then | ||
rpm-ostree ex initramfs-etc --track /etc/NetworkManager/system-connections | ||
fi | ||
Comment on lines
+19
to
+21
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I feel like where this gets ugly and we need to be a lot more careful about enabling it. For example, what if someone has Also I think Sorry I just have a lot of open questions right now. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I guess the 2nd question is taken care of by There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think the answer to the third question is "then they want networking in the initrd, and they'll get it". For the first question, if they didn't supply firstboot NM keyfiles, the unit conditions will ensure we'll never get here. If they did, and they specified There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Yeah, indeed. But worth noting that any network kargs will not have taken effect on first boot at least because our current stance is that firstboot NM keyfiles win. The only use case I can think of where they'd use both network kargs and NM keyfiles is if they want the same configuration between the initrd and the real root on first boot, but not on subsequent boots... which would be weird. I guess one example is they add a NIC after install and they want to e.g. make sure that it stays off in the initrd? Anyway, high-level, yes if the kargs describe a configuration for devices that overlap with the
Essentially, what this is proposing is setting a new default behaviour (which purposely isn't specific to Tang): if the system needs networking in the initramfs, and you specified NM keyfiles, then we assume that you want that configuration to apply on not just the first boot, but every boot. It seems like a reasonable assumption (and IMO less surprising than not doing it). You can disable this default by switching only to kargs, or disabling the service (at install time), or using Related to this, in the future I'd like to also add support to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It feels weird to require these. Does it matter where the files came from as long as they end up in
/etc/NetworkManager/system-connections/
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
AIUI: if they came from Ignition, then they weren't needed in the initrd during first boot, so they shouldn't be needed in the initrd in later boots. If they came from kargs, then the disposition of those kargs should govern: either they'll exist on every boot, or they won't and we shouldn't propagate their effects forward.
I guess the
network-propagated
condition is for the corner case where the user provided some NM configs, but they looked default-y so we didn't copy them forward? If so, let's mention that.