[U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files

[Dennis Gilmore]

On Tue, 06 Jan 2015 17:43:19 -0700
Stephen Warren <swarren at wwwdotorg.org> wrote:

> (CCing Dennis so he can comment from a distro perspective re:
> partition table bootable flags v.s. scanning all partitions)
> 
> On 01/06/2015 10:07 AM, Sjoerd Simons wrote:
> > On Mon, 2015-01-05 at 13:24 -0700, Stephen Warren wrote:
> >> On 01/05/2015 10:13 AM, Sjoerd Simons wrote:
> >>> Not all devices use the convention that the boot scripts are on
> >>> the first partition. For example on chromebooks it seems common
> >>> for the first two partitions to be ChromeOS kernel partitions.

ChromeOS seems to have adopted its own unique setup. it is not a
typical configuration.

> >>>
> >>> So instead of just the first partition scan all partitions on a
> >>> device with a filesystem u-boot can recognize.
> >>
> >> I had planned (but obviously never got around to...) enhancing the
> >> scripts to look up the (set of?) bootable partition(s) on the disk
> >> and to attempt to load the boot files from there. Bootable would
> >> be defined as the MBR bootable flag, or GPT legacy bootable
> >> attribute.
> >>
> >> That would allow the code to zero in on the one specific partition
> >> that it was supposed to look at, rather than searching all
> >> partitions.
> >>
> >> Do you have any thoughts re: which option is better?
> >
> > I did wonder about this as well. I do personally consider the
> > bootable flag as a rather obsolete/legacy thing (GPT even specifies
> > it as a legacy flag), so i was wary about using it.. Also i've been
> > bitten a few times on systems that did rely on the bootable flag
> > (what, what, why does it not boot, oooooohhhh), which was another
> > reason for heading this route.

I really like the idea of using the bootable flag and looking at it but
if its legacy in GPT will it go away in some future partition table
layout? UEFI Requires that a ESP exist. I think requiring that the
bootable flag exist is acceptable.

> > This way does no extra work if the first partition is the partition
> > with the boot partition when compared to only checking partitions
> > with the bootable flag as both would need to list existing
> > partitions.
> >
> > If the first few partitions have no filesystems, the extra work
> > compared to the bootable-flag approach would just be probing the
> > filesystem type, which tends to be relatively simple, so i don't
> > see a big issue there (it's more work to scan for a missing boot
> > file).
> >
> > If your first few partitions are ones without the bootfiles, some
> > more effort is wasted as it will be probing those for viable boot
> > files.. However, in my experience, partition layouts with the
> > bootfiles not on the first filesystem partitions is rather
> > uncommmon. So again, i didn't feel that that was problematic. If
> > you have an odd parition layout, your boot time will be ever so
> > slightly longer :)
> >
> > The only "issue" in my mind is when multiple partitions, for
> > whatever reason, have bootfiles. In which case the first one will
> > get picked with this approach, while with the partition-boot-flag
> > approach you'd have a way to specify, no really just look at that
> > one.. However, i suspect the likelihood of forgetting to set the
> > boot flag is higher (been there, done that) then accidentally
> > leaving boot files on partitions before the intended boot partition
> > (which also requires on uncommon layout), so even then i suspect
> > this approach is more friendly/less error-prone.
> >
> >> This patch looks fine assuming this option (rather than bootable
> >> flag) is selected.
> >
> > Well my thoughts on the matter are above, If folks feel strongly
> > about this approach being the wrong way I'd love to hear their
> > arguments :).
> 
> One issue with this approach is that there's no way for the user to 
> short-circuit the scanning. If I put a ChromiumOS install on an SD
> card and leave it plugged into a system that's going to end up
> booting from eMMC since that's where the boot files are, there are
> lots of partitions to scan on that SD card, which will be a bit
> annoying.

That is what happens on x86 today though. if you had a bootable
cdrom/dvdrom or usb stick it will boot from that before the local
install.

Dennis