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

[Stephen Warren]

On 01/10/2015 11:27 AM, Dennis Gilmore wrote:
> 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.

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.

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

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.