From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Mon, 12 Jan 2015 10:42:27 -0700 Subject: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files In-Reply-To: <20150110122712.447ed038@ra.ausil.us> References: <1420478019-18877-1-git-send-email-sjoerd.simons@collabora.co.uk> <1420478019-18877-4-git-send-email-sjoerd.simons@collabora.co.uk> <54AAF302.7020007@wwwdotorg.org> <1420564024.15910.172.camel@collabora.co.uk> <54AC8127.2090404@wwwdotorg.org> <20150110122712.447ed038@ra.ausil.us> Message-ID: <54B40783.4050204@wwwdotorg.org> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 01/10/2015 11:27 AM, Dennis Gilmore wrote: > On Tue, 06 Jan 2015 17:43:19 -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: >>>>> 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.