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

[Ian Campbell]

On Wed, 2015-01-07 at 12:46 +0100, Sjoerd Simons wrote:
> On Wed, 2015-01-07 at 11:17 +0000, Ian Campbell wrote:
> > On Wed, 2015-01-07 at 12:01 +0100, Sjoerd Simons wrote:
> > > On Wed, 2015-01-07 at 10:22 +0000, Ian Campbell wrote:
> > > > On Wed, 2015-01-07 at 11:10 +0100, Sjoerd Simons wrote:
> > > > > On Tue, 2015-01-06 at 17:43 -0700, Stephen Warren 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:
> > > > > 
> > > > > > > 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.
> > > > > 
> > > > > 
> > > > > I don't remember exactly how many partitions with fat/ext* filesystems a
> > > > > ChromiumOS installation has (order of 3-5 iirc?), but indeed it means
> > > > > your boot will be a bit slower due to it probing more partitions.
> > > > > Wouldn't expect it to significantly slow down the total boot time
> > > > > though.
> > > > 
> > > > I thought u-boot would scan that partitions which were marked bootable
> > > > first, in which case you just need to set the bit correctly in the
> > > > partition table. I might be wrong about that though. (and re-reading
> > > > $subject, it seems like changing this is the subject of the thread...)
> > > 
> > > Nope current u-boot just always uses the first partition. My changes
> > > make it scan all the partition on the device instead to find a viable
> > > set of bootfiles. As you can see in the previous mails, i do have some
> > > dislike for using the legacy bootable flag for this purpose..
> > 
> > I think when using a legacy partition table it is fine to pay attention
> > to that bit, it's not legacy in that context.
> > 
> > WRT GPT, I think "legacy" in that context can reasonably be inferred to
> > mean "non-EFI", and u-boot isn't EFI so I don't think it is so very
> > wrong for u-boot to pay some attention to it, or at least search those
> > first.
> > 
> > GPT defines bit 1, as "No Block IO Protocol", so if you disagree with
> > treating u-boot as "not EFI", perhaps you'd instead prefer to be "EFI
> > compatible" to the extent of honouring that bit.
> 
> I prefer to treat GPT as a partition table layout seperate from EFI. In
> the GPT context, i tend to read "legacy" as "Intel BIOS". But that's
> really opinions. Respecting bit 1 would be a nice improvement though. 
> 
> Wrt. the boot flag. I can be convinced that partitions with that flag
> should be prioritized in their scanning above others, although i'm
> really not sure how valuable that actually is (i don't think it is).
> What i'm opposed to would be *only* searching partitions with that flag
> as that just tends to be unnecessarily error-prone.

I agree it'd be better to eventually scan everything, but I do think
it'd be useful to follow any hints the partition table might offer.

> > > This is about the default setup though, it would be really nice to get
> > > consistent behaviour. I would be inclined to say that the defaults
> > > should conservatively try the internal/main storage first (assuming
> > > there will be an OS is installed there) and only fallback to other
> > > options later. 
> > 
> > I'm inclined the other way, which is to boot of a removable media first
> > if someone has gone to the effort to plug one in. People building kiosks
> > etc who want to lock it down to internal only can still do so.
> 
> This is the general problem of the user doing an action but the system
> really being unable to devine the intention behind that action.. An
> external storage device can have been plugged in for a lot of reasons,
> not just to boot from (you might have wnated to copy/inspect/change some
> data on the card). I would argue that the main reason for folks to plug
> in external storage devices into computers is not because they'd like to
> boot from it and furthermore that a lot of people would be confused if
> leaving in a storage card/stick makes the system unbootable.

If the external media is present but unbootable then I'd expect it to
(by default) try the internal media next, not fail to boot.

> I suspect this argument comes down to how you expect users to normally
> use the system.. Iotw as a general computing device, just like your
> laptop or desktop machine or as a development toy where you regularly
> boot from external media (I would expect the former, but that's just
> me).

A laptop or desktop machine is typically configured (from the factory at
least) to boot from the optical device first if present (and bootable),
and it's not uncommon for the e.g. a USB stick to be ahead of the hdd in
the default boot order.

But that's not necessarily relevant here, in the context of e.g. arndale
the "external mmc" is an sdcard slot, which it is perfectly reasonable
to boot from and use as a rootfs, and in many cases more convenient
because you can install it from some other host by e.g. dd-ing a distro
provided image to it, or using debootstrap etc. It a bit different from
what one might call "removable media", even if it does happen to be
removable.

Ian.