overlay.d/05core: disable bootloader-update.service on live ISO

[nikita-dubrovskii]

When running from live-iso bootupctl fails with:

    error: Querying adoptable state: creation time is not available for the filesystem

That happens because filesystem (erofs|suqashfs) doesn't support statx.stc_btime field:

    $ stat /sysroot/.coreos-aleph-version.json
    Access: 2022-08-01 23:42:11.000000000 +0000
    Modify: 2022-08-01 23:42:11.000000000 +0000
    Change: 2022-08-01 23:42:11.000000000 +0000
     Birth: -

coreos/fedora-coreos-tracker#2136

[gemini-code-assist]

Code Review

This pull request introduces a systemd generator to disable the bootloader-update.service on CoreOS live ISOs, preventing failures caused by the lack of statx.stx_btime support on ISO9660. Review feedback highlights that the current kernel argument check may fail for standalone flags and suggests masking the service directly for better efficiency and idempotency.

[dustymabe]

Thanks for working on this @nikita-dubrovskii!

I would say rather than making this a generator I'd prefer either

1. Finding some Condition* that could actually go upstream. i.e. we wouldn't want ConditionKernelCommandLine=!coreos.liveiso necessarily because that leaks CoreOS details into bootupd owned files, but something like ConditionFilesystem=!/boot:ext4 (this condition doesn't exist).
2. If we can't find a good condition to put into the service upstream then we add an overlay/override here (like the one created by the generator in the current version of this PR) but just a permanent override file, not one dynamically created by a generator.

[dustymabe]

ahh - could potentially use ExecCondition to check the filesystem type.

but I have no experience with that.

Could use systemctl show --property=Type --value boot.mount to get the filesystem type and then basically bail out if it is erofs or squashfs.

though maybe there's a better way to just do this in the bootupd code.

@PeaceRebel or @travier - any thoughts here?

[PeaceRebel]

Not 100% sure, may be something like not (!)this?

[dustymabe]

Not 100% sure, may be something like not (!)this?

That is also something specific to CoreOS, so wouldn't want to do 1. with that, but I do agree for 2. that's better than the ConditionKernelCommandLine=!coreos.liveiso because the karg (I think) is specific to ISO, whereas /run/ostree-live happens in live PXE and live ISO cases.

[nikita-dubrovskii]

Finding some Condition* that could actually go upstream.

Actually yesterday i opened 2 PRs, 2nd is coreos/bootupd#1088

That is also something specific to CoreOS

Could it be more specific than https://github.com/coreos/bootupd/blob/main/src/coreos.rs#L30 ? ))

ConditionKernelCommandLine=!coreos.liveiso because the karg (I think) is specific to ISO

First I tried to make smth similar to coreos-ignition-unique-boot.service and created generator with

[[ $(findmnt /sysroot -o FSTYPE -n) =~ ^(erofs|squashfs)$ ]] && exit 0

, but than decided that !coreos.liveiso does the same, but looks simplier. And also it was enough to fix cosa kola run iso.* .

[nikita-dubrovskii]

Dropped generator and added conf file.
Both approaches workaround the issue:

• ConditionKernelCommandLine=!coreos.liveiso
• ExecCondition=/bin/bash -c '[[ ! $(findmnt -n -o FSTYPE /sysroot) =~ ^(erofs|squashfs)$ ]]'

Same added to upstream.

[dustymabe]

Finding some Condition* that could actually go upstream.

Actually yesterday i opened 2 PRs, 2nd is coreos/bootupd#1088

ahh. didn't see that one

That is also something specific to CoreOS

You make a good point. In that case it probably wouldn't have been that inappropriate.

[dustymabe]

I think we should only fix this in one place so we don't accumulate config here that becomes dead over time. Can we close this in favor of coreos/bootupd#1088 ?

[nikita-dubrovskii]

Can we close this in favor of coreos/bootupd#1088 ?

Yep, I opened this since it’s the fastest way to fix the issue. Not sure how often bootupd releases.