MMCCAM Stack Not Showing BSD Slice

Sun May 5 22:14:13 UTC 2019

On Sun, May 5, 2019 at 3:37 PM James Shuriff <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>
> *Sent:* Sunday, May 5, 2019 5:10 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
>
>
>
> 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> 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>
> *Sent:* Sunday, May 5, 2019 4:06 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, 1:59 PM James Shuriff <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>; 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>
> Sent: Sunday, May 5, 2019 8:56 AM
> To: James Shuriff <james at opentech.cc>; 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>).
> _______________________________________________
> 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"
>
> ------------------------------
>
> *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).
>
> ------------------------------
> 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).
>