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

[Stephen Warren]

On 01/13/2015 01:40 AM, Sjoerd Simons wrote:
> On Mon, 2015-01-12 at 12:44 -0600, Dennis Gilmore wrote:
>> On Mon, 12 Jan 2015 10:42:27 -0700
>> Stephen Warren <swarren at 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 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.
>
> Sure, However most installation guides for linux on chromeos will still
> tell you have the first 2 partitions as kernel ones (Which is also where
> you put u-boot if you want to load that without writing it to flash).
>
> In any case, this was just an example to indicate why hardcoding
> partition one is nasty.
>
>>>>>>>> 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.
>
> That seems quite confusing indeed. Also ESP partitions are required to
> be vfat afaik, which is rather unconvenient. At least in the Debian
> world, the package management tools get rather annoyed if /boot isn't a
> posix compatible filesystem.
>
> Defining a new partition type UUID would be more GPT-style, there is a
> bit of prior art here:
> http://www.freedesktop.org/wiki/Specifications/DiscoverablePartitionsSpec/
>
> But that doesn't really define a boot partition currently, apart from
> suggesting to mount the ESP on /boot. Something to take up with the
> systemd folks.

One other issue is that there may be no separate /boot partition. We 
don't want to force the existence of a separate partition just so that 
it can have the bootable type UUID.

>>>>> 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.
>
> Ok. To summarize a bit, it seems the overall consensus thusfar is that
> u-boot should honor the bootflag both on old msdos style partitions and
> GPT partitions. So basically folks don't agree with my dislike of the
> boot flag (ah well, such is life).
>
> So the next step for me would be to update this set adding ``part
> listbootable'' command, which does the same as part list, but filters on
> partitions which are bootable (as defined by the bootable flag). And
> change this particular patch to use listbootable instead of list.

I'd suggest a "part list" command that lists all partition IDs, with 
optional options to restrict the set of partitions returned 
"-bootable-flag" would likely be all we implement to start with, but we 
could later implement "-type fat"/"-type ext" etc.

> Dennis, Ian, should we keep trying partition 1 as a fallback or does the
> current Fedora/Debian installers set this flag on new ARM installations
> already? (I guess in the Debian world a NEWS entry for the behaviour
> change might be enough, as afaik the u-boot package doesn't
> automagically reflash itself just yet)

Falling back to partition 1 seems like a good fail-safe, it the list 
returned by "part list" was empty at least.

> In case a new GPT UUID is defined, this can be added as a partition that
> will show up in listbootable in future, it won't require changes to the
> boot_cmds themselves.

Yup.