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

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


    # 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].



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]