sysroot: Support /boot on / for syslinux and uboot

[cgwalters]

People making smaller operating systems, particularly things like
cloud images, don't need to have /boot as a separate partition.

Build on the code that recently landed to detect whether /boot
is a mountpoint at runtime (for read-only purposes) here in order
to influence bootloader config generation.

Basically if /boot is not a partition, prepend /boot to generated
syslinux/uboot config.

NOTE: not tested in a real world scenario for either syslinux or
uboot, but I did extend the test suite to cover this.

https://bugzilla.gnome.org/show_bug.cgi?id=751666

[cgwalters]

Or, would it work to just drop the leading /? Hmm...I guess not in general if someone installs extlinux to /boot/extlinux.

[cgwalters]

bot, retest this please

[cgwalters]

I finally got around to testing this a bit by converting a CentOS Atomic Host image from grub2->extlinux using libguestfs. (That was a fun process and I hit https://bugzilla.redhat.com/show_bug.cgi?id=1099237 again...what was really broken is libguestfs claimed to support turning off 64 bit but didn't actually do it 😭 ).

Anyways, when things booted I immediately noticed /boot is a bind mount, and then I remembered about https://bugzilla.gnome.org/show_bug.cgi?id=756267

So...this leads me to believe that somehow u-boot has been working without this patch. John, does u-boot do something like search in /boot automatically as well?

[cgwalters]

To complete the picture here more sanely, since we already detect on bootup whether we're in a single partition approach, maybe ostree-prepare-root could touch /run/ostree/sharedboot, or maybe instead we detect whether /sysroot/boot is the same as /boot?

I think we still need an environment variable for OS builders that are doing cross builds, or alternatively/in addition a command line switch to ostree admin deploy (and that gets passed to the API)?

[gatispaeglis]

So...this leads me to believe that somehow u-boot has been working without this patch. John, does u-boot do something like search in /boot automatically as well?

I don't think so. U-boot sources uEnv.txt and then does something like:
load mmc ${bootpart} ${loadaddr} ${kernel_image}

Where kernel_image=/ostree/qt-os-590db09c66551670019a487992f4dae9cb2067e241f7c7fefd6b3d35af55895b/vmlinuz

So to make this work on a single partition system one would need to add the "boot" prefix:
bootdir="/boot".
loaduimage=load mmc ${bootpart} ${loadaddr} ${bootdir}${kernel_image}

I think we still need an environment variable for OS builders that are doing cross builds, or alternatively/in addition a command line switch to ostree admin deploy (and that gets passed to the API)?

Having OSTree to provide a full path is just a convenience in my opinion. Otherwise system builders can take care of this, as partition layout is static and the necessary prefix needs to be configured only once - when bringing up the system.

[wmanley]

So...this leads me to believe that somehow u-boot has been working without this patch. John, does u-boot do something like search in /boot automatically as well?

u-boot on the Tegra TK-1 does this at least. Here's a simplified excerpt that I've formatted for clarity:

boot_prefixes=
    /
    /boot/

scan_dev_for_boot=
    echo Scanning ${devtype} ${devnum}...;
    for prefix in ${boot_prefixes};
    do
        run scan_dev_for_extlinux;
    done

scan_dev_for_extlinux=
    if test -e ${devtype} ${devnum}:${bootpart} ${prefix}extlinux/extlinux.conf;
    then
        echo Found ${prefix}extlinux/extlinux.conf;
        run boot_extlinux;
        echo SCRIPT FAILED:
        continuing...;
    fi

boot_extlinux=
    sysboot ${devtype} ${devnum}:${bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf

The full set of u-boot environment looks like this:

# env print
arch=arm
baudrate=115200
board=jetson-tk1
board_name=jetson-tk1
boot_a_script=load ${devtype} ${devnum}:${bootpart} ${scriptaddr} ${prefix}${script}; source ${scriptaddr}
boot_extlinux=sysboot ${devtype} ${devnum}:${bootpart} any ${scriptaddr} ${prefix}extlinux/extlinux.conf
boot_prefixes=/ /boot/
boot_scripts=boot.scr.uimg boot.scr
boot_targets=mmc1 mmc0 usb0 pxe dhcp 
bootcmd=setenv usb_need_init; for target in ${boot_targets}; do run bootcmd_${target}; done
bootcmd_dhcp=run usb_init; if dhcp ${scriptaddr} boot.scr.uimg; then source ${scriptaddr}; fi
bootcmd_mmc0=setenv devnum 0; run mmc_boot
bootcmd_mmc1=setenv devnum 1; run mmc_boot
bootcmd_pxe=run usb_init; dhcp; if pxe get; then pxe boot; fi
bootcmd_usb0=setenv devnum 0; run usb_boot
bootdelay=2
bootpart=1
cpu=armv7
ethact=RTL8169#0
ethaddr=00:04:4b:5a:f1:d3
fdt_addr_r=0x82000000
fdt_high=ffffffff
initrd_high=ffffffff
kernel_addr_r=0x81000000
loadaddr=0x80408000
mmc_boot=if mmc dev ${devnum}; then setenv devtype mmc; run scan_dev_for_boot; fi
pxefile_addr_r=0x90100000
ramdisk_addr_r=0x82100000
scan_dev_for_boot=echo Scanning ${devtype} ${devnum}...; for prefix in ${boot_prefixes}; do run scan_dev_for_extlinux; run scan_dev_for_scripts; done
scan_dev_for_extlinux=if test -e ${devtype} ${devnum}:${bootpart} ${prefix}extlinux/extlinux.conf; then echo Found ${prefix}extlinux/extlinux.conf; run boot_extlinux; echo SCRIPT FAILED: continuing...; fi
scan_dev_for_scripts=for script in ${boot_scripts}; do if test -e ${devtype} ${devnum}:${bootpart} ${prefix}${script}; then echo Found U-Boot script ${prefix}${script}; run boot_a_script; echo SCRIPT FAILED: continuing...; fi; done
scriptaddr=0x90000000
soc=tegra124
stderr=serial
stdin=serial
stdout=serial
usb_boot=run usb_init; if usb dev ${devnum}; then setenv devtype usb; run scan_dev_for_boot; fi
usb_init=if ${usb_need_init}; then setenv usb_need_init false; usb start 0; fi
vendor=nvidia

Environment size: 1997/8188 bytes

[copumpkin]

What's left to do? This seems pretty appealing to me. Is it worth trying out (as a comparative "end user") in the current state?

[cgwalters]

Rebased for testing 🔬

[vtolstov]

gentle ping...

[vtolstov]

I'm test this pr and don't see that /boot prepended i think this is becasue /boot on / not dedicated partiono , but /boot/efi is the partition. I can delete move all stuff to efi partition but in this case (as i remember) fedora installer complain about that /boot/efi needs to be separate partition.

[vtolstov]

@cgwalters gentle ping... as of user that does not have separate /boot =)

[cgwalters]

Right, this code basically needs to be aware of /boot/efi on Fedora and probably other systems. This gets into a vague area of system dependency. Simplest is likely a build-time option.

[cgwalters]

Sort of related to this...one thing on the back of my mind here is that it'd be safer if we created a container with a new mount namespace, and just mounted read-write there. That way /boot wouldn't be transiently writable by other processes too.

[vtolstov]

does it possible to finish and merge this pr ?

[cgwalters]

This blocks on redoing the grub2 backend, see #706

[rh-atomic-bot]

☔ The latest upstream changes (presumably 455cc5e) made this pull request unmergeable. Please resolve the merge conflicts.

[cgwalters]

Obsoleted by #1404