bootc install to-filesystem - having issues with passphrase LUKS

[spmfox]

Hello, I'm trying to install bootc on top of an existing system that's configured with a LUKS passphrase. Reproducing this is easy, just a standard CentOS Stream 9 install - check the box for encryption during installation. Then run the bootc deployment method I describe below on top of the newly installed system. When the system reboot it hangs for a while then drops to a dracut prompt. No interesting log messages as far as I can tell.

I've looked/searched through all the bootc documentation and all of the issues & discussions on GitHub, but I cant seem to find any examples or anyone talking about using regular passphrase LUKS with this bootc deployment method.

Is this a known issue or am I doing something wrong? Thanks for your time.

I am using this deployment method as a test:

podman run --rm --privileged \
        --pid=host --security-opt label=type:unconfined_t \
        --volume /dev:/dev \
        --volume /var/lib/containers:/var/lib/containers \
        --volume /:/target \
        --entrypoint bootc \
        quay.io/centos-bootc/centos-bootc:stream9 \
        install to-filesystem --skip-fetch-check --replace=alongside /target --root-ssh-authorized-keys /target/root/.ssh/authorized_keys

[cgwalters]

In the general case it's pretty tricky as unlocking the root volume can get arbitrarily complex, and we'd need to know how to scrape out all the data for that. However, I think it's tractable to:

• Teach bootc to handle well-defined distro defaults (as you are trying)
• Error out if we are uncertain if we can handle the rootfs

That all said out of curiosity for your use case, would you be OK if we just wiped the OS state instead and reinitialized? (Per https://github.com/containers/bootc/pull/78 ) - in this case it'd be bootc (or an external installer like anaconda) which would need to configure the LUKS setup, we wouldn't try to handle an existing one.

In other words: if we supported a flow of running anaconda as a container, moving itself to RAM and reinitializing the target disk (with support for inheriting desired state when moving to RAM) would that match your use case?

[spmfox]

Hi Colin, yes that would work - the takeover sounds like a cleaner version of the replace. Any solution to installing with a LUKS encrypted drive would match my use case. I've mainly been using install to-filesystem for my testing because its the easiest to get started with.

I have tried the ISO install method hoping that I can just modify the install via anaconda but it gives you no way to make changes before deploying the image.

However I agree that bootc should be able to detect if that's not currently supported and error out before it results in an unusable system.

[cgwalters]

I have tried the ISO install method hoping that I can just modify the install via anaconda but it gives you no way to make changes before deploying the image.

What changes do you want to make? You should be able to make almost all changes via deriving a container image, right?

[spmfox]

I have tried the ISO install method hoping that I can just modify the install via anaconda but it gives you no way to make changes before deploying the image.

What changes do you want to make? You should be able to make almost all changes via deriving a container image, right?

I was just looking for a way to install with LUKS using a passphrase, either by taking over a system that already had it or perhaps do it manually with Anaconda.