Trying to install on a SoftIron Overdrive 1000 using the "serial" console (in real life it's USB). The target drive gets partitioned correctly and the msdosfs and ufs file systems get created, the OS gets copied over to the ufs partition just fine. Unfortunately, I'm seeing nothing in the msdosfs EFI partition at all, so the system fails to reboot. Copying the EFI file hierarchy, such that it is, from the mini USB memory stick image into the msdosfs EFI partition allows the system to boot correctly. There are no error messages or warnings from the installer at all. I used the following memstick image: FreeBSD-12.0-CURRENT-arm64-aarch64-20171220-r327038-mini-memstick.img Here's a (failed) boot log, for what it's worth: NOTICE: BL3-1: NOTICE: BL3-1: Built : 14:04:15, Apr 9 2016 INFO: BL3-1: Initializing runtime services INFO: BL3-1: Preparing for EL3 exit to normal world INFO: BL3-1: Next image address = 0x8000e80000 INFO: BL3-1: Next image spsr = 0x3c9 UEFI Interactive Shell v2.1 EDK II UEFI v2.60 (SoftIron Overdrive 1000, 0x00010000) Mapping table FS0: Alias(s):HD0b65535a1:;BLK1: PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(1,GPT,5BA98F8C-E84E-11E7-B174-E0FFF70020A6,0x28,0x64000) BLK0: Alias(s): PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0) BLK2: Alias(s): PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(2,GPT,5BAA2436-E84E-11E7-B174-E0FFF70020A6,0x64028,0x73F9BFF8) BLK3: Alias(s): PciRoot(0x1)/Pci(0x0,0x0)/Sata(0x1,0xFFFF,0x0)/HD(3,GPT,5BAB79D7-E84E-11E7-B174-E0FFF70020A6,0x74000020,0x706D67) Press ESC in 1 seconds to skip startup.nsh or any other key to continue. Shell>
Can you confirm that this happens only when doing a serial install? Or is that a coincidence and we have a bigger problem. Any chance you could do a video install too? maybe none of the installers for arm does the right thing here? Also, which files, exactly, did you need to copy where?
Wotcha! The Overdrive 1000 is a headless machine, so the only kind of install possible is via the USB serial port (other than really esoteric stuff like using another machine to write the hard drive, and then installing it into the Overdrive, but that's way outside what I'm doing). What I copied is: drwxr-xr-x 1 root wheel 8192 Sep 12 19:23 ./efi drwxr-xr-x 1 root wheel 8192 Sep 12 19:23 ./efi/boot -rwxr-xr-x 1 root wheel 393216 Sep 12 19:23 ./efi/boot/BOOTaa64.efi -rwxr-xr-x 1 root wheel 13 Sep 12 19:23 ./efi/boot/startup.nsh I don't know why the dates are from September - they'll be the dates from the installation media though. I would have thought that if none of the arm installers were doing the right thing then you'd have had millions of irate Rasperberry PI 3 owners jumping up and down and screaming by now, which I haven't seen any evidence of, so I'd suspect the text-based serial console installer. Jon.
OK. I'm guessing that arm64's installer has never been used in anger until now and that you're finding bugs in it. There's really no 'standard' thing to do on arm64, alas. We should do the right thing though. I'll work with Nathan to help puzzle that out.
I initially installed FreeBSD on my Overdrive 1000 using an 11.x installer snapshot, so it looks like there's a regression here.
Looks to be a regression in some code NathanW committed a couple of weeks ago. According to IRC, he's in hot pursuit. This may prove to be the first MI bug we've found on arm64. A milestone for the platform!
A commit references this bug: Author: nwhitehorn Date: Thu Dec 28 01:21:31 UTC 2017 New revision: 327258 URL: https://svnweb.freebsd.org/changeset/base/327258 Log: Fix bug introduced in r326674, in which efi boot partitions created by the installer but not mounted (i.e. with boot1.efifat dd'ed to them rather than the forthcoming proper filesystem) would get newfs_msdos run on them immediately after the boot code was copied. This would overwrite the bootstrap code, causing the EFI system partition to be blanked and resulting in an unbootable system. PR: 224562 Changes: head/usr.sbin/bsdinstall/partedit/gpart_ops.c
batch change: For bugs that match the following - Status Is In progress AND - Untouched since 2018-01-01. AND - Affects Base System OR Documentation DO: Reset to open status. Note: I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Jon are you able to try a recent snapshot image? My Overdrive 1000 has unfortunately died.
This issue has been cured some time ago; I've verified that it has mot resurfaced again by testing with FreeBSD-12.0-CURRENT-arm64-aarch64-20180521-r333982-memstick.img Jon.