There's a huge variety of situations when booting with UEFI. Document
more of them, hopefully better.
MFC After: 3 days
Sponsored by: Netflix
Details
Details
- Reviewers
manu
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 59117 Build 56004: arc lint + arc unit
Event Timeline
| stand/man/loader.efi.8 | ||
|---|---|---|
| 369 | Accidentally copied from terminal window? | |
| 378 | ":"? | |
| 383 | "If"? | |
| 385 | -t msdosfs? Though I've always wondered why mount(8) can't autodetect that... | |
| 391 | I don't know if modern U-Boot implements enough of this in its read-only runtime services, but older U-Boot doesn't AFAIK, so will probably give an error there. | |
| 432 | Should probably document updating both, not just one; having them be out of sync can get confusing | |
| stand/man/loader.efi.8 | ||
|---|---|---|
| 385 | It's either mount -t msdos (no fs, I should remove that), or it's mount_msdos. I'll switch to the "new" style. | |
| 391 | "If you have to use uboot, you are on your own for knowing what to do for that platform to work, most likely it's just the default listed below." If you get an error here, there's nothing we can do but fall back on the user of the system knowing what to do. If they don't, then we can't really help except by probing or maybe suggesting the default, which may or may not be right. | |
| 432 | We do not want to document updating both. Otherwise, I'd have documented both. | |
| stand/man/loader.efi.8 | ||
|---|---|---|
| 385 | No, it is msdosfs | |
| 391 | Sure, I just think it's relevant enough to note, rather than assume a proper EDK2-based firmware is present | |
| 432 | Well, bsdinstall installs to the removable media path if there's no file there, the common case for a clean install, so leaving the old file untouched sounds like a ticking time bomb waiting for someone's CMOS battery to be replaced and suddenly boot from the old loader. My thinking behind any automated tool was that it should update both if they are bit-for-bit identical, otherwise only update the one it thinks is relevant. | |
This comment was removed by markmi_dsl-only.net.
Comment Actions
Any reason to not use "gpart show -p nda1" for the style of command? It avoids needing to know the naming correspondence.
# gpart show -p nda1
=> 40 2930277088 nda1 GPT (1.4T)
40 2008 - free - (1.0M)
2048 532480 nda1p1 efi (260M)
534528 1562624 - free - (763M)
2097152 2919235584 nda1p2 freebsd-ufs (1.4T)
2921332736 7340032 nda1p3 freebsd-swap (3.5G)
2928672768 1604360 - free - (783M)Without an explicit name "gpart show -p" shows all the naming for MBR examples as well:
# gpart show -p
. . .
=> 63 468862065 da1 MBR (224G)
63 1985 - free - (993K)
2048 102400 da1s1 fat32lba [active] (50M)
104448 468757680 da1s2 freebsd (224G)
=> 0 468757680 da1s2 BSD (224G)
0 128 - free - (64K)
128 460728192 da1s2a freebsd-ufs (220G)
460728320 8028160 da1s2b freebsd-swap (3.8G)
468756480 1200 - free - (600K)[This note replaces the one where I'd messed up a command that I typed in that lead to my making an invalid report.]
Comment Actions
Thanks for the reviews. I was getting a bit defensive earlier today so I took a break...
I could write 5x on this topic talking about weird edge cases I've encountered or debugged. And I'm sure there's others that would point out at least another similar amount... And it would just drown most readers...
So I'll expand this a bit from what I have, but try to make sure the common issues that are still somewhat rare don't drown out the typical path for most. Maybe add most of the 'exception' text to the 'Bugs' section...
| stand/man/loader.efi.8 | ||
|---|---|---|
| 369 | yup. will fix. | |
| 378 | yea, already fixed in my local tree.. | |
| 385 | I thought I'd removed this a while ago. But checking, all I did was remove the whine at -t msdos. I'll update. | |
| 391 | This isn't assuming a EDK2-based firmware. It's assuming UEFI standards compliant firmware. efibootmgr is written to the standard. I'll add a note in 'bugs' that u-boot falls short. If EFI runtime services doesn't work, there's no way to find out the right thing to do. There's quite a bit of "diversity" in the marketplace in the x86 marketplace, so I need to make sure I strike a good balance between being helpful to most people vs being helpful to a few but distracting to many. I'll see what I can come up with. | |
| 432 | bsdinstall does that as an emergency fallback for broken BIOSes. But those broken BIOSes will report they booted from bootx64.efi, at least in my experience. This isn't an automated tool. There's a *LOT* of other details that I'd put in the automated tool. For example, we publish the LoaderDev and LoaderPath via a private UEFI variable to FreeBSD. We also do the same for boot1, and we can use these to make more intelligent choices. We can also grep for FreeBSD loader in the binary. And I'm hoping to add kenv data to help automation as well. But putting all those details here will be more confusing. Now, having said that, I think I'll try to find a way to add a note about edge cases possibly needing to update both. At the moment, we whine about the loader being out of date. If you see that message, update loader.efi and you still see it, you'll need to update the other. | |
| stand/man/loader.efi.8 | ||
|---|---|---|
| 385 | That's the "By default, this will be mounted on", which is what bsdinstall configures, so if you get this far you're already in a weird custom state and mount /boot/efi is highly likely to not work. | |
| stand/man/loader.efi.8 | ||
|---|---|---|
| 487–488 | I'm not sure this follows -- we didn't make the ESP small because boot1.efi was limited in functionality. The prebuilt FAT filesystem hack we used to do is most likely the real reason it was small. Should we include a command to check if you have one of these small ESPs? | |