From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Warren Date: Tue, 13 Jan 2015 13:52:40 -0700 Subject: [U-Boot] [PATCH 3/4] config_distro_bootcmd: Scan all partitions for boot files In-Reply-To: <1421138453.2450.27.camel@collabora.co.uk> 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> <54B40783.4050204@wwwdotorg.org> <20150112124441.2630a9be@ra.ausil.us> <1421138453.2450.27.camel@collabora.co.uk> Message-ID: <54B58598.30107@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/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 wrote: >> >>> 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. > > 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.