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.

Sign up for GitHub

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

Jump to bottom

Injecting configuration files after installation, before first boot #531

Open
jmpolom opened this issue May 15, 2024 · 5 comments · May be fixed by #267
Open

Injecting configuration files after installation, before first boot #531

jmpolom opened this issue May 15, 2024 · 5 comments · May be fixed by #267
Labels
area/config Related to configuration area/install Issues related to `bootc install` enhancement New feature or request triaged This looks like a valid issue

Comments

@jmpolom
Copy link

jmpolom commented May 15, 2024

How does one inject a configuration file post bootc install but before the first system boot? A customized /etc/fstab is a good example or perhaps some systemd mount units. With a non-ostree system when the installation chroot is setup this is a straightforward copy operation. bootc should document this process a bit better or provide a more convenient method as it will be a common need to drop some configuration files in place post install but before the system boots for the first time. Not everyone will want to adopt ignition to do these tasks.
@cgwalters
Copy link
Collaborator

bootc should document this process a bit better or provide a more convenient method

See #267 for a more convenient method. We are indeed in a relatively inconsistent situation where e.g. Anaconda allows this, but bootc-image-builder and bootc install don't in any kind of direct way; the above PR helps.

Not everyone will want to adopt ignition to do these tasks.

Yes, agreed.

@cgwalters cgwalters added enhancement New feature or request area/install Issues related to `bootc install` area/config Related to configuration triaged This looks like a valid issue labels May 15, 2024
@cgwalters cgwalters linked a pull request May 15, 2024 that will close this issue
Draft
@jmpolom
Copy link
Author

jmpolom commented May 15, 2024 •
edited
Loading

I gathered there was divergent functionality here and this was not really supported now. What is the present day workaround?

What is going on in your PR with let target_etc = root.open_dir("etc").context("Opening deployment /etc")?;? Are you effectively just grabbing the etc directory of the ostree deployment in sysroot? figured this out for myself.

As for a workaround, should I just dump stuff into <physroot>/ostree/deploy/default/deploy/<hash>/etc/? What I've come up with to use in a script with a filesystem install to get to this location: ostree admin status | head -n 1 | cut -d ' ' -f 3 -

@jmpolom jmpolom mentioned this issue May 15, 2024
Open
@jmpolom
Copy link
Author

jmpolom commented May 16, 2024 •
edited
Loading

As for a workaround, should I just dump stuff into <physroot>/ostree/deploy/default/deploy/<hash>/etc/? What I've come up with to use in a script with a filesystem install to get to this location: ostree admin status | head -n 1 | cut -d ' ' -f 3 -

ostree admin status --sysroot=<wherever sysroot is mounted> doesn't work right after install as it reports works only if the boot partition is mounted otherwise it reports No deployments. It looks like ostree rev-parse --repo=<wherever sysroot is mounted>/ostree/repo ostree/1/1/0 could work if boot isn't mounted for some reason.

It would be a much more pleasant experience if bootc install subcommands could cleanly output this bit of info. It is present internally.

@cgwalters
Copy link
Collaborator

ostree admin status --sysroot= doesn't work right after install as it reports No deployments.

It's almost certainly because you have a distinct /boot filesystem which isn't mounted, and ostree uses the bootloader configs as source of truth.

@jmpolom
Copy link
Author

jmpolom commented May 17, 2024 •
edited
Loading

ostree admin status --sysroot= doesn't work right after install as it reports No deployments.

It's almost certainly because you have a distinct /boot filesystem which isn't mounted, and ostree uses the bootloader configs as source of truth.

This is exactly what the issue was. The documentation for ostree admin status does not indicate it pulls data from /boot, however. I wrongly presumed it inspected the repository somehow.

cgwalters added a commit to cgwalters/bootc that referenced this issue Nov 5, 2024
@cgwalters
Merge pull request containers#531 from coreos/dependabot/cargo/serde_…
70064d2 
…json-1.0.107

build(deps): bump serde_json from 1.0.105 to 1.0.107
cgwalters added a commit to cgwalters/bootc that referenced this issue Nov 6, 2024
@cgwalters
Merge pull request containers#531 from cgwalters/fix-panic-on-updated
f237597 
chunking: Ignore ostree commit layer
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/config Related to configuration area/install Issues related to `bootc install` enhancement New feature or request triaged This looks like a valid issue
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

install: Add --copy-etc cgwalters/bootc
2 participants
@cgwalters @jmpolom