-
Notifications
You must be signed in to change notification settings - Fork 198
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
kernel-install wrap should include any dracut arguments being set in the manifest. #3799
Comments
Moving this comment here:
So this is an interesting issue. Today on the host/client side, we have access to the ostree commit object directly - everything works using that as a base. But here in the container flow, we would need to load the commit object, and...that doesn't yet have a precedent. It would make total sense to do so - we have the commit object in /ostree/repo/objects/00/abcde.commit etc, but actually as far as I know we don't know which commit we're using - that's in the container image metadata. We could read /usr/share/rpm-ostree/treefile.json but so far we also haven't been processing that client side. This gets into #2326 I would lean actually that we should instead of having initramfs-args we should have from the start been writing config files into Another way to say this is: dracut already has a declarative way to specify its configuration via config files - and crucially that same mechanism should work the same in |
Hmm, independent of this, I think it might be worth adding a ref like
This sounds reasonable to me, and makes a lot of sense long-term. Maybe we should then deprecate Short-term though, WDYT on just continuing to read from the commit metadata? I don't think we're talking about a lot of code. (Though we'd have to solve the ref issue mentioned above, which I think would be good to do regardless.) |
See coreos/rpm-ostree#3799 This way when we run dracut in a container build, we naturally pick up the same config we used for server side builds.
Long term can be now 😄 - PR in coreos/fedora-coreos-config#1828
Yeah, no urgency to remove it, but indeed we should deprecate.
I think I'd vote for an API to "fetch me the single commit object in a repo" but that said...
Not using |
Because other potential users of CoreOS layering (or maybe I should just say "layering"? not sure how much we care about such users right now, but the tech is pretty CoreOS-agnostic) outside FCOS could equally hit this. :) |
For sure, though there aren't many of these things. It looks like there is no usage of
There is in fedora-iot/ostree but that's something equally easily fixed. |
I agree with moving now to |
Users should use `/etc/dracut.conf.d` instead. This option does not work when regenerating the initramfs in the container flow. We'll want to keep supporting it internally for a while in the upgrade code, until all known composers have moved away from it, and reasonably enough time for client systems to get the resulting updated trees. See discussions in coreos#3799.
Opened #3834. |
Users should use `/etc/dracut.conf.d` instead. This option does not work when regenerating the initramfs in the container flow. We'll want to keep supporting it internally for a while in the upgrade code, until all known composers have moved away from it, and reasonably enough time for client systems to get the resulting updated trees. See discussions in coreos#3799.
See coreos/rpm-ostree#3799 This way when we run dracut in a container build, we naturally pick up the same config we used for server side builds.
Users should use `/etc/dracut.conf.d` instead. This option does not work when regenerating the initramfs in the container flow. We'll want to keep supporting it internally for a while in the upgrade code, until all known composers have moved away from it, and reasonably enough time for client systems to get the resulting updated trees. See discussions in coreos#3799.
See coreos/rpm-ostree#3799 This way when we run dracut in a container build, we naturally pick up the same config we used for server side builds.
See coreos/rpm-ostree#3799 This way when we run dracut in a container build, we naturally pick up the same config we used for server side builds.
See coreos/rpm-ostree#3799 This way when we run dracut in a container build, we naturally pick up the same config we used for server side builds.
Opening this issue based on the discussion on #3364 #3689 (comment)
We want to support any dracut arguments being specified in the manifest/tree file when running kernel-install even when wrapped.
The text was updated successfully, but these errors were encountered: