Tiny Core Base > Corepure64
Bootx64.efi missing?
PDP-8:
This is getting so far beyond me that I have no hope but to rely on the TC system architects.
The question is a bootx64.efi *mandatory*, or can it be left inside the efiboot.img file and still work?
Much of my research from Arch to Centos Like this one from gslabs recently
https://www.gslab.com/blogs/booting-centos-from-uefi
seem to indicate that one is supposed to extract the bootx64.efi and copy it to the EFI/BOOT.
Arch references efiboot.img too:
https://bbs.archlinux.org/viewtopic.php?id=240034
But then I catch that it needs to be created with
--- Code: ---mk_efi( ) <-------- to boot usb drives
mk_efiboot( ) <----- to boot from cd/dvd
--- End code ---
So I have no clue and well beyond my depth why things are why they are. I'll keep searching...
PDP-8:
VENTOY SPEAKS! (I'm on a fix-the-problem, NOT the-blame mode)...
Aha - narrowing it down. The very latest version of Ventoy helps provides a clue, as it has included a "grub-2" compatability mode. Ostensibly to help other systems that *need* that compatability, rather than the default.
HOWEVER, if you place the latest Ventoy into Grub-2 mode (ctrl-r), it fails to find a configuration file for boot for the tc64 iso and tells you so!!!
It may also explain that why every time I am at the grub-prompt, any attempt to define root or find filesystems is a failure with filesystem not found.
EVERY OTHER attempt to dd the iso from my own fat-fingers, to every other "burner app', whether linux or windows, will use dd for the most part, but raise no complaint obviously. So the fingers cannot be pointed to 3rd party utils that simply don't raise their voice since analysis is not programmed in.
This suggests that the TC64 iso is "special", in some manner that I can't define yet, nor provide luser-level (me) hacks to overcome in a convenient manner.
Of course, using Ventoy in the default manner has no issue. But put it into grub-2 mode, and it indicates that *something* may be amiss in the iso or done for a special reason.
On the hunt..
nick65go:
it will be usefull for you to know how the tc.iso was made, the full command and its parameters.
Anyway, to clarify for you my understanding of UEFI64 booting:
- UEFI64 boots only from an ESP (like fat32) flag-mark partition. On that ESP must be a folder /EFI/BOOT and a default BOOT64.EFI file in it (the boot-loader). This BOOT64.EFI can be any EFI-type file, a win10 boot-loader, or a grub2.efi renamed, etc.
- the /EFI/BOOT/efiboot.img is not hard-coded. It can be any name you want. like /aaa/bbb.ccc . What matters is that for CD/DVD booting you have one boot-loader for BIOS, and another one (the second one) for UEFI; which you select it for mkisofs parameters. Basicaly you build "an image" (a pseudo ESP partition) which is like a memdisk. in this image (which can be anywhere inside ISO, like [BOOT] seen from 7zip) you have another normal /EFI/BOOT/BOOT64.EFI.
And this BOOT64.EFI is the second boot-loader, used when you boot from CD/DVD.
FYI: I build (manually) a ISO, with /EFI/BOOT/BOOT64.EFI as a win10 bootloader, and a second one in [BOOT]/ EFI/BOOT/BOOT64.EFI as a grub2.efi; So when you dd this ISO on a USB you boot win10, but when you burn this ISO on a cd/DVD you boot grub2.efi
PS: sometime is better to go back to the basics, instead of using advanced/automated tools. Anyway USB manual build, using grub2.efi is fast. ISO image is not so often burned in a CD/DVD nowadays, it is dispatched merely for compatibility with old devices.
Juanito:
Maybe this explains something: https://fedoraproject.org/wiki/User:Pjones/BootableCDsForBIOSAndUEFI
nick65go:
very nice link Juanito, is all someone could need :)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version