[PATCH v5 38/46] boot: Consider non-bootable partitions

[Simon Glass]

Hi Tom,

On Fri, 28 Mar 2025 at 10:30, Tom Rini <trini at konsulko.com> wrote:
>
> On Fri, Mar 21, 2025 at 07:38:27PM +0100, Simon Glass wrote:
> > Hi Tom,
> >
> > On Thu, 20 Mar 2025 at 15:22, Tom Rini <trini at konsulko.com> wrote:
> > >
> > > On Thu, Mar 20, 2025 at 03:43:36AM +0000, Simon Glass wrote:
> > > > Hi Tom,
> > > >
> > > > On Wed, 19 Mar 2025 at 16:40, Tom Rini <trini at konsulko.com> wrote:
> > > > >
> > > > > On Wed, Mar 19, 2025 at 03:03:49PM +0000, Simon Glass wrote:
> > > > > > Hi Tom,
> > > > > >
> > > > > > On Tue, 18 Mar 2025 at 16:53, Tom Rini <trini at konsulko.com> wrote:
> > > > > > >
> > > > > > > On Tue, Mar 18, 2025 at 03:24:02PM +0000, Simon Glass wrote:
> > > > > > > > Hi Tom,
> > > > > > > >
> > > > > > > > On Tue, 18 Mar 2025 at 15:04, Tom Rini <trini at konsulko.com> wrote:
> > > > > > > > >
> > > > > > > > > On Sat, Mar 15, 2025 at 02:25:58PM +0000, Simon Glass wrote:
> > > > > > > > >
> > > > > > > > > > Any 'bootable' flag in a DOS partition causes boostd to only scan
> > > > > > > > > > bootable partitions for that media. This can mean that extlinux.conf
> > > > > > > > > > files on the root disk are missed.
> > > > > > > > > >
> > > > > > > > > > Put this logic behind a flag and update the documentation.
> > > > > > > > > >
> > > > > > > > > > For now, the flag is enabled, to preserve existing behaviour. Future
> > > > > > > > > > work may provide a command (or some other mechanism) to control this.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Simon Glass <sjg at chromium.org>
> > > > > > > > >
> > > > > > > > > Isn't this backwards as the existing behavior (prior to bootstd) was to
> > > > > > > > > scan and use these files, and so that's the behavior we need to preserve
> > > > > > > > > by default.
> > > > > > > >
> > > > > > > > Not so far as I know, but I've already spent too much time trying to
> > > > > > > > decode those scripts.
> > > > > > > >
> > > > > > > > If you look at scan_dev_for_boot_part, that is what I was trying to
> > > > > > > > replicate with bootstd.
> > > > > > >
> > > > > > > The feedback from the community call where this was brought up was that
> > > > > > > it used to work and now didn't, I thought. Heinrich, I think you had one
> > > > > > > of the cases here (something about RISC-V and multiple distros?) or am I
> > > > > > > misremembering?
> > > > > >
> > > > > > OK let's see if Heinrich chimes in.
> > > > > >
> > > > > > Are there notes for the call? It would help me if they could all be in
> > > > > > a shared document, like we used to use[1].
> > > > >
> > > > > Yes, they're in email.
> > > >
> > > > What subject should I search for to find them? I looked for 'community
> > > > call' and a few other things, but cannot find them.
> > >
> > > They're in reply to every announcement email and sent to all three
> > > lists.
> >
> > OK, well I can't find them, sorry. I did see the first one you sent
> > but after that I have no record.
> >
> > It sounds like you don't want them in a doc for easy reference?
>
> I don't want them hidden away in some document, I want them easily
> accessible.
> https://lore.kernel.org/u-boot/20250128171923.GQ1233568@bill-the-cat/
> https://lore.kernel.org/u-boot/20250211204927.GF1233568@bill-the-cat/
> https://lore.kernel.org/u-boot/20250225191031.GS1233568@bill-the-cat/
> https://lore.kernel.org/u-boot/20250311203117.GV2640854@bill-the-cat/
>
> All of which are in reply to the announcement email for the release.

OK thanks, I see it now. I need to search for '[ann]' not 'community meeting'.

I've copied them into the doc as I find it a bit easier to keep track
of. So much email.

Regards,
Simon

>
> --
> Tom