Open bgilbert opened 5 years ago
We could "standardize" /run/ostree-live
here?
https://github.com/ostreedev/ostree/pull/1995 is a WIP PR for this.
This oddly works now in a locally built FCOS live ISO and PXE artifacts:
[root@localhost ~]# rpm-ostree status
State: idle
Deployments:
● ostree://fedora:fedora/x86_64/coreos/testing-devel
Version: 31.20200526.dev.0 (2020-05-26T19:18:19Z)
Commit: f1bbe310d7ec3ac03e1dba2c819f43daf3c7f6c88c000b20892d7d4a25881f2e
GPGSignature: (unsigned)
[root@localhost ~]# cat /proc/cmdline
BOOT_IMAGE=fedora-coreos-31.20200526.dev.0-live-kernel-x86_64 ip=dhcp rd.neednet=1 initrd=fedora-coreos-31.20200526.dev.0-live-initramfs.x86_64.img console=tty0 console=ttyS0 ignition.config.url=http://192.168.122.1:8000/config-fcos.ign ignition.firstboot ignition.platform.id=metal BOOTIF=01-52-54-00-44-96-c9
Repurposing this card now to just generalize it to having ostree be "live system-aware".
Moving this comment over https://github.com/coreos/fedora-coreos-config/pull/3009#issuecomment-2237350414
I think this is basically another instance of ostreedev/ostree#1921 (which I've just retitled); so then ostree-prepare-root would detect that this is a live environment and just not even try to set up composefs there.
Just for reference I don't think that's the right fix. I still think it makes sense to use composefs in this scenario...yes, there are "two layers" of read-only but IMO that's still fine. For example I would actually argue for example that we should enable fsverity by default for our ISOs...it obsoletes things like the anaconda "sha256 the whole filesystem before you run it" thing.
The messy thing here is the intersection between who sets up the filesystem writable portions. On the ostree side we already have the etc.transient
flag - that covers /etc
and is what we should use on ISOs. The messier thing is /var
. Maybe we can also just add that to ostree and have it work the same way, pointing at a tmpfs.
The good thing about this is that from ostree's PoV then we could look at the block device underlying the target rootfs, and if that is physically ro
then that tells us what we need to know, without having a special extar /run/ostree-live
flag.
That sounds fine to me overall, but that seems like more of a follow-up to this? I'd be happy if we can just drop the /proc/cmdline
hacks to start.
This oddly works now in a locally built FCOS live ISO and PXE artifacts:
Ahh, I think the reason this works now is that we're literally shipping a /boot
in the squashfs. Not sure when that changed, but obviously it was a while ago now. It feels a bit awkward, but I guess we also need it now for the HMAC bits for FIPS (unless we also change the dracut module to look elsewhere). I think it'd still make sense to have ostree tolerate no /boot
though, but also seems fine to close this issue for now until someone else shows up asking for it.
We have https://github.com/ostreedev/ostree/issues/1920 tracking the /proc/cmdline
bit. And probably should have a separate issue for the "fold CoreOS live concepts into ostree"?
When Fedora CoreOS is booted as a live PXE system, ostree would ideally function in read-only mode, where it refuses to deploy updates (since that isn't a meaningful operation on a live system) but still provides read-only status info.
rpm-ostreed currently refuses to start on such systems because ostree is unhappy:
Live PXE systems don't need anything in
/boot
, since the kernel and initramfs are provided externally. Fedora CoreOS could generate a fake BLS entry if needed, though note that/proc/cmdline
doesn't contain anostree
argument so we'd need to deal with that also (#1920).What's the best way to proceed here?