OVERVIEW: FreeBSD-11.2-RELEASE-amd64-memstick.img causes computer to freeze until rearranging installation media MBR and partition alignment on Gygabyte motherboard GA-G41M-ES2L STEPS TO REPRODUCE: Using various USB sticks with various different BIOS configurations (USB 1.0/2.0 Enable/Disable | Legacy USB Support Enable/Disable etc), tested with 6 different vendor/sizes USB sticks with same result: Computer freezes right after BIOS memory check at initial stages. Same USB sticks works if loaded with different content (e.g. GRUB from other OSes). STEPS TO FIX THE ISSUE: It seems that realigning the partitions to MiB boundaries fixed the freezing issue. The original FreeBSD-11.2-RELEASE-amd64-memstick has the EFI partition starting at sector 1, right after MBR data. The following steps resulted in a fix for the situation: - Backing up MBR, EFI and BOOT partitions from actual USB stick loaded with the image. - Wipe USB stick with zeros - Restore MBR from backup - Delete actual partitions as pointed in MBR using fdisk on linux - Recreate the EFI and BOOT partitions using linux fdisk with exact same total sector size as in the original image and same partition ID types - Restoring EFI and BOOT partition data from backup to the newly created ones After this procedure the EFI partition starts at sector 2048 and no more at sector 1. Now aligned to MiB as this is a standard in recent linux fdisk program CONSIDERATIONS: Although I’m not an expert in the subject what I think is (and I may be wrong on these): - The EFI partition starting at sector 1 seems like an exotic alignment (or not really aligned to expected usual page sizes) - Using usual/recommended partition alignment can avoid compatibility issues by avoiding uncommon situations (not tested at product development cycle, e.g. tested only with expected page sizes or even hardware being unable to load very different page sizes from BIOS) - Sector 1 is expected to be used by GPT in GPT scheme, keeping that space free of use for other purposes seems to be a good call, for compatibility reasons.
Tossing it over to bcran@, who is doing things with our ESP creation/usage in general -- https://reviews.freebsd.org/D17947 touches how the release images are generated already, this could probably get worked into if it seems reasonable.
This wouldn't surprise me: I had a motherboard a few years ago that hung at the Intel AHCI/RAID optrom if there was a certain pattern on the disk that Linux had written. The latest BIOS for the GA-G41M-ES2L is from 2010/06/21 so it's a relatively old board in terms of potential bugs/issues around booting GPT etc.
FreeBSD-11.2-RELEASE-amd64-memstick.img is MBR only, no GPT involved, what’s perfectly acceptable for either legacy BIOS or UEFI hardware to function correctly in the case of the boot media. The important aspect is the fact that partitions alignment _should_ respect physical sector size/logical sector size exponential ratio in modern approach, to avoid issues. For example as depicted in ATA8-ACS: “As larger sectors occur, partition alignment becomes an important issue that affects applications that check if the first partition starts on sector 63 (e.g., on a 512-byte sector device, all the partitions should start on an LBA that is aligned with the start of a physical sector on the media, on a 1 024-byte sector device, the partitions should start on an even numbered sector and end on an odd numbered sector, and on a 4 096-byte sector device, the partitions should start on an LBA where the low order three bits are zero).”
Please, what remains to be done here? (In reply to Kyle Evans from comment #1) D17947 was closed with <https://github.com/freebsd/freebsd-src/commit/db8b56134506840832bec2d1ce07b9e00d4d6d71> (2018-12-20): db8b56134506 Rework UEFI ESP generation ---- Triage: it's normal to add a former assignee e.g. standards@ to the CC list, and we do have standards as a keyword, however UEFI is not standards for component and standards@ purposes so, in this case, no addition to the list.
Created attachment 247178 [details] Workaround
The 'FreeBSD-14.0-RELEASE-amd64-memstick.img' still causes GA-G41M-ES2L to freeze while trying to initialize basic I/O from USB pen-drive. The same type workaround I explained make it work. I attached a script above that does the workaround, for assertiveness in regard to my description (and for future FreeBSD versions while GA-G41M-ES2L is alive and supported) This is a interesting MOBO. It has mixed ATA/SATA channels. I hope this is not just gibberish out of my head (and hope it makes sense) but my best theory is BIOS firmware forcing/expecting the 63 sectors CHS addressing scheme interface convention 'dictated' by BIOS interrupt call INT13h, historically pushed to ATA I/O command interface BIOS. Breaks otherwise. Even though modern PC (and absolutely modern OS) don't need it, disk utilities (fdisk, gpart etc) still defaults to CHS alignment when creating partitions.