ostree init and init-fs, should order of calls matter?

[fwilhe]

Hi,

I was observing something that did not seem logical to me, I'm not sure if this is a bug but I don't really understand what ostree is doing here.

Given this example cli session:

$ mkdir sysroot
$ ostree admin init-fs --modern sysroot
$ mkdir -p sysroot/ostree/repo
$ ostree init --mode=archive --repo=sysroot/ostree/repo
$ mkdir rootfs
$ echo abc > rootfs/foo
$ ostree commit --repo=sysroot/ostree/repo --branch main rootfs
fd004ec9528faf3f625f317b22bdb831ce5e96b53dd03ac004e068a86034baae
$ find sysroot/ostree/repo/objects -name '*file*'
sysroot/ostree/repo/objects/7f/a6fb6a81831271eb66391c71655e254ac8e553c5379bb0eaf4b3ef2ea9129e.file

I do get a file with the name *.file despite using the mode archive which should result in getting a *.filez file.

Out of curiosity, I swapped the order of the init-fs and the init call, which does give me the *.filez file as expected.

$ mkdir -p sysroot/ostree/repo
$ ostree init --mode=archive --repo=sysroot/ostree/repo
$ ostree admin init-fs --modern sysroot
$ mkdir rootfs
$ echo abc > rootfs/foo
$ ostree commit --repo=sysroot/ostree/repo --branch main rootfs
c4e6224df8807b1719a3da767ede362d55c58efa2fd640e357d90f0b7c34c8a4
$ find sysroot/ostree/repo/objects -name '*file*'
sysroot/ostree/repo/objects/7f/a6fb6a81831271eb66391c71655e254ac8e553c5379bb0eaf4b3ef2ea9129e.filez

Is this the intended behaviour? I guess I was using it wrong, but I think the cli is not very forgiving here, where could I have learned about the correct order of commands?

Edit: In case this matters, I'm using ostree from the debian testing repo on arm64

ostree --version
libostree:
 Version: '2023.6'
 Features:
  - inode64
  - libcurl
  - libsoup3
  - gpgme
  - ex-fsverity
  - libarchive
  - selinux
  - avahi
  - libmount
  - systemd
  - release
  - p2p

[jlebon]

ostree admin init-fs implies creating the ostree repo, which is always in bare mode for sysroots (since the goal is to share hardlinks). ostree init is idempotent but will confusingly not error out if the requested mode isn't of the type of the existing repo. But anyway, you normally cannot switch from one repo mode to another after it's been created.

[fwilhe]

Thanks @jlebon that helps.

Just to be clear: os-init is different in that regard, right?