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

[Dennis Gilmore <dennis@ausil.us>]

On Mon, 12 Jan 2015 10:42:27 -0700
Stephen Warren <swarren@wwwdotorg.org> wrote:

> On 01/10/2015 11:27 AM, Dennis Gilmore wrote:
> > On Tue, 06 Jan 2015 17:43:19 -0700
> > Stephen Warren <swarren@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.
> 
> One other alternative for GPT is to invent a new partition type UUID
> for bootable partitions. This likely has more implications though,
> since any tool that looks at the partition type UUID would have to be
> updated. I have no idea how many such tools exist though.

or perhaps use the ESP flag. though that might be totally confusing for
all.


> >>
> >> 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.
> 
> x86 doesn't search all the partitions though, only those marked with
> the bootable flag. That's why I'm trying to drive the standard distro
> boot process (as implemented by U-Boot) to honor the bootable flag
> and ignore other partitions.

Right, bios uses the bootable flag, UEFI uses the ESP partition which
is why I guess GPT has the bootable flag as a legacy option. I'm in
agreement with you on honouring the bootable flag. I was just trying to
point out that if you put say a usb stick in a machine that had a live
image installed on it that's what the x86 system would boot.

Dennis