Fix --sysroot /sysroot on booted system

[cgwalters]

The default sysroot is / - now in theory, saying --sysroot /sysroot should work, except it breaks because we don't mount /boot at /sysroot/boot. Arguably, we should make that a bind mount.

[javipolo]

I see the same behaviour when using ostree container image deploy
Since --sysroot is mandatory, I tried both --sysroot / and --sysroot /sysroot (each time starting with a vanilla SNO) with the same result

Here's the output of both runs:

[root@sno core]# ostree container image deploy --sysroot / --stateroot $new_osname --imgref $base_container
[root@sno core]# ostree admin status                                                                                             
  javipolo 7584311eb1dbc6bcad9584df14fc30a387b5ef6338f5b2b1a2b8ad71bbae8ec8.0 (staged)
    origin: <unknown origin type>                                                                                                                                                             
* rhcos c59713e7f89fa2d3a1b1f8469a3285a52b8e4398c9e690d09e6da43bc73a1c7d.0                                                                                                                    
    origin: <unknown origin type>                                                   
[root@sno core]# ls /boot/loader/entries/                              
ostree-1-rhcos.conf

[root@sno core]# ostree container image deploy --sysroot /sysroot --stateroot javipolo --imgref $base_container                                                                               
The --rebuild-if-modules-changed option is deprecated. Use --refresh instead.
[root@sno core]# ls /boot/loader/entries/
ostree-1-rhcos.conf

However, if I do it in two steps it works fine:

• ostree container unencapsulate
• ostree admin deploy without --sysroot

[cgwalters]

You definitely want --sysroot / per this bug. Are you sure you reset the state between runs? So far in a quick test --sysroot / works here.

[cgwalters]

Did a small PR related to this in ostreedev/ostree-rs-ext#516

[javipolo]

You definitely want --sysroot / per this bug. Are you sure you reset the state between runs? So far in a quick test --sysroot / works here.

I tried again just to be sure, and it seems to be version related (new version seems fixed)

For the record, it fails using ostree shipped in 4.12:

Version: '2022.2'
Git: a332611316fee36b1c630f8b266e4a37f77f2c54

But works OK using the one shipped in 4.14:

Version: '2022.6'                            
 Git: 892a5950a3685f5ffff59b2e2e3158c5afaba26e

[cgwalters]

Ah, yes. We shipped what is basically a MVP of the ostree-container stack in 4.12 (cherry picked just for OCP with custom RHEL8-derived builds) - the focus of everything is on RHEL9 (4.13+).

We can try to get things back to 4.12 but it has to have a pretty strong motivation.

[javipolo]

No need to backport to 4.12 at all. I'll bump to 4.13 to do my testing :)

[javipolo]

Seems that ostree shipped with 4.13.8 is also broken, NOT creating /boot entries, although this version does not report anything broken in rpm-ostree status as it happened with the one in 4.12:

Version

[root@sno core]# ostree --version| head -n3
libostree:
 Version: '2023.1'
 Git: 5799105ba747a016d942b25cfbd1196c41c958ae

Pre deploy status

[root@sno core]# ostree admin status
* rhcos 606ce4372d0f9c6a1cfce100744d7f7f96776e8276d1f253be1045dbbdc04d6f.1
    origin: <unknown origin type>

[root@sno core]# rpm-ostree status
State: idle
Deployments:
● ostree-unverified-registry:quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:3d16f67befd4c592d22746a234f31d3f6b2601a22f4cc711e8808ec4ebde3c29                                           
                   Digest: sha256:3d16f67befd4c592d22746a234f31d3f6b2601a22f4cc711e8808ec4ebde3c29                                                                                            
                  Version: 413.92.202307311416-0 (2023-08-21T15:55:18Z)

Init and deploy

[root@sno core]# ostree admin os-init ingrade
ostree/deploy/ingrade initialized as OSTree root

[root@sno core]# ostree container image deploy --sysroot / --stateroot ingrade --imgref ostree-unverified-registry:quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:87230f7f44e28fb137822bed659de5cedf338a79a9ed7456fd747a47ad84cc95

Post deploy status

[root@sno core]# ostree admin status
  ingrade 67ca8e0eff42371d5b54e5d11b25457bcfd44f628b34d123e897f5bd7064b1f1.0 (staged)
    origin: <unknown origin type>
* rhcos 606ce4372d0f9c6a1cfce100744d7f7f96776e8276d1f253be1045dbbdc04d6f.1
    origin: <unknown origin type>

[root@sno core]# rpm-ostree status
State: idle
Deployments:
  ostree-unverified-image:docker://quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:87230f7f44e28fb137822bed659de5cedf338a79a9ed7456fd747a47ad84cc95
                   Digest: sha256:87230f7f44e28fb137822bed659de5cedf338a79a9ed7456fd747a47ad84cc95
                  Version: 414.92.202307250657-0 (2023-08-21T16:15:35Z)
                StateRoot: ingrade

● ostree-unverified-registry:quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:3d16f67befd4c592d22746a234f31d3f6b2601a22f4cc711e8808ec4ebde3c29
                   Digest: sha256:3d16f67befd4c592d22746a234f31d3f6b2601a22f4cc711e8808ec4ebde3c29
                  Version: 413.92.202307311416-0 (2023-08-21T15:55:18Z)
                StateRoot: rhcos

[root@sno core]# ls /boot/loader/entries/
ostree-1-rhcos.conf
[root@sno core]# 

[cgwalters]

Ah yes this is confusing...notice the (staged) in the output. The ostree container image deploy CLI defaults to that - the bootloader entry is only written at shutdown time in this flow. So it's not broken.