Screen recording:
A frame from the recording:
…
Failed to load ’/boot/loader.efi’
panic: No bootable partitions found!
Eventually it was decided to have separate bugs for the hardware aspects:
I apologize if my question seems obvious, but did you install it on a good quality USB stick and did it correctly? It doesn’t seem like a problem with the PC but with the stick. But I could be wrong
@borgio3
I’m with you on that. I recently installed NomadBSD to a flaky (unbenownst to me) Corsair GT 3.0 32gb, and crashed and burned, despite passing all flash tests.
Here’s the problem with some bug reports - nobody asks if they have tried a different stick! And what exactly was their favorite DD recipe or other flash method.
That’s why on consumer level boxes with Windows or MacOS installed, when asked about this myself I make them do THREE things to help ensure we are all on the same page before starting out:
As you’ve mentioned, try another stick.
If a consumer device with windows (or mac) is the target, use BALENA ETCHER to burn the image. Critically, it does a verify after the burn which helps reduce flaky sticks. Even if the fellow gray-beard you are helping is a DD-guru with his own recipe, this step helps ensure we are starting out on the same page and I’m not dealing with some outrageous home-grown multi-boot partitioning setup.
As a further diagnostic, if *bsd won’t boot, will it do so with the latest Knoppix? Again, as a hardware diagnostic aid (if it fails there AND with *bsd, then we’ve got bigger issues). No harm trying to help each other - this is not advocating a switch to Knoppix.
Fortunately the latest 9.1 comes in a smaller CD-sized version.
Again, this can be useful to help determine if it wont boot on *bsd AND won’t boot with Knoppix, we’ve got some major issues with the computer itself, and not necessarily *bsd !
At the very least, these steps on cranky hardware can help save some hairs, or at the very least reduce variables that can lead to circular bug-tracking links that are endless.
Another “Gotcha” to look out for:
Some 64-bit windows boxes, even modern uefi ones, may have a 32-bit windows installed to lower costs.
Does that mean you should try to install a 32-bit version of *bsd? NO.
You still need to flash the 64-bit version of NomadBSD, AND secondly, your bios/setup may need to be switched to “windows 64” or similar, even though your machine came with only 32-bit windows in the first place and of course will no longer boot it! (until you switch it back to 32).
Something else to doublecheck anyway to ensure that you are booting 64-bit *bsd on uefi machines properly.
@grahamperrin
I notice that this is a very new machine, and saw with interest that you have the ability to boot from a file.
That would be interesting to see if you could boot from the NomadBSD img file itself when redirected by the uefi setup. I wonder if you’ve tried that - although not sure NomadBSD is set up this way to boot directly from the img…
Yes, if I recall correctly it was the same drive that was used for FreeBSD boot failures · GitHub
If not the same, then it was probably a Kingston DataTraveler G4.
How so?
Copy the .img to an msdosfs file system on a USB flash drive?
I didn’t try Knoppix, however re: 255073 – boot (UEFI): loader: copy_staging: no progress beyond EFI framebuffer information a previously available HP ProBook 440 G7 did boot from installers for OmniOS community edition.
Ah ok. Pretty new machine, and I wouldn’t mind having one myself. Hopefully the stupid efi boot bugs can get worked out.
Booting from a file:
Now that’s an interesting option I’ve never seen in an actual machine before. But yeah, the way I’m familiar with it is that one puts a bootable iso on a drive somewhere and references it.
Example: Lets say one can only boot from some weedy little device, like eMMC or back in the old days, a CD/DVD. But that’s almost unusable. The trick is to boot initially from the slow media, and reference a bootable iso on the much faster media - which for whatever reason you don’t have a permanent install to. Only the iso resides on it.
Using Knoppix as an example, (there are others too) the iso’s are typically bootable by themselves and employ squashfs and the like. I’m not familiar enough with NomadBSD to claim their image is similar.
But the way you’d do it is boot knoppix, and instead of letting it complete the bootup process, you issue a kernel parameter instead, pointing to the iso on the other media:
knoppix64 bootfrom=/dev/sda1/KNXxx.iso
(Access image, boot from ISO-Image. ***)
So! That piqued my interest when I saw something similar in your HP laptop! Just wondered if that can be configured to point to a bootable iso simply sitting on say a fat32 or whatever filesystem !?!
If that worked, the hacker/slacker in me would want to see if I could do the same with NomadBSD’s image. Possibly renaming the extension from .img to .iso (even though it isn’t) if things don’t fly and the HP is looking for bootable iso’s.
That would be my total college-try, and wouldn’t worry if it doesn’t work, since I’m not knowledgeable enough about NomadBSD’s internals at this point.
I can hear mk1 laughing at me right now. 
But that’s the gist of my caffeine-fueled thoughts…
Thanks,
I might try it with an HP ProBook 440 G7, but I’m not hopeful. In my experience with HP BIOS/firmware, the EFI Boot from file routine typically involves browsing a file system hierarchy until an .efi file (for example, BOOTx64.efi) can be chosen.
Maybe today I’ll try it with the much older HP EliteBook 8570p that I currently use.
@grahamperrin
By the way, have you tried the SD-Card slot to boot NomadBSD with? (full size sd-card, not the dinky micro-sd’s)
Just wondering if it would get any futher in the process if what looks like a possible EFI issue is for some reason your usb stick <>hp port has some sort of timing issue instead when asked to boot, rather than just swap files around like most consumers would do.
I take it windows is still functional, and one thing I ALWAYS do is format my SD-cards - at least once - with the proprietary formatter from the SD-Card association. Then feel free to dd or format again with something other os.
Why? These are the people that the manufacturers licensed the tech from. AND, the sd-card association formatter is the only one capable of reaching into the controller chip to check for proper programming and reprogram the controller chip properly if the manufacturer hasn’t done well, or has it tweaked specifically for windows or mac.
For most people, doing something like this on their sd-cards (and micro-sd’s for you RPI or other single-board hackers) is over the top, but thought I’d throw this out.
So maybe grab a full-sized sd-card (yeah yeah, even if they are not true full-speed), and see if you can dd or otherwise flash NomadBSD onto it and see how far you get. Use the sd-card association formatter just once if you like if you want to make sure the internal controller is doing ok.
(It’s late here, and I forgot if I flashed the image directly to the SD-card, or if instead I used an sd<>usb adapter to do the initial burn to SD, (so now the device shows up as a usb-device when DD’ing, and then for actual booting, used just the sd-card slot proper for the real boot…)
Thanks. I’ll try this, if I can find a card.
Re: availability of the HP ProBook 440 G7, I don’t have one, but it’s the only type of computer that will be available to me (at work). I sometimes have my hands on this make and model before it’s handed over to other people.
Fixed in FreeBSD 13.1-RELEASE.
From https://www.freebsd.org/releases/13.1R/relnotes/#boot-loader:
UEFI boot is improved for amd64. The loader detects whether the loaded kernel can handle the in-place staging area (non-copying mode). The default is
copy_staging auto. Auto-detection can be overridden, for example: withcopy_staging enable, the loader will unconditionally copy the staging area to 2M, regardless of kernel capabilities. Also, the code to grow the staging area is more robust; for growth to occur, it’s no longer necessary to hand-tune and recompile the loader. (Sponsored by The FreeBSD Foundation)
D31121 amd64 UEFI boot: stop copying staging area to 2M phys