Provide a way to override the ostree= kernel argument

[bgilbert]

ostree-prepare-root and ostree-system-generator both read the deploy path solely from /proc/cmdline. On live PXE systems, the deploy path doesn't come from kernel args; instead, the initramfs synthesizes it by inspecting the filesystem. At present, the only way to pass this path to ostree is to write a fake kernel command line to a file and bind-mount it on top of /proc/cmdline.

It would be helpful for ostree to provide a way to override the deploy path, or perhaps override its view of the kernel command line. This might be an environment variable or command-line option.

[jlebon]

Hmm, I wonder if we could just fallback to comparing st_dev and st_ino of / against all the deployments to figure it out for ourselves.

[jlebon]

Discussions about this in https://github.com/ostreedev/ostree/pull/1995.

[cgwalters]

Hmm, I wonder if we could just fallback to comparing st_dev and st_ino of / against all the deployments to figure it out for ourselves.

I don't understand, it's ostree-prepare-root that does the chroot?

[jlebon]

Yeah, let me unpack that. The idea with that suggestion is to just not teach libostree at all about live systems, but instead make it more generically about "no bootloader" mode signalled by having no ostree= karg at all (implying that the kargs weren't sourced by a bootloader config OSTree itself created). Then:

• ostree-prepare-root just falls back to preparing the only deployment in /sysroot (or error out if there are multiple)
• in the real root, error out on any operation that requires bootloader modification, but still know which deployment we're booted into by just comparing / vs the only deployment root in /sysroot (which is already how we do this today).

[cgwalters]

I think we're on the same page, but how about instead of:

ostree-prepare-root just falls back to preparing the only deployment in /sysroot (or error out if there are multiple)

We require that OS builders create a symlink:

ln -s /ostree/deploy/$stateroot/deploy/$checksum.$serial /ostree-readonly

in the physical root. That way ostree-prepare-root doesn't have to do any filesystem traversal, and it's a much more explicit notice of intent.

[jlebon]

We require that OS builders create a symlink:

ln -s /ostree/deploy/$stateroot/deploy/$checksum.$serial /ostree-readonly

in the physical root. That way ostree-prepare-root doesn't have to do any filesystem traversal, and it's a much more explicit notice of intent.

I think I agree, and we may just be using words differently. When you say "read-only", you're talking about read-only bootloader configuration, right?

Because otherwise, I don't see why most operations that normally require a writable sysroot shouldn't keep working in a live system. IOW, we would error out on ostree admin deploy, but not on ostree pull. Presumably the user knows that this a live system and that doing e.g. ostree pull $whole_other_tree or e.g. curl -LO https://example.com/bigfile has RAMifications (:wink: ).

[cgwalters]

I think I agree, and we may just be using words differently. When you say "read-only", you're talking about read-only bootloader configuration, right?

Right. Hmm. /ostree-readonly-boot? Or it's tricky...in the PXE case it's really "external kernel" but eh.

Because otherwise, I don't see why most operations that normally require a writable sysroot shouldn't keep working in a live system. IOW, we would error out on ostree admin deploy, but not on ostree pull

Oh definitely...and actually there's no reason to tie that to "live/no-/boot systems", see also https://github.com/coreos/fedora-coreos-tracker/issues/354#issuecomment-591417441