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

[Sjoerd Simons]

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

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)


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.

-- 
Sjoerd Simons <sjoerd.simons at collabora.co.uk>
Collabora Ltd.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6170 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150113/3f9b9d8f/attachment.bin>