MMCCAM Stack Not Showing BSD Slice

Sun May 5 20:54:08 UTC 2019

So /evi/freebsd/loader.env would be relative to the ESP (the s1 fat
partition). It's a simplified version of loader.conf in that it only
understands foo=bar type variables.

There's another new loader variable  called uefi_rootdev. However, UEFI
doesn't really have a notion of BSD partitions (or any nested partitioning
schemes), so there's no standardized way to specify disk0s2a. In a complex
system, this would be a problem. However, in your simple scenario, you may
be able to say 'rootdev=disk0s2a:' in loader.env and have things work.

I just added loader.env in the past couple of weeks, so I've not yet
updated the docs because we have no loader.efi(8) man page. There is a
uefi(8) that I was unaware of when I did these changes. Maybe I could add
something there. We have a lot of undocumented tribal knowledge about the
boot process that we should commit to paper / manpage :)

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).
>