Date: Sun, 5 May 2019 16:14:00 -0600 From: Warner Losh <imp@bsdimp.com> To: James Shuriff <james@opentech.cc> Cc: "Andrey V. Elsukov" <bu7cher@yandex.ru>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: MMCCAM Stack Not Showing BSD Slice Message-ID: <CANCZdfqdx5Bxfs8=Kie81Ow%2BYeXUdJg3bssF1g9eqsWjPQZ6hQ@mail.gmail.com> In-Reply-To: <BN7PR06MB5187FF51B1C89112720B5CEEAA370@BN7PR06MB5187.namprd06.prod.outlook.com> References: <BN7PR06MB51879B7DCDAE6A5BA28C6D41AA360@BN7PR06MB5187.namprd06.prod.outlook.com> <62c176f7-ada7-1243-f603-b6ead448d11e@yandex.ru> <BN7PR06MB5187E860530EF95C70C10A19AA370@BN7PR06MB5187.namprd06.prod.outlook.com> <BN7PR06MB5187E1D8232BAFD41429D326AA370@BN7PR06MB5187.namprd06.prod.outlook.com> <CANCZdfr0du8ekK900oGtOv14KV3hJ-ZGCz%2BXbHyo0agn58n8JQ@mail.gmail.com> <BN7PR06MB51877C4D304ED1E7724856D7AA370@BN7PR06MB5187.namprd06.prod.outlook.com> <CANCZdfof2KVVFdd3Q4miaPyD0JR5RDCsv%2B6hf7jq8Pi_5S3QLg@mail.gmail.com> <BN7PR06MB5187FF51B1C89112720B5CEEAA370@BN7PR06MB5187.namprd06.prod.outlook.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sun, May 5, 2019 at 3:37 PM James Shuriff <james@opentech.cc> wrote:
> I can=E2=80=99t use GPT so I have to use the BSD slice to have a UFS part=
ition.
> Putting =E2=80=9Crootdev=3Ddisk0s2a:=E2=80=9D in /EFI/FREEBSD/loader.env =
didn=E2=80=99t 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=E2=80=99t 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=E2=80=99t find pool by guid
>
> Setting currdev to
>
> ZFS: can=E2=80=99t 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 =E2=80=98kernel=E2=80=99
>
>
>
> 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=E2=80=99s going on with the loader.env parser and fix that. Easi=
er 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@bsdimp.com>
> *Sent:* Sunday, May 5, 2019 5:10 PM
> *To:* James Shuriff <james@opentech.cc>
> *Cc:* Andrey V. Elsukov <bu7cher@yandex.ru>; freebsd-arm@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 a=
s
> you do.
>
>
>
> Warner
>
>
>
> On Sun, May 5, 2019 at 2:34 PM James Shuriff <james@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=E2=80=99s GPT. I=
don=E2=80=99t
> think VideoCore supports GPT disks (I=E2=80=99m using a Raspberry Pi 3 Mo=
del B).
>
>
>
> I patched the loader to use D_SLICEWILD instead of D_PARTISGPT. Now
> currdev defaults to disk0s1a. I can=E2=80=99t find any good documentation=
on
> /efi/freebsd/loader.env so I=E2=80=99m looking for the parser that reads =
the file.
> I see sanity checks for currdev and it *should* be failing the sanity che=
ck
> but if it is it=E2=80=99s not being logged.
>
>
>
> - James Shuriff
>
>
>
> *From:* Warner Losh <imp@bsdimp.com>
> *Sent:* Sunday, May 5, 2019 4:06 PM
> *To:* James Shuriff <james@opentech.cc>
> *Cc:* Andrey V. Elsukov <bu7cher@yandex.ru>; freebsd-arm@freebsd.org
> *Subject:* Re: MMCCAM Stack Not Showing BSD Slice
>
>
>
>
>
> On Sun, May 5, 2019, 1:59 PM James Shuriff <james@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 roo=
t
> 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@yandex.ru>; freebsd-arm@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 sli=
ce
> 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 automou=
nt
> 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=3D"ufs:/dev/sdda0s2a"
> hw.usb.template=3D3
> boot_multicons=3D"YES"
> boot_serial=3D"YES"
>
> My current fstab:
> # DeviceMountpointFStypeOptionsDumpPass#
> /dev/sdda0s2a/ufsrw11
> /dev/sdda0s1/boot/firmwaremsdosfsrw,noatime00
> tmpfs/tmptmpfsrw,mode=3D1777,size=3D60m00
> proc/procprocfsrw00
> //JAMES@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@yandex.ru>
> Sent: Sunday, May 5, 2019 8:56 AM
> To: James Shuriff <james@opentech.cc>; freebsd-arm@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 hav=
e
> received this message in error please delete it and promptly notify the
> sender, James Shuriff (james@opentech.cc<mailto:james@opentech.cc>).
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@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@opentech.cc).
>
> ------------------------------
> DISCLAIMER: This message and any attachments are intended solely for the
> use of the recipient and may contain confidential information. If you hav=
e
> received this message in error please delete it and promptly notify the
> sender, James Shuriff (james@opentech.cc).
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfqdx5Bxfs8=Kie81Ow%2BYeXUdJg3bssF1g9eqsWjPQZ6hQ>