FreeBSD-based TrueOS Desktop CURRENT installed to an HP EliteBook 8540p notebook with UEFI enabled. A limited workaround is outlined below. Long before this beta, I found the same symptoms but never a workaround with FreeBSD-based PC-BSD CURRENT installed to some other computers, including but not limited to an HP EliteBook 8570p. Outline ======= https://github.com/trueos/pc-sysinstall/issues/3#issuecomment-238661284 is concise – > If I boot from the installation disk and run the following commands – > > gpart destroy -F ada0 > > gpart create -s gpt ada0 > > – then boot Parted Magic (from UBCD) and launch Partition Editor, there is again the prompt to fix the GPT. – and critically, for a disk where the operating system is installed: a) without a fix to the GPT, the computer can not find the BSD boot loader – more broadly, it can not find the file system that should be used for the UEFI boot; and b) immediately after a fix by GParted to the GPT, the loader is found and the FreeBSD-based OS boots without difficulty. Symptom on an HP EliteBook 8540p ================================ > Non-System disk or disk error > replace and strike any key when ready > > _ Shown by GParted ================ > Not all of the space available to /dev/sda appears to be used, you can fix the GPT to use all of the space (an extra 7 blocks) or continue with the current setting? Limitations of the workaround ============================= If GELI encryption is preferred when installing the OS, then (as above) the computer can not find the file system that includes the boot loader. The fix to the GPT will allow the loader to be found, however: * with the attempt to load, there's an immediate panic. Side note ========= #211702 blocks me from making a comparison with FreeBSD-11.0-BETA4-amd64 Reference ========= HP EliteBook 8540p Notebook PC – HP EliteBook 8540w Mobile Workstation – Maintenance and Service Guide <http://h20565.www2.hp.com/hpsc/doc/public/display?sp4ts.oid=4097214&docLocale=en_GB&docId=emr_na-c03382696>
> including but not limited to an HP EliteBook 8570p. Correction. That should have been 'including but not limited to an HP EliteBook 850 G2.'.
From the dialogue that is presented by GParted: > Not all of the space available to /dev/sda appears to be used, > you can fix the GPT to use all of the space (an extra 7 blocks) > or continue with the current setting? It's possible to ignore that particular invitation to fix, and still use GParted to make the GPT recognisable by TrueOS Desktop. For example: a) reduce the size of the EFI partition from 100 MB to 99 b) add 1 MB free space before that partition c) apply changes. Then restart the computer, and TrueOS Desktop will boot.
Another workaround, good for most cases: Use gdisk <http://www.rodsbooks.com/gdisk/> to relocate backup data structures to the end of the disk. gdisk is included with GParted Live. So far I have encountered four computers that will not boot a FreeBSD-based operating system without post-installation attention to the GPT. Two HP, two Apple. ---- The most recent case is the first for which gdisk relocation of backup data structures was _not_ a workaround. HP EliteBook 8540p with recently released GhostBSD 10.3 <http://www.ghostbsd.org/10.3_enoch>. In this case I took the same approach as in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211715#c2 above. Specifically, I booted GParted Live from a USB flash drive then used GParted to: a) shrink the fat16 file system /dev/sda1 by 1 MiB (from 100 to 99 MiB); and then b) create a corresponding amount of free space before that partition.
Another workaround, which was good for at least one TrueOS Desktop case (tracking FreeBSD-CURRENT) and is good for today's test case of GhostBSD 10.3: 01) boot from something other than the disk to which the OS was installed 02) use gpart(8) to show the status of the affected disk – the GPT *appears* to be 'OK' but know that the computer will not boot from that disk 03) use gpart(8) to backup, destroy and restore the GPT of the affected disk – then restart, and the computer will boot the installed OS.
https://github.com/trueos/pc-sysinstall/issues/3 no longer exists (sorry); some of what was there *might* be found in https://github.com/trueos/trueos-core/issues/15
Reproducibility with FreeBSD (without TrueOS) ============================================= https://github.com/trueos/trueos-core/issues/114#issuecomment-255430869 >> @MAHDTech Can you try one of the FreeBSD images to see >> if you have the same result? >> >> ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/amd64/ISO-IMAGES/12.0/ https://github.com/trueos/trueos-core/issues/114#issuecomment-255568935 > … FreeBSD 12 snapshot, get the same issue (installs fine but won't boot) …
> Limitations of the workaround > ============================= > > If GELI encryption is preferred when installing the OS, > then (as above) the computer can not find the file system > that includes the boot loader. The fix to the GPT will > allow the loader to be found, however: > > * with the attempt to load, there's an immediate panic. – I guess, that is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213491 gpt{,zfs}boot after r305353 crash in GELIBoot
Comparing a recent installer for TrueOS Desktop with the most recent installer for FreeBSD-CURRENT, FreeBSD-12.0-CURRENT-amd64-20161021-r307747-memstick.img a) installing to a USB flash drive; and then b) attempting to boot a MacBook Pro from that drive. I can not reproduce the problem with installations of FreeBSD. I performed two installations: * one GPT (UEFI) * one GPT (BIOS + UEFI) * both without forcing 4K. I'll seek reopening of https://github.com/trueos/trueos-core/issues/15 and then we can probably close this issue in the FreeBSD area.