Image 'main' has not been built yet (I need to use --force)

[francoism90]

Is this expected? I'm on CachyOS:

$ mkosi qemu
‣ Distribution of your host can't be detected or isn't a supported target. Defaulting to Distribution=custom.
‣ Image 'main' has not been built yet
‣ (Make sure to build the image first with 'mkosi build' or use '--force')

Using mkosi qemu --force works fine.

[MoltenArmor]

Can you provide your tree output and mkosi.conf?

[francoism90]

I have tried it with mkosi build && mkosi qemu, this doesn't work, the last command states 'main' is not build yet. Using mkosi qemu --force works.

I did use Format=disk, because of the following in man mkosi:

If the disk output format is used, the disk image is generated using systemd-repart.   The  repart
              partition  definition  files  to use can be configured using the RepartDirectories= setting or via
              mkosi.repart/.  When verity partitions are  configured  using  systemd-repart’s  Verity=  setting,
              mkosi  will  automatically  parse  the verity hash partition’s roothash from systemd-repart’s JSON
              output and include it in the kernel command line of every unified kernel image built by mkosi.

I have defined them like https://github.com/francoism90/custom-os/tree/feat-mkosi/mkosi.repart, I thought this would create the subvolumes? If I use directory, how does it know the EFI/root filesystem specs?

[MoltenArmor]

https://github.com/francoism90/custom-os/tree/feat-mkosi/mkosi.repart

Sorry, I completely misunderstood your last reply. I thought you meant UseSubvolumes=true(which, according to mkosi.1, only affects the output when Format=directory is used).

About the mkosi qemu issue, that's because after PR 3696, mkosi always reparses configuration files instead of saving the full resolved config in history.

Since your mkosi.version script is dynamic, it generates a new version string every time it's called. mkosi detects this as a configuration change and concludes that the existing image is outdated. That's why mkosi qemu complains about image not built.

In your use case, you can use a mkosi.bump script and run mkosi bump to generate a static mkosi.version only when necessary, just like what ParticleOS does.

About the subvolume issue, I'm still trying to reproduce it.

[francoism90]

I wasn't aware of ParticleOS, which looks really cool! It seems like a far better base, than the one I'm currently try to build.

Does ParticleOS use subvolumes? I think it's needed for upgrades to work, but I'm very new with this, so don't know for sure, but I use them because of their flexibility.

If so, I better try to build that image, instead of my own implementation. :)

[MoltenArmor]

I wasn't aware of ParticleOS, which looks really cool! It seems like a far better base, than the one I'm currently try to build.

Does ParticleOS use subvolumes? I think it's needed for upgrades to work, but I'm very new with this, so don't know for sure, but I use them because of their flexibility.

If so, I better try to build that image, instead of my own implementation. :)

Yep it does use subvolumes, and A/B updates work seamlessly. You can treat it as the reference implementation of the design principles laid out in Fitting Everything Together.

[francoism90]

Thanks! I'll look into this. :)