01bootetc: introduce module for updating dracut etc #792
Conversation
|
Can one of the admins verify this patch? |
|
@cgwalters this is the end result of the idea to support |
| #!/bin/sh | ||
| . /lib/dracut-lib.sh | ||
|
|
||
| bootetc=$(getarg bootetc=) |
There was a problem hiding this comment.
OK, so we require an explicit opt-in karg like bootetc=1; and you see us changing FCOS to pass that by default? Or it only gets injected when e.g. dm-multipath is in use?
There was a problem hiding this comment.
It's more like bootetc=LABEL=..... I envision this being an opt-in. We could use it for FCOS, but I'm particularly keen on not making that decision today.
| touch /run/bootetc.done | ||
|
|
||
| if [ -z "$DRACUT_SYSTEMD" ]; then | ||
| systemctl try-restart dracut-cmdline.service |
There was a problem hiding this comment.
This part is probably the most unfortunate. I don't know all of what's going on in dracut-cmdline.service but it'll need to be prepared to be killed at arbitrary points.
Can't we have this bit run Before=dracut-cmdline.service?
There was a problem hiding this comment.
Nope, I looked at the boot-path. dracut-cmdline.service is run before Udev. we need udev to find the boot device.
|
|
||
| if [ -z "$DRACUT_SYSTEMD" ]; then | ||
| systemctl try-restart dracut-cmdline.service | ||
| systemctl try-restart systemd-udev-trigger.service |
There was a problem hiding this comment.
Hm, why does udev need to be retriggered?
There was a problem hiding this comment.
probably so the device that contains the boot partition can be found?
There was a problem hiding this comment.
oh re-triggered.. not sure
|
At a high level, I think the original idea was just that we support e.g. |
|
I think the approach here has potential. A few questions/comments:
|
Well I was pushing back against using initramfs mutation for this because it conflicts with any approach to signing, it's mixing code and configuration. The initramfs is code that should be parsing configuration from e.g. the kernel cmdline. The problem with multipath is that its configuration is too big for the cmdline. |
Its a pretty-fast failure and its opt-in only. Since its run after
Sort of. I think they are orthogonal. Support in |
Multipath configuration can't be used on the commandline. The configuration must originate from This PR is a general solution for general Linux. And having been a support engineer, I would have killed for the features that this enables such as the ability to change the configuration in the initramfs without having to play the regeneration of the initramfs (because everyone loves the bind mount, chroot, regenerate, reboot game). Something else to consider: it was requested that this idea be put in Dracut. If this is too much for CoreOS, then we should carry the narrowly scoped module in our own trees for building CoreOS. |
Right, we also have the iSCSI case which is similar. But any dracut module that wants to use this shares all the bits of mounting /boot - the difference just comes in that the individual modules would cherry-pick their own config files; IOW: dm-multipath-pre.service iscsid-pre.service: etc. (Written as a systemd unit instead of the shell, but the same idea applies in both). I agree it's a good idea to find solutions that will apply to traditional systems too! And nothing about the "narrow" approach excludes that - IOW once that change landed at some point e.g. Anaconda could be changed for "traditional" Fedora systems to set up dm-multipath that way instead of regenerating the initrd. But..the motivation for doing that is a lot lower if one is always regenerating the initrd locally anyways. Or to rephrase this, either way something different is happening; CoreOS uses |
|
To ensure this is all xref'd; Lennart suggested using EFI variables (my followup) but it just doesn't work for us because e.g. AWS is BIOS only and we need a uniform mechanism (not to mention e.g. needs to work on s390x too etc.). |
|
Another angle on this code/configuration thing; as this stands today someone could write an |
That's why I didn't do a Given the strong distaste for this PR, I'll rework this. |
Well, we can see what the other drauct devs think too! |
|
xref to coreos/ignition-dracut#154 and the commend that inspired this PR coreos/ignition-dracut#154 (comment) for background |
|
I guess one other concern I have with having configs in If we constrain this to just solving the firstboot case, I think doing something similar to coreos/fedora-coreos-config#346 could make sense. (I.e. apply in initrd, propagate to real root, delete directory). Would that solve the multipath scenario? |
We need to find the multipath configuration on every boot. |
For an RHCOS in the scope of OCP, there is no easy mechanism to regenerate the initrd. The two-sources of truth concern, IMO, is mitigated by the fact that this is an opt-in (off-by-default) option. Turning it is explicitly stating you want to use the mechanism.
No. Not at all. If root is on a multipath, then it has to be enabled in the initramfs before root is mounted. If the root is mounted first, then the multipath is not activated. So you have to regenerate the initramfs. I didn't pursue using the MCO to trigger an initramfs regeneration because the MCO can't deliver payloads on a node level; multipath configuration can be/often-is a node-level configuration. If:
Then multipath, iSCSI and other complicated disk setups can't be supported by CoreOS. |
|
I fear that we might wear our welcome here by debating CoreOS specific concerns here. @jlebon @cgwalters @dustymabe let's take the debate to coreos/fedora-coreos-tracker#464 And the Dracut Developers are more than welcome to come to our space. I'm inclined to close until a decision is made at the CoreOS level. If the idea wouldn't be merged into CoreOS's own codebase, why ask Dracut to consider it? |
|
I don't think this problem domain is solely CoreOS specific - it applies to any "image based" system which wants to ship a server-side generated initramfs, right? And it's good if solutions we come up with can be adopted by other distributions using non-OSTree mechanisms. |
Agreed. And that's what I tried to do with this, and why I liked your suggestion to cargo-cult in
I suggested that we move the discussion because the scope of conversation had become one about OSTree needs. I had proposed the general solution and it quickly rabbit holed. I would be happy to consider discussing the best implementation for the feature within the scope of the generic Linux community for image-based workflows. CoreOS' needs were indeed the opening justification, but it has dominated the discussion. I'd rather we have our myopic discussions in our own space. To be clear -- your counter idea of targeted and per-module overrides makes sense, and there's merit to it. As does the merits of Jonathan's concerns about not having N sources of truth (although, having 18 ways to the same thing is a thing in Linux). The solution as proposed puts the power in the hands of the user by allowing for easy side-loading. The tension between the target path and this solution is really whether we want a side-loading functionality for users and to which degree. Not debating OSTree specific concerns. My position is that once we enable Multipath and iSCSI sideloads, someone else will want it for something else. In looking at the full-scope of the problem domain, I concluded that a general side-loading mechanism is pro-user and gives a good balance between image base workloads against user tensions. My argument is that reducing friction for users will increase adoptions while image masters do their arcane and byzantine dark magic. The typical image based workloads would normally require re-mastering the image or using kargs; this solves those pain points. If adopted the wider Dracut world outside of Fedora/Red Hat and CoreOS could use that and its why I did the most generic method possible. I do think that we should continue the debate for CoreOS in the Fedora CoreOS. Trust me, had I submitted it to Fedora CoreOS or Ignition Dracut this would have looked very different. The general side loading of With that, let's continue the debate on the generic solution here. And then figure it how/if/what to use in our ivory towers. |
This provides support for updating '/etc/' in the initramfs using 'bootetc=<DEVICE>'. If the device has the path '/initrd-etc', then the tree is copied into the initramfs. The purpose of bootetc is to aide immutable operating systems like Fedora and Red Hat CoreOS that ship static initrds with a path for user-provided configuration. Example use cases include udev rules, iSCSI and multipath configuration, fips and Network Manager configurations.
|
@haraldh Can I bother you to weigh in here? There's a lot going on in the conversation, and without understanding how the Dracut Community feels, this idea is pretty much dead in my opinion. |
|
For the reference.. @darkmuggle and I chatted in private. I opted for either a IMHO, ideally it would be a signed config cpio, which could be checked by grub, so we would avoid any reload of systemd services. |
This provides support for updating '/etc/' in the initramfs using
'bootetc='. If the device has the path '/initrd-etc', then the
tree is copied into the initramfs.
The purpose of bootetc is to aide immutable operating systems like
Fedora and Red Hat CoreOS that ship static initrds with a path for
user-provided configuration. Example use cases include udev rules, iSCSI
and multipath configuration, fips and Network Manager configurations.