Run /usr/lib/ostree-boot/setup.sh if it exists during u-boot bootloader setup

[jallwine]

Standard Beaglebone images have a custom version of U-Boot installed that looks for specific variables in the uEnv.txt file as well as specific files for loading various device tree overlays. In order to properly set up the /boot/loader.# directory at ostree admin deploy time, I added a check for the existence of /usr/lib/ostree-boot/setup.sh in the deployment and run it so it can set up the necessary symlinks and modifications to uEnv.txt (this is much easier than implementing it explicitly in C). The script is passed the sysroot path, the deployment path, and the /boot/loader.# path so that it can properly set everything up. If the script fails to run (not executable, for example) or exits with an error status, the deployment will fail.

See #2357 for more info.

Here is an example setup.sh script that I use for the Beaglebone:

#!/bin/bash

SYSROOT=$1
DEPLOY=$2
LOADER=$3

echo "PWD: $PWD"
echo "SYSROOT: $SYSROOT"
echo "DEPLOY: $DEPLOY"
echo "LOADER: $LOADER"

cd ${SYSROOT}${LOADER}

cp ${SYSROOT}${DEPLOY}/boot/uEnv.txt uEnv.txt
sed -i "/^cmdline=/ s,$, ostree=${DEPLOY}," uEnv.txt

ln -s ${DEPLOY}/boot/vmlinuz-current
ln -s ${DEPLOY}/boot/initrd.img-current
ln -s ${DEPLOY}/boot/dtbs
ln -s ${DEPLOY}/boot/System.map-current
ln -s ${DEPLOY}/boot/config-current
ln -s ${DEPLOY}/boot/SOC.sh
ln -s ${DEPLOY}/boot/uboot
ln -s ${DEPLOY}/boot/lib

[openshift-ci]

Hi @jallwine. Thanks for your PR.

I'm waiting for a ostreedev member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

[lucab]

/ok-to-test

[dbnicholson]

There are 2 parts I'd like to think about before adding this.

1. @jallwine what does your setup.sh actually do? Anything that can be done with the builtin loader is better for everyone so that they don't have to go implement a separate program to get things deployed. An escape hatch is nice, but I'd rather see ostree work out of the box. Maybe the semantics of the loader just need to be better documented.
2. If the external program is determined to be needed, we really want to think about what the semantics are and what the interface to that program is. Changing it later would be painful since it could make existing deployments unable to upgrade.

[jallwine]

Thanks for taking a look @dbnicholson! I agree we should discuss further. I'm not sure if I'm doing it the best way, but it seems to work. I went this route due to how Beaglebone's custom version of U-Boot works. A lot of the custom U-Boot code is here: https://github.com/beagleboard/u-boot/blob/v2019.04-bbb.io-am335x/include/configs/ti_armv7_common.h The key pieces are under the uname_boot variable when it detects a uname_r variable set in the uEnv.txt file.

1. My setup.sh script copies the deployment's uEnv.txt file over to the proper /boot/loader.#/uEnv.txt. It overwrites what the ostree uboot configuration generated because I'm only concerned with the variables used by Beaglebone's custom version of U-Boot (this is why I was originally leaning towards creating a new bootloader configuration). All I need to change in my uEnv.txt file is add the ostree= to the cmdline argument. This is handled by these two lines:

cp ${SYSROOT}${DEPLOY}/boot/uEnv.txt uEnv.txt
sed -i "/^cmdline=/ s,$, ostree=${DEPLOY}," uEnv.txt

The rest of the lines create symlinks so that Beaglebone's custom U-Boot can find specific paths at boot. In most Beaglebone uEnv.txt files, there's a uname_r variable that should be set to the kernel version of the system. uname_r is used in a number of paths in U-Boot. These paths include /lib/firmware and /boot. When preparing my rootfs, I set the uname_r variable to always be the value current rather than a specific kernel version and then create the proper symlinks to the actual kernel verison (i.e. symlink vmlinuz-current to vmlinuz-4.19.94-ti-r43), initramfs (initrd.img-4.19.94-ti-r43 -> initrd.img-current). There's also a dtbs/<kernel version> folder that contains a number of device tree overlays that can be pulled in at boot by setting specific variables (disable_uboot_overlay_emmc, disable_uboot_overlay_video, disable_uboot_overlay_audio, disable_uboot_overlay_wireless, and disable_uboot_overlay_adc). Again, I symlink that directory to dtbs/current. What's problematic is the real sysroot of the filesystem needs to have symlinks from files in /lib/firmware to the /lib/firmware in the deployment as well as symlinks from files in /boot to the deployment. So, on the real /sysroot I also created symlinks from /lib to /boot/loader/lib and /boot/vmlinuz-current to /boot/loader/vmlinuz-current, /boot/initrd.img-current to /boot/loader/initrd.img-current, etc. With it set up this way, ostree admin deploy needs to create the symlinks from /boot/loader.#/vmlinuz-current to the deployment's /boot/vmlinuz-current (and the initrd, dtbs folder, etc.). My setup.sh script creates those /boot/loader.# links.

2. I pass in the sysroot path, the deployment path and the /boot/loader.# path as the first three arguments to setup.sh. That way the script has the ability to create links however it needs to whether ostree admin deploy is run from a build process or on a client.

Any thoughts you have on the best way forward are appreciated!

[jallwine]

Oh, and there’s one other thing that’s been in the back of my mind, but I haven’t implemented yet in the setup.sh. The U-Boot build does get updated occasionally and needs to be written to the first portion of the Beaglebone’s eMMC (I’ve run into complications with certain device tree overlays when updating them, but didn’t update U-Boot). There’s a script that does this in any given deployment so it seems appropriate to run it from setup.sh during an ostree admin deploy. I would only want to run that piece on the client, and not on the build system.

[jowa2021]

Hello.
I am not a master like most of you here, but this seems dangerous and deceitful. Maybe I misinterpreted everything I have read here, so, can someone please help me understand more clearly ?
Would it be wrong for me to summarize this by saying that this potentially could be used to trick another individual into thinking they were looking at one thing, but its actually another ??