FYI: head -r358966 -> -r359376 and RPi4: -r359376 fails to boot (unless I use boot -v) where -r358966 booted fine before update

[Mark Millard]

On 2020-Mar-28, at 19:48, Mark Millard <marklmi at yahoo.com> wrote:

> [Just correcting a persistent version number typo:
> head -r359376 is correct, not -r359736 . Subject
> corrected too.]
> 
> On 2020-Mar-28, at 18:18, Mark Millard <marklmi atyahoo.com> wrote:
> 
>> On 2020-Mar-28, at 17:14, Mark Millard <marklmi at yahoo.com> wrote:
>> 
>>> I use a microsd card that is set up for booting both
>>> a Rock64 and a RPi4: the dd'd u-boot vs. the RPi4
>>> specific materials are in independent places and
>>> the rest is shared and rather generic.
>>> 
>>> So at head -r358966 I'd been able to both the
>>> Rock64 and the RPi4 from the same media.
>>> 
>>> Now with head -r359736 in place instead:
> 
> Make that: -r358376 .

[Not my day. Trying again: -r359376 . But that
is not a major point of this note.]

>>> A) The Rock64 boots via that media just fine.
>>> 
>>> B) The RPi4 fails to boot (nothing special
>>> like "boot -v").
>>> 
>>> C) The RPi4 with "boot -v" boots just fine.
>>> (This makes identifying the issue non-obvious.)
>>> 
>> 
>> Booting the old kernel seems to consistently
>> work (unload, load, boot sequence).

Turns our that the following sequence seems to
always boot, using just my non-debug head
-r359376 build:

Get to the boot-loader prompt then:

unload
load /boot/kernel/kernel
boot

In other words: reloading the same kernel
leads to such boot attempts working. The
old kernel need not be involved at all
for this kind of sequence.


Also: I tried some artifact.freebsd.org
debug kernel builds and they all booted
fine. (This is not like the OPI+2e boot
problem that I've separately reported.
The OPI+2e boot-problem has a successful
artifact bisection result: head -r359311
breaks things and -r359309 and before
boot fine in my testing.)

Somehow the RPi4 problem appears to be
specific to non-debug builds --or at
least to my non-debug builds of
-r359376 .

>> boot -v of the new kernel can fail.
>> 
>> Plain boot of the new kernel can on occasion
>> boot.


Such variability likely somehow fits
with the unload/load/boot sequence
leading to changed behavior.

I omit the prior boot-output diffs below.

>> . . .


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)