Tiny Core Base > Corepure64
Bootx64.efi missing?
PDP-8:
I think I go down rabbit-holes too fast and get stuck is my problem.
Like reading how efiboot.img if created too big is silently truncated.
Or how Redhat warns that if one is mounting the efiboot.img to extract the bootx64.efi that since this is an "image within an image", attempts to move bootx64.efi to another location should be done with DD to the desired path, rather than using cp to do so.
Or how 7zip corrupts files.
Or how building to satisfy a boot on a vm does NOT always mean it will be successful on bare metal.
That's what is so frustrating. Juanito guided me earlier on how to make my own. Works fine. Amazing how with just 2 distribution files, I can go from that to a full enterprise system if I want.
My quest is to find out why the 64bit iso - for the common man - seems so difficult when it shouldn't be.
And no disrespect to Juanito either - I'd be bored to tears after supporting dsl and TC for so long. Tip of the hat to you and the others.
But, that Fedora page was last edited on 20 Aug 2010, and the machines we're dealing with now with UEFI have mostly been built past that date. So perhaps that page isn't sufficient to work with what has become de-facto standards today.
PDP-8:
Btw Nick - thank you for the description and Juanito's link. I don't want to appear ungrateful.
But don't be too quick to throw out 3rd party utils as being unhelpful. How many of us burnt our first DSL with proprietary Roxio? :)
What Ventoy is suggesting is that when placed into the grub-2 compatability mode, and not being able to boot - like /every other dd method, whether from a real-command line, or with a 3rd party util / there may be one of two things:
1) There is an actual problem with the iso
or
2) It has become non-standard for post 2010 machines.
That is what I'm looking into. Not that I can't build my own.
We know that multibooters, which put their own bootloader in front of TC, differs from "single purpose" utils which do NOT do that, so we don't want to get them confused with the likes of Etcher, Rufus, etc, or even commandline dd itself.
Every single multi-booter, which substitute their own front-end loader (unless support for TC has been withdrawn), can succesfully boot the 64 bit iso. Be it those that actually mount and rewrite to physical stick (like multibootusb 9.2), or like Ventoy which boot iso's directly, and do so in ram rather than mount and rewrite to another filesystem on the stick.
Every single "single purpose" dd'er wrapped in a gui shell, cannot because they don't substitute their own front end bootloader - they simply deal with the iso as is. Ie Etcher, Rufus or the myriad of others, including simple dd on the commandline itself.
Again, the quest is not to build my own, but to find out why everything that dd's on the planet can't boot post-2010 uefi machines with the current iso. Well at least those who haven't accidentally declared their machine uefi-only, when in fact some are not and have csm features baked in. :)
nick65go:
My laptop has UEFI64(+CMS -BIOS compatible) so I can not help more with pure UEFI-only. But the logic for UEFI64 from ISO, is like this:
1.- if you stop at shell-efi prompt, then UEFI firmware did not find /understand the ESP partition.
2.- if you stop at grub prompt, then the problem is the BOOTx64.EFI.
In case 1: it is because ESP is not like FAT32. (FYI: in qemu I can boot even from fat12/floppy efiboot.img in ISO); or not marked flag as ESP, or wrong min/max size. OR stupid firmware wants GPT-type disk only. (by dd -ing an ISO maybe you obtain a MBR disk).
In case 2: BOOTx64.EFI is an old/incomplete grub2.efi built. Because grub2.efi should include compiled inside it at least modules for bios, iso, mbr, gpt, fat32, efi-video and possible an embedded config. When grub2 did not find its configuration (because a wrong default-path) it stops at grub prompt. With 7zip you can see the structure of grub.efi and its encapsulated modules.
Summary: I think the grub2.efi builder is the possible problem.
PDP-8:
Could be but I'm just trying to catch the "gotcha's" which may be causing this.
Like only using no-emul-boot only once, and forgetting it needs to be in the config twice - once for cd/dvd and another time for usb stick type operations.
I've gone too far to make any headway. The good news is that YUMI-Uefi as of v. 0.0.4.2 seems to work again with TC64 as an "unlisted iso".
So there's that, but I just don't have the depth of knowledge to make any solid connections to anything wrong yet. All I see is that for the systems that DO boot on very recent hardware, bootx64.efi still seems to work, even if that is an old convention.
But thanks to everyone for helping. Invaluable assistance for sure.
Juanito:
Just in case you feel like experimenting with the latest grub, grub2-multi updated in the x86/x86_64 repos :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version