Re: trying to understand how the /boot/loader symlink is supposed to work.

[Will Manley <will williammanley net>]

On Tue, 30 Jan 2018, at 21:08, Dan Nicholson wrote:
> On Tue, Jan 30, 2018 at 10:14 AM, Davis Roman <davis roman84 gmail com> wrote:
> Our image builder has this snippet:
>
>   mkdir -p "${BOOT}"/loader.0
>   ln -s loader.0 "${BOOT}"/loader
>   # Empty uEnv.txt otherwise ostree gets upset
>   > "${BOOT}"/loader/uEnv.txt
>   ln -s loader/uEnv.txt "${BOOT}"/uEnv.txt
>
> This is done prior to calling "ostree admin deploy". We've had that
> forever and I don't recall all the reasons for it. Looking at the
> ostree code in src/libostree/ostree-bootloader-uboot.c, I think what
> happens is that the configuration gets put into loader.N/uEnv.txt
> simulating what's done with the BLS entries. To work, I believe you
> need the toplevel uEnv.txt -> loader/uEnv.txt symlink so u-boot finds
> the uEnv.txt file corresponding to the current booting deployment.

Incidentally we do a similar trick but with the syslinux.conf.  We do it because ostree does auto-detection 
of current bootloader in use and we want to ensure that it picks syslinux:

    # ostree uses the presence of a /boot/syslinux/syslinux.cfg symlink to enable
    # syslinux support:
    mkdir -p /boot/syslinux
    ln -sf /dev/null /boot/syslinux/syslinux.cfg

    export OSTREE_DEBUG_CHECKOUT_DETAILS=1

    # Actually do the deploy
    time ostree admin deploy --no-prune --os=linux $KARGS_ARG "$commit_sha"

    # ostree writes its syslinux bootloader snippet to /boot/loader/syslinux.cfg,
    # but our u-boot looks for it in /boot/extlinux/extlinux.conf:
    ln -sf ../loader/syslinux.cfg /boot/extlinux/extlinux.conf

    # Remove /boot/syslinux again to avoid confusion:
    rm -rf /boot/syslinux

I'd had a thought a little while ago how it'd be nice to specify the complete bootloader configuration in a 
file so ostree doesn't need to do any probing of the system.  This would be useful for preparing disk images 
for embedded where you're running ostree admin deploy on a machine other than the one that will actually be 
running the rootfs.  This would complement the existing --sysroot option you can pass.  Conceptually it's 
similar to using autotools cache files or meson cross-build definition files[1].

[1]: http://mesonbuild.com/Cross-compilation.html#defining-the-environment

Will