Tiny Core Base > Corepure64
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: ---/EFI/BOOT/efiboot
--- End code ---
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: ---/EFI/BOOT/bootx64.efi
--- End code ---
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
--- Quote from: PDP-8 on November 11, 2021, 05:55:28 AM --- ... What we see in the iso is:
--- Code: ---/EFI/BOOT/efiboot
--- End code ---
...
--- End quote ---
That's odd, what I see is:
--- Code: ---/EFI/BOOT/efiboot.img
--- End code ---
So I decided to take a closer look.
After mounting the ISO and the .img file:
--- Code: ---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.
--- End code ---
We see what's inside:
--- Code: ---tc@E310:~$ ls -l image/EFI/BOOT
total 593
-rwxr-xr-x 1 root root 607232 Apr 30 2015 BOOTX64.EFI
--- End code ---
And then we clean up:
--- Code: ---tc@E310:~$ sudo umount image
tc@E310:~$ sudo losetup -d /dev/loop287
tc@E310:~$ sudo umount iso
--- End code ---
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]
Navigation
[0] Message Index
[#] Next page
Go to full version