Bootx64.efi missing?

[PDP-8]

So I'm really trying to understand this.  I don't see the fallback name as preferred for removable drives (usb sticks, cd-r) in the TinyCorePure64 V12 iso.  I went as far back as ver 9.0 and same thing.

What we see in the iso is:

Code: [Select]

/EFI/BOOT/efiboot
When according to "Rods Books" (hey, I'm trying to study) using a fallback filename of bootarch.efi is preferred for the media which TC is really designed for.

Should be something like this renamed:

Code: [Select]

/EFI/BOOT/bootx64.efi
Rod discusses the reasons for the fallback here for removable media:
https://www.rodsbooks.com/efi-bootloaders/installation.html#alternative-naming

I notice that the rest of the planet seems to use this fallback convention, and even coreplayer2 running with it in various discussions here detailing his filesystem for uefi and even uefi-only systems.

So I'm wondering if the decision to use the simple name of "efiboot"  rather than the more conventional fallback name in the iso, or if perhaps this may be the reason many are having severe uefi-only difficulties with even quality modern hardware?  Is it a placeholder that just didn't get renamed or a design decision?

Perhaps if the fallback name isn't an issue, there may be a problem with the efiboot file itself after all these years?

Not pointing fingers - just trying to learn... It kind of jumped out at me - like "hey, where is the bootx64.efi file that I see everywhere else?"

[Rich]

Hi PDP-8

... What we see in the iso is:

Code: [Select]

/EFI/BOOT/efiboot ...

That's odd, what I see is:

Code: [Select]

/EFI/BOOT/efiboot.imgSo I decided to take a closer look.

After mounting the ISO and the  .img  file:

Code: [Select]

tc@E310:~$ mkdir iso
tc@E310:~$ sudo mount TinycoreISOs/TinyCorePure64-12.0.iso iso
mount: /home/tc/iso: WARNING: device write-protected, mounted read-only.
tc@E310:~$ sudo losetup --show --find --partscan iso/EFI/BOOT/efiboot.img
/dev/loop287
tc@E310:~$ sudo lsblk -f /dev/loop287
NAME    FSTYPE LABEL UUID                                 MOUNTPOINT
loop287 vfat         8A29-A2DC                           
tc@E310:~$ mkdir image
tc@E310:~$ sudo mount /dev/loop287 image
mount: /home/tc/image: WARNING: device write-protected, mounted read-only.
We see what's inside:

Code: [Select]

tc@E310:~$ ls -l image/EFI/BOOT
total 593
-rwxr-xr-x 1 root root 607232 Apr 30  2015 BOOTX64.EFI
And then we clean up:

Code: [Select]

tc@E310:~$ sudo umount image
tc@E310:~$ sudo losetup -d /dev/loop287
tc@E310:~$ sudo umount iso

[PDP-8]

Wow!  Thanks Rich!

I see what that *should* work, but I must dig deeper to find out why that convention isn't followed by most others (having bootx64.efi being called directly instead of just efiboot.img referencing it)

I've got a hunch, but you know me - open mouth and insert foot!

[PDP-8]

Well Rich, you were right - I followed your example and sure enough, BOOTX64.EFI is there.

Back in the windows side, I took care of the low hanging fruit.  Like it defaulting to not showing file extensions.  Or not showing system files.

Still, back in *nix, all roads lead back to either the efi-shell, or the grub prompt.

The efi shell is caused by using dd methods, which result in an iso9660 format, which many modern systems reject by default if they are bootable.  Unless a manufacturer has made an exception.  Hard to tell since that is not a marketable bullet-point.

Attempts to simply mount and copy the files to a removable drive result in a system which IS recognized by uefi, but always lands at grub.

So frustrating, since I can make my own, shoehorn just 2 distribution files, or use any other 3rd party front-end as a bootloader and make it come up.

But when it comes to the iso as delivered, it really has me stumped.  Like finding a needle in a haystack now, since I'm not at that level to see what's obvious.  And I don't want to keep recommending 3rd party front end bootloaders to friends who are curious and want to get that leg up over the wall.

Pardon me while I go outside and yell at a cloud.

Thanks for the help though.  It's gotten me a bit further along.  Someday I'll get the aha-moment....

[gadget42]

re: yelling at clouds [tilting-at-windmills-emoji]

don't feel alone in your frustration as even the windows side is bonkers [rolling-eyes-emoji]

windows 10/11 isos won't fit on dvd so their webpage says "use dual-layer dvd" or "use blu-ray"...and so then using the resulting blu-rays requires turning off uefi...except that then the installers refuse to install because of uefi not being active [yelling-at-clouds-emoji]

ended up using rufus via another win10 installation to create thumbdrive install media [smoke-break-emoji]

the aha-moment has not arrived yet [shrugging-atlas-emoji]

[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: [Select]

mk_efi( )   <-------- to boot usb drives

mk_efiboot( )   <----- to boot from cd/dvd
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

[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