Re: Using loader to switch kernel and root device on Pi2

On Mar 30, 2025, at 16:40, bob prohaska <fbsd@www.zefox.net> wrote:

> An old Raspberry Pi2 v1.1 (so, armv7) has quit booting from USB when
> using the "bootcode.bin" method (that file only on the MSDOS partition,
> the usual layout on the USB disk). The machine gets stuck in a netboot
> loop. 
> 
> However, it appears possible to boot using the microSD card, then load 
> the kernel and mount the root filesystem from USB at the loader prompt:
> 
> Hit [Enter] to boot immediately, or any other key for command prompt.
> Booting [/boot/kernel/kernel] in 10 seconds... 
> 
> Type '?' for a list of commands, 'help' for more detailed help.
> OK lsdev
> disk devices:

The below disks look like they might be 2
separate media, each separately being
bootable.

>    disk0:    1953525168 X 512 blocks
>      disk0s1: DOS/Windows

Does this have a bootcode.bin and other
RPi* firmware related files? U-Boot?

The above being a EFI msdsofs, likely with
its own EFI/BOOT/*.efi file.

>      disk0s2: FreeBSD
>        disk0s2a: FreeBSD UFS

The above being a UFS-based / file system,
likely with its own /boot/ .

>        disk0s2b: FreeBSD swap
>        disk0s2d: FreeBSD UFS

It is unclear if the above also has a /boot/
as well.

>    disk1:    125042688 X 512 blocks (removable)
>      disk1s1: DOS/Windows

Does this also have a bootcode.bin ? If yes,
the same vintage as above?  What about other
RPi* firmware related files? U-Boot?

The above also being another EFI msdsofs,
likely with its own EFI/BOOT/*.efi file?

>       disk1s2: FreeBSD
>        disk1s2a: FreeBSD UFS

The above being another UFS-based / file
system, likely with its own /boot/ ?


It that the case? The below is only for for the
context: "yes" to there being multiple variants
of various directories and files used in booting,
which might not be the actual type of context.

If yes, then how do you expect the RPi2 to
pick which EFI msdosfs it uses each time? (That
is just one type of example "pick" operation.)
Does it need to be more stable than random for
which it picks?

Once it picks, how do you expect the loader to
pick which UFS-based /boot/ it should use? Does it
need to be more stable than random?

Note that which /boot/loader.conf file would be
used depends on which /boot/ is used if there are
multiple /boot/ directories present.

As I understand things, whichever  EFT/BOOT/*.efi
is used, a /boot/ from the same media (not the
same partition or file system) is used. If there
is more than one such /boot/ on that media
(via distinct file systems on the media), then
the question of which /boot/ is picked is
repeated.

Can you make the disk1s1 such that is not a valid
RPi2* firmware source and not a valid EFI msdosfs?
An example could be renaming the EFI/BOOT/*.efi
file to be a name that is not one that would be
found as a standard .efi file name to be used --so
that it would be ignored.

> http: (unknown)
> net devices:
>    net0:
> OK unload
> OK show currdev
> disk1s2a:
> OK set currdev="disk0s2a"
> OK show currdev
> disk0s2a
> OK load kernel
> /boot/kernel/kernel text=0x1b4 text=0x6df178 text=0x1f9cb8 data=0xc37a8 data=0x0+0x254000 0x4+0xb1af0+0x4+0x134365|
> OK set vfs.root.mountfrom="ufs:/dev/da0s2a"

You did not first show the value of
vfs.root.mountfrom from before you
changed it. Which /boot/ would it
have found if you had not changed
the value?

> OK boot -s
> Using DTB provided by EFI at 0x39f23000.
> Kernel entry at 0x33e00200...
> Kernel args: -s
> .....
> 
> The machine comes up with kernel and root from the USB disk, as desired.
> 
> It appears that the 
> currdev="disk0s2a"
> and 
> vfs.root.mountfrom="ufs:/dev/da0s2a"
> 
> could be placed in /boot/loader.conf,
> but where would the unload and load
> commands go?

Is there more than one /boot/ and, so, more
than one /boot/loader.conf that might be
used from one boot attempt to the next? If
yes, how do you know which /boot/loader.conf
to edit?

Getting which EFI/BOOT/*.efi and /boot/
picking to be stable and as-desired is
something to have in place before worrying
about the content of any specific
/boot/loader.conf or other such file.
(Presumes you do not make all the various
examples [if multiple] be duplicates of
each other for all the files would end up
involved.)

> Without them the machine
> is stuck with the microSD's kernel.

You should only have one RPI* firmware
soruce and only one EFI/BOOT/*.efi (that
has the right filenaming convention) and
only one /boot/ in normal usage contexts.
Having only one /boot/ means having only
one /boot/kernel/kernel as well. There
should not be alternatives that might
instead be found and used.


===
Mark Millard
marklmi at yahoo.com