Failed to update grub configuration if managing deployments on a loop device

[RomanValov]

Hello,

I would like to generate OSTree-driven disk images on my own and employ the functionality of ostree admin deploy command to update bootloader configuration, but it fails:

$ sudo losetup --find --show --partscan ./Fedora-IoT-33-20210214.0.x86_64.raw 
/dev/loop0
$ sudo mount /dev/loop0p2 /mnt/
$ sudo mount /dev/loop0p1 /mnt/boot/
$ sudo ostree admin status --sysroot=/mnt
  fedora-iot b8a69e5c79be5830bb272356809a52b1660d2013c26f6973d549d0a312a8d21a.0
    Version: 33.20210214.0
    origin refspec: fedora-iot:fedora/stable/x86_64/iot
$ ostree refs --repo=/mnt/ostree/repo/
ostree/0/1/0
$ sudo OSTREE_DEBUG_GRUB2=1 ostree admin deploy --sysroot=/mnt --os=fedora-iot ostree/0/1/0
Copying /etc changes: 3 modified, 0 removed, 20 added
/usr/sbin/grub2-probe: error: cannot find a device for / (is /dev mounted?).
error: Bootloader write config: grub2-mkconfig: Child process exited with code 1

I know I can skip bootloader configuration if I unlink grub.cfg file, but I wonder is there a way to workaround the issue?

As I understand ostree admin deploy makes chroot to deployment directory, but there is no /dev, /sys or /proc directory made available to make grub2-mkconfig work smoothly.

[cgwalters]

Hmm, FIoT should be fixed to do the same thing as FCOS and set the bootloader backend https://github.com/coreos/coreos-assembler/blob/74f44afa3b50909ce2c3fda5a45a2c8bf2c12c94/src/create_disk.sh#L362 to none (except on s390x).

[cgwalters]

Ah right I tried this at https://github.com/rhinstaller/anaconda/pull/2752

[RomanValov]

@cgwalters as I understand you suggest to disable bootloader config re-generation

But on the other hand is there a chance it will work correctly without disabling?

In other case I would probably do the bind mounts for dev/sys/proc before invocation of ostree admin deploy. But the point with ostree admin deploy is that it generates the deployment directory during it's run and makes chroot to that directory with no way to control the chroot

[cgwalters]

To be clear, the idea here is that at boot time, grub reads the /boot/loader entries which ostree writes. We're still updating the GRUB configuration, we just aren't regenerating a grub-specific file to do so.

[cgwalters]

To use this, your GRUB needs the BLS patches, which Fedora at least ships.

[RomanValov]

GRUB still needs a config file to use BLS. As I see the COSA uses pre-generated grub.cfg. Is that approach considered recommended way to go?

[cgwalters]

Yes, I strongly recommend the CoreOS setup for all ostree-based systems that use grub. Among other major benefits, it avoids invoking os-prober.

[cgwalters]

Without hacking Anaconda today, you could probably do this post-build. There's also ongoing work on using osbuild for IoT I believe, and eventually osbuild/coreos-assembler will converge I hope.