daemon: Use MountFlags=slave and opt-in to OSTree read-only /sysroot

[cgwalters]

This is all we need to tell libostree that we support a read-only
/sysroot and /boot.

See ostreedev/ostree#1265
PR in ostreedev/ostree#1767

[jlebon]

bot, retest this please

[jlebon]

Requires: ostreedev/ostree#1767

[jlebon]

LGTM, though... I'd feel better if we had tests for this. Can you add a trivial vmcheck test that e.g. sets the flag, reboots, then does some basic operations?

(Once we switch FCOS over to it and merge #1949, that'll be the default, but I think at that point we can modify the test to sanity-check the opposite trivial case of /sysroot rw still working... and we can drop it if we turn it on by default in the future).

[jlebon]

Of course, this would be more meaningful if CI wasn't actually broken right now... 😢

[cgwalters]

I toggled this on in the kernel args tests.

Also tested this locally with FCOS and things seem good!

[jlebon]

OK yup, tested kernel-args on top of #1949.

/lgtm

And of course, this won't actually pass CI until we build a newer ostree and tag it into the continuous tag. Basic pipeline tests did pass though.

/override continuous-integration/jenkins/pr-merge

f29 tests appear to be blocking on some Rust issue:

error: Couldn't execute `cargo metadata` with manifest "./rust/Cargo.toml": Json(Error("EOF while parsing a value", line: 1, column: 0))

Not sure what's going on there. It did pass on f31 in the pipeline tests though.

/override f29-compose1
/override f29-compose2
/override f29-primary

[openshift-ci-robot]

@jlebon: Overrode contexts on behalf of jlebon: continuous-integration/jenkins/pr-merge, f29-compose1, f29-compose2, f29-primary

In response to this:

OK yup, tested kernel-args on top of #1949.

/lgtm

And of course, this won't actually pass CI until we build a newer ostree and tag it into the continuous tag. Basic pipeline tests did pass though.

/override continuous-integration/jenkins/pr-merge

f29 tests appear to be blocking on some Rust issue:

error: Couldn't execute `cargo metadata` with manifest "./rust/Cargo.toml": Json(Error("EOF while parsing a value", line: 1, column: 0))

Not sure what's going on there. It did pass on f31 in the pipeline tests though.

/override f29-compose1
/override f29-compose2
/override f29-primary

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[jlebon]

/retest

[cgwalters]

OK, I reworked this to be compile-time conditional.

What we really want again is a FCOS-continuous stream, testing the latest git master of everything; distinct from the main FCOS builds. We'll get there...

Anyways on this, what we'll end up with is that only people building ostree from git master will get the ro-sysroot, and with this they'll also need to build rpm-ostree git master too. Which personally I always do.

[cgwalters]

Being probably excessively conservative, I don't want to stick ostree git master in anything that main Fedora users might see right now...though I'd of course be more confident of all this once we get our CI going again.

[jlebon]

Ahh heh, FAHC rdgo is actually still going strong. So we did pull in git master ostree and turned on the flag.

Though now tests are failiing with:

VM is running.
error: unlink(vmcheck_orig): Read-only file system

Which yup, of course, is because VMs are re-used.

Anyway, I'm gonna context switch to try to get #1949 working, though meanwhile it looks like our CI is co-operating... let's just turn off that flag again at the end of the test (or in test.sh)?

[cgwalters]

let's just turn off that flag again at the end of the test (or in test.sh)?

Done!

[jlebon]

Alrighty, let's do this!

/lgtm

[jlebon]

Ahh OK, there seems to be a real test failure here. rpm-ostree kargs is hitting EROFS after we turn on the read-only bit and reboot:

+ vm_rpmostree kargs --append=APPENDARG=3RDAPPEND --delete=APPENDARG=VALAPPEND
+ vm_cmd env ASAN_OPTIONS=detect_leaks=false rpm-ostree kargs --append=APPENDARG=3RDAPPEND --delete=APPENDARG=VALAPPEND
+ ssh -o User=root -o ControlMaster=auto -o ControlPath=/dev/shm/ssh-vmcheck1-1576177232616816051.sock -o ControlPersist=yes vmcheck1 env ASAN_OPTIONS=detect_leaks=false rpm-ostree kargs --append=APPENDARG=3RDAPPEND --delete=APPENDARG=VALAPPEND
error: Read-only file system

That should've worked, right?

[jlebon]

But I tested this test on FCOS and it had passed. But that was with coreos/coreos-assembler#736. Maybe there's a subtle difference there between doing it at creation time than turning it on live and rebooting?

[jlebon]

OK, it definitely works to turn on the bit live and reboot in FCOS, so this might be something funny going on with f29. Anyway, I'm not really interested in debugging f29, so for now I just commented out the vmcheck additions. (We can uncomment once we get #1949 in and flip it to false halfway through or something).

/lgtm

[openshift-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cgwalters, jlebon

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [cgwalters,jlebon]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cgwalters]

bot, retest this please

[cgwalters]

/override f29-primary
/voerride f29-compose1

[openshift-ci-robot]

@cgwalters: Overrode contexts on behalf of cgwalters: f29-primary

In response to this:

/override f29-primary
/voerride f29-compose1

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[cgwalters]

/override f29-compose1

[openshift-ci-robot]

@cgwalters: Overrode contexts on behalf of cgwalters: f29-compose1

In response to this:

/override f29-compose1

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.