You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Right now, when booting the ISO, one cannot use e.g. pointer Ignition configs, or reference remote resources in their Ignition configs if the system requires non-default network configuration. With the new coreos-installer iso kargs, it's possible to inject kernel arguments to set up networking, but (1) complex network setups may be difficult or impossible to express on the cmdline, and (2) we should encourage NM keyfiles over kargs in general because they're much easier to manage.
Desired Feature
Something like
$ coreos-installer iso nmconfigs <embed|show|remove>
This would add NM configs to a pre-allocated CPIO in the ISO, much like we do for the Ignition CPIO. These would then be picked up by coreos-copy-firstboot-network (which would learn to run in the live ISO path, see coreos/fedora-coreos-tracker#841), propagated to the real root of the live ISO, and optionally could be copied into the installed system using --copy-network. That way, you only have to define network configs once in the whole flow.
And to be symmetrical with PXE, we'd have:
$ coreos-installer pxe nmconfigs <wrap|unwrap>
Though clearly in the PXE case, one can also just use the kernel command-line (but again, network kargs are not great).
Other Information
This would also be prep for having a "coreos-installer iso uproot" command which would be able to convert a full live ISO into a minimal live ISO (where the only difference is the removal of the rootfs CPIO). I've been playing with this idea a bit in the background to see what it would entail. But the primary thing is that obviously the system will need the ability to fetch the rootfs remotely.
One of the end goals for this would be to replace the Assisted Installer's need to remaster their own minimal ISO. Though the feature is useful to a larger audience.
(Consider this a separate RFC from the original feature request here. They do not need to happen together. Will open a separate discussion at some point for that.)
The text was updated successfully, but these errors were encountered:
Feature Request
Right now, when booting the ISO, one cannot use e.g. pointer Ignition configs, or reference remote resources in their Ignition configs if the system requires non-default network configuration. With the new
coreos-installer iso kargs
, it's possible to inject kernel arguments to set up networking, but (1) complex network setups may be difficult or impossible to express on the cmdline, and (2) we should encourage NM keyfiles over kargs in general because they're much easier to manage.Desired Feature
Something like
This would add NM configs to a pre-allocated CPIO in the ISO, much like we do for the Ignition CPIO. These would then be picked up by
coreos-copy-firstboot-network
(which would learn to run in the live ISO path, see coreos/fedora-coreos-tracker#841), propagated to the real root of the live ISO, and optionally could be copied into the installed system using--copy-network
. That way, you only have to define network configs once in the whole flow.And to be symmetrical with PXE, we'd have:
Though clearly in the PXE case, one can also just use the kernel command-line (but again, network kargs are not great).
Other Information
This would also be prep for having a "
coreos-installer iso uproot
" command which would be able to convert a full live ISO into a minimal live ISO (where the only difference is the removal of the rootfs CPIO). I've been playing with this idea a bit in the background to see what it would entail. But the primary thing is that obviously the system will need the ability to fetch the rootfs remotely.One of the end goals for this would be to replace the Assisted Installer's need to remaster their own minimal ISO. Though the feature is useful to a larger audience.
(Consider this a separate RFC from the original feature request here. They do not need to happen together. Will open a separate discussion at some point for that.)
The text was updated successfully, but these errors were encountered: