Booting from USB on RPI3

[Mark Millard]

On 2020-Apr-23, at 12:27, Jonathan Chen <jonc at chen.org.nz> wrote:
> 
> On Fri, 24 Apr 2020 at 04:22, bob prohaska <fbsd at www.zefox.net> wrote:
> [...]
>> Consoles: EFI console
>>    Reading loader env vars from /efi/freebsd/loader.env
>> Setting currdev to disk1p1:
>> FreeBSD/arm64 EFI loader, Revision 1.1
>> (Thu Apr 16 06:59:37 UTC 2020 root at releng1.nyi.freebsd.org)
>> 
>>   Command line arguments: loader.efi
>>   Image base: 0x39e91000
>>   EFI version: 2.80
>>   EFI Firmware: Das U-Boot (rev 8217.4096)
>>   Console: comconsole (0)
>>   Load Path: /efi\boot\bootaa64.efi
>>   Load Device: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
>> Trying ESP: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(1,0x01,0,0x81f,0x18fa8)
>> Setting currdev to disk1p1:
>> Trying: /VenHw(e61d73b9-a384-4acc-aeab-82e828f3628b)/UsbClass(0x0,0x0,0x9,0x0,0x0)/UsbClass(0x424,0x9514,0x9,0x0,0x2)/UsbClass(0x2109,0x2811,0x9,0x0,0x1)/UsbClass(0x13fd,0x1040,0x0,0x0,0x0)/HD(2,0x01,0,0x197c7,0x4a6bb39)
>> Setting currdev to disk1p2:
>> Loading /boot/defaults/loader.conf
>> Loading /boot/device.hints
>> Loading /boot/loader.conf
>> Loading /boot/loader.conf.local
>> Loading kernel...
> 
> You've set rootdev=disk1p1: , but your kernel appears to be on
> disk1p2: You should double-check this and make sure you're booting off
> the correct partition.
> 
>> /boot/kernel/kernel text=0x9b804c data=0x192958 data=0x0+0x3a21fe syms=[0x8+0x10f740+0x8+0x134f85]
>> Loading configured modules...
>> /boot/kernel/umodem.ko text=0x2100 text=0x1390 data=0x6e0+0x10 syms=[0x8+0xf48+0x8+0xb6e]
>> can't find '/boot/entropy'
>> 
> 
> It looks like your kernel has loaded, but it can't find the
> file-system. This is usually due to unusual content in /etc/fstab. You
> have to use symbolic names (eg: /dev/gpt/some-gpt-label) instead of
> /dev/da* names.

The RPi3 will not start to boot from a gpt partitioned
media. So picking gpt labeling as the example is somewhat
misleading for single-media booting. glabel based
labeling would be more realistic for the context.

> Can you show the contents of "gpart show -l" of your
> USB disk, and /etc/fstab ?



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