MMCCAM Stack Not Showing BSD Slice

Mon May 6 00:43:36 UTC 2019

I patched loader/main.c to show every time it does a sanity check and it only checks the last two “Setting curdev”s. I also put a check in parse_loader_efi_config to try to figure out what’s going on with the loader.env parser. It turns out “stat” is returning -1 for /efi/freebsd/loader.env. I patched it further to try opening the file regardless but this fails as well.

On another note, I compiled the same exact system and installed it onto a brand new 128 GB sd card, the old one being 32 GB. It had no loader.env or even a loader.conf. The UEFI loader first tried disk0p1 for currdev then it tried disk0p2. It booted successfully without any “extra help”. I reverted all of my patches before building. I’m not surprised it didn’t require the “exact” slice disk0p2a when on the old slice disk0s2 worked for currdev as well as disk0s2a did. I think the problem may be how the loader is reading the device. On this SD card the loader sees the parts as “p” and on the old one the parts are “s”. In my mind I’ve always associated “p” with GPT and “s” with MBR. Loader_lua.efi sees the new sd card parts as “p” though the OS sees them as “s” (as expected).

- James Shuriff

From: Warner Losh <imp at bsdimp.com>
Sent: Sunday, May 5, 2019 6:14 PM
To: James Shuriff <james at opentech.cc>
Cc: Andrey V. Elsukov <bu7cher at yandex.ru>; freebsd-arm at freebsd.org
Subject: Re: MMCCAM Stack Not Showing BSD Slice

On Sun, May 5, 2019 at 3:37 PM James Shuriff <james at opentech.cc<mailto:james at opentech.cc>> wrote:
I can’t use GPT so I have to use the BSD slice to have a UFS partition. Putting “rootdev=disk0s2a:” in /EFI/FREEBSD/loader.env didn’t work. The full loader log looks like this (before my D_SLICEWILD change):

Consoles: EFI console
ZFS: i/o error - all block copies unavailable
ZFS: can’t read MOS of pool zpi
  Reading loader env vars from /efi/freebsd/loader.env

something went wrong because there should be a message here that says

    Setting currdev to configured rootdev disk0s2a:

Setting currdev to disk0p1:

or maybe disk0p1 isn't found. This should say disk0s1, I'd think, for it to read in things properly.

FreeBSD/arm64 EFI loader, Revision 1.1

  Command Line arguments: loader.efi
  EFI version: 2.70
  EFI Firmware: Das U-Boot (rev 0217.1792)
  Console: efi (0)
  Load Path: /efi\boot\bootaa64.efi
  Load Device: .. SD(0)/HD(1, 0x01, 0, 0x3f, 0x190000)
Trying ESP: .. SD(0)/HD(2, 0x01, 0, 0x3f, 0x190000)
Setting currdev to disk0p1:
Trying: .. SD(0)/HD(2, 0x01, 0, 0x1903f, 0x3b86fc1)

This is odd too. Likely another bug, though it may all step from the same source.

ZFS: can’t find pool by guid
Setting currdev to
ZFS: can’t find pool by guid
Startup error in /boot/lua/loader.lua:
LUA ERROR: cannot open /boot/lua/loader.lua: no such file or directory.

can't load ‘kernel’

With the D_SLICEWILD change the first currdev is disk0s1a, the second is disk0s1a, and the third is blank. I think the best solution is to figure out what’s going on with the loader.env parser and fix that. Easier than implementing a slice walker :)

I'm not sure that would be hard.... I don't think the bug is in common/part.c, but rather somewhere in stand/efi, most likely stand/efi/loader/loader.c, or maybe stand/efi/libefi/efipart.c. Those are two places I know we kinda assume or explicitly assume there's no MBR and nesting to cope with.

Warner

- James Shuriff

From: Warner Losh <imp at bsdimp.com<mailto:imp at bsdimp.com>>
Sent: Sunday, May 5, 2019 5:10 PM
To: James Shuriff <james at opentech.cc<mailto:james at opentech.cc>>
Cc: Andrey V. Elsukov <bu7cher at yandex.ru<mailto:bu7cher at yandex.ru>>; freebsd-arm at freebsd.org<mailto:freebsd-arm at freebsd.org>
Subject: Re: MMCCAM Stack Not Showing BSD Slice

Also, you'd have to tinker with the searching for root algorithm if you wanted to make the D_SLICEWILD work. We don't nest in the searching as well. I'm surprised, a little that it settled on disk0s1a, though. For other platforms we do support nesting, so I'm sure it's that code kinda sorta working, but not really working that's allowing you to get as far as you do.

Warner

On Sun, May 5, 2019 at 2:34 PM James Shuriff <james at opentech.cc<mailto:james at opentech.cc>> wrote:
Makes sense. I can see the loader code that makes that assumption. If the loader disk is partitioned set_currdev_pdinfo assumes it’s GPT. I don’t think VideoCore supports GPT disks (I’m using a Raspberry Pi 3 Model B).

I patched the loader to use D_SLICEWILD instead of D_PARTISGPT. Now currdev defaults to disk0s1a. I can’t find any good documentation on /efi/freebsd/loader.env so I’m looking for the parser that reads the file. I see sanity checks for currdev and it *should* be failing the sanity check but if it is it’s not being logged.

- James Shuriff

From: Warner Losh <imp at bsdimp.com<mailto:imp at bsdimp.com>>
Sent: Sunday, May 5, 2019 4:06 PM
To: James Shuriff <james at opentech.cc<mailto:james at opentech.cc>>
Cc: Andrey V. Elsukov <bu7cher at yandex.ru<mailto:bu7cher at yandex.ru>>; freebsd-arm at freebsd.org<mailto:freebsd-arm at freebsd.org>
Subject: Re: MMCCAM Stack Not Showing BSD Slice

On Sun, May 5, 2019, 1:59 PM James Shuriff <james at opentech.cc<mailto:james at opentech.cc>> wrote:
The "currdev" is defaulting to disk0p1: when it should be disk0s2a:. loader_lua.efi seems to read a file "/boot/freebsd/loader.env" off the FAT16 partition but it uses a particular format that is "subtly different" from loader.conf. I'm trying to set currdev here. When I set "currdev" in the loader prompt instead of just passing it the kernel it mounts the root filesystem automatically.

Loader.efi assumes GPT partitioning. While MBR kinda works, it has not been well tested and bugs like this are lurking.

Warner

- James Shuriff

-----Original Message-----
From: James Shuriff
Sent: Sunday, May 5, 2019 11:02 AM
To: 'Andrey V. Elsukov' <bu7cher at yandex.ru<mailto:bu7cher at yandex.ru>>; freebsd-arm at freebsd.org<mailto:freebsd-arm at freebsd.org>
Subject: RE: MMCCAM Stack Not Showing BSD Slice

Yes, it does show sdda0s2 as a consumer. This didn't happen with the MMC stack so I assumed it was a bug. I've destroyed the label and now the slice is appearing.

loader_lua.efi isn't finding the boot partition. It complains about not finding /boot/lua/loader.lua. I have to manually tell it to "load disk0s2a:/boot/kernel/kernel" and "boot". Then the kernel doesn't automount the root partition. I tried using vfs.root.mountfrom in loader.conf and it's still not automounting. This was a problem when I had the label and still is after I removed it.

My current loader.conf:
vfs.root.mountfrom="ufs:/dev/sdda0s2a"
hw.usb.template=3
boot_multicons="YES"
boot_serial="YES"

My current fstab:
# DeviceMountpointFStypeOptionsDumpPass#
/dev/sdda0s2a/ufsrw11
/dev/sdda0s1/boot/firmwaremsdosfsrw,noatime00
tmpfs/tmptmpfsrw,mode=1777,size=60m00
proc/procprocfsrw00
//JAMES at STEVE-PC/TV/mnt/tvsmbfsrw,-N00

Any ideas? This started when I switched to the MMCCAM stack so I assumed it was all the same issue. I copied loader_lua.efi to the FAT16 partition as /EFI/BOOT/bootaa64.efi.

- James Shuriff

-----Original Message-----
From: Andrey V. Elsukov <bu7cher at yandex.ru<mailto:bu7cher at yandex.ru>>
Sent: Sunday, May 5, 2019 8:56 AM
To: James Shuriff <james at opentech.cc<mailto:james at opentech.cc>>; freebsd-arm at freebsd.org<mailto:freebsd-arm at freebsd.org>
Subject: Re: MMCCAM Stack Not Showing BSD Slice

On 04.05.2019 16:04, James Shuriff wrote:
> Working on current branch for Aarch64 with MMCCAM stack. I have an MBR
> disk partitioned with a 50M fat32lba partition and a 30G BSD slice.
> The BSD slice contains a single UFS partition (root). With the MMC
> stack I would see mmcsd0s1, mmcsd0s2, and mmcsd0s2a. With the MMCCAM
> stack I only see sdda0s1 and sdda0s2. There should be an sdda0s2a. I
> can still mount the root partition via labels (/dev/ufs/rootfs). Any
> ideas?

ufs/rootfs was found on the sdda0s2 and then mounted for r/w. GPART_BSD had no chance to taste sdda0s2 slice, and thus there is no BSD label.
This happens sometimes with labels that share the same provider.

I think if you do `glabel list` you will see that ufs/rootfs uses sdda0s2.

--
WBR, Andrey V. Elsukov

________________________________
 DISCLAIMER: This message and any attachments are intended solely for the use of the recipient and may contain confidential information. If you have received this message in error please delete it and promptly notify the sender, James Shuriff (james at opentech.cc<mailto:james at opentech.cc<mailto:james at opentech.cc>>).
_______________________________________________
freebsd-arm at freebsd.org<mailto:freebsd-arm at freebsd.org> mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org<mailto:freebsd-arm-unsubscribe at freebsd.org>"
________________________________
DISCLAIMER: This message and any attachments are intended solely for the use of the recipient and may contain confidential information. If you have received this message in error please delete it and promptly notify the sender, James Shuriff (james at opentech.cc<mailto:james at opentech.cc>).
________________________________
DISCLAIMER: This message and any attachments are intended solely for the use of the recipient and may contain confidential information. If you have received this message in error please delete it and promptly notify the sender, James Shuriff (james at opentech.cc<mailto:james at opentech.cc>).
________________________________
DISCLAIMER: This message and any attachments are intended solely for the use of the recipient and may contain confidential information. If you have received this message in error please delete it and promptly notify the sender, James Shuriff (james at opentech.cc<mailto:james at opentech.cc>).