Tiny Core Linux

Tiny Core Base => Corepure64 => Topic started by: PDP-8 on November 11, 2021, 02:55:28 AM

Title: Bootx64.efi missing?
Post by: PDP-8 on November 11, 2021, 02:55:28 AM
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]
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]
Rod discusses the reasons for the fallback here for removable media:

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?"
Title: Re: Bootx64.efi missing?
Post by: Rich on November 11, 2021, 06:25:44 AM
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
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
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 11, 2021, 01:54:31 PM
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! :)

Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 11, 2021, 04:59:02 PM
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....
Title: Re: Bootx64.efi missing?
Post by: gadget42 on November 12, 2021, 02:21:21 AM
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]
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 12, 2021, 07:00:58 PM
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


seem to indicate that one is supposed to extract the bootx64.efi and copy it to the EFI/BOOT.

Arch references efiboot.img too:


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...
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 12, 2021, 08:06:53 PM
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..

Title: Re: Bootx64.efi missing?
Post by: nick65go on November 13, 2021, 02:28:18 AM
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.
Title: Re: Bootx64.efi missing?
Post by: Juanito on November 13, 2021, 02:59:13 AM
Maybe this explains something: https://fedoraproject.org/wiki/User:Pjones/BootableCDsForBIOSAndUEFI
Title: Re: Bootx64.efi missing?
Post by: nick65go on November 13, 2021, 03:33:21 AM
very nice link Juanito, is all someone could need :)
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 13, 2021, 01:07:38 PM
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.
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 13, 2021, 02:34:42 PM
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
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. :)

Title: Re: Bootx64.efi missing?
Post by: nick65go on November 13, 2021, 05:36:54 PM
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.
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 13, 2021, 10:14:58 PM
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. 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.
Title: Re: Bootx64.efi missing?
Post by: Juanito on November 14, 2021, 12:47:03 AM
Just in case you feel like experimenting with the latest grub, grub2-multi updated in the x86/x86_64 repos  :)
Title: Re: Bootx64.efi missing?
Post by: nick65go on November 14, 2021, 02:43:16 AM
@PDP-8:  TC*.iso was built for minimal size (to do not harm tc servers downloads), so ISO has only what is needed for BIOS and UEFI64 to boot from THIS iso. It is NOT made friendly for other/chain loaders. Only by luck it boots on ventoy, etc. For BIOS boot is well suited. It does not boot on UEFI32. Further from now, we "talk" only about UEFI64 boot.

My own "conclusions" about TinyCorePure64-12.0.iso for UEFI64 boot are:
1. the ISO can not be DD-ing (byte-by-byte copy) because many things:
- full DD will obtain an iso-format, with BIOS-ioslinux boot laoder;
- partial DD (skip few first bytes) will obtain a MBR disk (maybe) still with BIOS-isolinux boot-loader.
- GPT-type disk can NOT be obtained, because GPT needs last bytes on USB/HDD to check GPT structure is intact, (Rufus docs commented this).
- the main file missing /EFI/BOOT/BOOTx64.EFI, directly accesible (when USB/HDD), not encapsulated in an efiboot.img (when CD/DVD).

2. The ESP partition is OK encapsulated in [BOOT]/EFI/BOOT/efiboot.img; Inside BOOTx64.EFI (a grub2.efi renamed) there are a lot (74 module objects) of grub modules encapsulated. So no missing modules for mbr, gpt, iso, etc.

But the last module (75) is the embeded configuration file for grub, which SHOULD point to grub.cfg. Hex-view it, and has only NULL bytes and a string "()/EFI/BOOT/grub". which is OK when booting from CD, because "()" point to whatever is /cd, or /cd0.

 So when you copy this BOOTx64.EFI on a USB/HDD will not work, because you need explicit FULL path, like
(hd0, gpt)//EFI/BOOT/grub as root for finding grub.cfg. IMHO is case close. You may need a better embeded configuration, for example with multiple paths. Come on, its just few bytes more in a grub.efi. QED.
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 14, 2021, 01:31:14 PM
WOW!  Nick, this explains it!  Thank you so much.

Geez, how about a freakin' README in the iso to say up front that this is not intended to be dd'ed to usb stick, rather than let the new user who does not have this advanced knowledge struggle endlessly, doubting their own abilities, or at worst, consigning TC to the "vintage-computer" bin?  (my biggest fear)

Because let's face it - there is a growing population who might like TC, but the last time they used/saw a cd/dvd was when they tried to view the wedding photos from their Dad's 1mp Sony-Mavica camera driven by AA batteries? :)  Ie, the problem is not apparent.

I see it from both sides now!  And in fact Rufus, will give the iso a big thumbs up *logically* in the log file display (ctrl-L) and sees it all (including the embedded bootx64.efi in the efiboot.img) and give no complaints.  BUT it can't / does not make any logical conclusions about module support.  It gave me some small tips, but I couldn't see it clearly.  Your explanation does, and validates the rufus logfile.

From a systems-integrity standpoint, this could be a weak point by having an exposed bootx64.efi.  Why?  You don't want people trying to sneak in somebody else's bootx64.efi with extra modules you don't intend to support, (like ntfs or whatever) or other modules badly implemented.  THAT is what I think is going on here.  Module integrity by obscurity for most.  I get it.

How could one logically support that if the ability to use bootx64.efi was swapped around like potato chips from elsewhere?  I certainly wouldn't want to make that the FIRST question any time a support issue came up.  And hoping that the questioner would be honest about it if asked. 

Anyway, thank you so much.  A readme file in the next iso would be helpful stating the intentions so that newcomers won't struggle, or be tipped off immediately that other steps need to be taken.

Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 14, 2021, 03:12:47 PM

Ever see how fast Xfbdev is on a totally fast modern machine?  And in a classic fltk/flwm setup pushing a screen-res of only 1024x768?  Maybe even less like 800x600?

Pretty freakin fast!   This isn't for everyone, but I do it all the time with machines cast off from a year or two ago at work.  Blows people's minds when I tell them that I'm not runnix a full xorg either.

So not for everyone, and all the gobs of ram and storage may seem like a waste.  Forget "toram", there is no observable difference on these fast modern blazers!

Funny how tech has gotten so fast, that one could claim that Xfbdev is still worth supporting for those that like the minimality of it for our use case with the modern gear which just smokes with a classic TC install.
Title: Re: Bootx64.efi missing?
Post by: nick65go on November 15, 2021, 02:21:32 AM
I understand that this subject is clarified now.
But I would like to provide to TC community my humble "work", a demo of how small an ISO can be (463 KB), which can boot in UEFI64 mode, with a minimal grub.efi (137 KB); Grub has a embedded custom configuration but its modules are not embedded, just to prove how little modules are necessary (7 modules, 209 KB) to boot into a grub.cfg menu. Inside the ISO is UEFI64-grub.2.02.txt to explain what I did.

It is a demo because I did not included the ext2, or ntfs modules to chain-boot from other media. The purpose it to "destroy" the myth of what FAT-type UEFI ask for (I used FAT12, a 360KB floppy); and to prove that ESP embedded image can have any path or name you want (i used /Uefi.FLP arbitrary); and there is no /EFI folder in the ISO root, etc.

Code: [Select]
FYI: use 7-zip.exe (open archive) to see inside BOOTIX64.EFI
\EFI\BOOT\BOOTX64.EFI is for UEFI 64 bits  <-modern PC

inside BOOTX64.EFI: is a data structure as : .data, .reloc, .text, .mods
right-click on ".mods" and select "Onen Inside#"
we see pieces like 2.o, 4.0, 6.0, 8.0, 10.0 and 11

right-click on EACH and select "Onen Inside*"
.modulename -> part_msdos, part_gpt, fshelp, fat, iso9660
.moddeps    -> fshelp (for fat & iso9660)
in piece "11" are strings about the embeded configuration: (cd0)/boot/grub

FYI: (cd0) in root of CDROM (ISO image).
Code: [Select]
UEFI can NOT boot from Floppy, UEFI need a ESP-tag Partition. We build a CD/DVD iso with this floppy inside.
1. Build a floppy with bfi.exe [as 160Kb], It will have only two files.
bfi -v -t=0 -l=UEFI -f=myISO-root\UEFI.FLP .\myFDD

2.Then copy UEFI.FLP to myISO-root\
Add a grub2 configuration as myISO-root\boot\grub\grub.conf
Add (in \boot\x86_x64-efi folders):
 boot.mod bufio.mod crypto.mod extcmd.mod gettext.mod normal.mod terminal.mod

3. Build the ISO with:
mkisofs_3.02a7.exe -z -J -sysid MyOS -appid NONE -no-pad -eltorito-alt-boot -b UEFI.FLP -no-emul-boot -o UEFI.iso myISO-root

4.test ISO with VirtualBox, or qemu 4.2.0 (has UEFI)
F:\MyProgs\App64\Qemu42\qemu-system-x86_64.exe -pflash F:\MyProgs\App64\Qemu42\edk2-x86_64-code.fd -cdrom UEFI.iso

EDIT: the forum rules restrict me to "Restrictions: 4 per post, maximum total size 192KB, maximum individual size 128KB"  :( The logic is the same for linux and windows commands (do not be picky).
Title: Re: Bootx64.efi missing?
Post by: nick65go on November 15, 2021, 05:00:24 AM
FYI: the missing part from previous post is about how to build your MINIMAL grub2.efi yourself.
Code: [Select]
grub-mkimage -v -d x86_64-efi -O x86_64-efi -o BOOTX64.EFI -p (cd0)/boot/grub part_msdos part_gpt fat iso9660
See topic (from 27/06/2020) " rant/discussion about grub bootloaders - MBR and EFI"

And some info about minimal size for FAT12 (160 KB), or FAT16,  or FAT32 (17 MB) for ESP partition. (and forget MS-windows bad advice for ESP size >100 ... 200 MB). Oh, good luck to find linux equivalent tool to format a 160KB floppy today, instead of using the old (year 2002) windows-based tool bfi.exe (by Bart Lagerweij).
Title: Re: Bootx64.efi missing?
Post by: nick65go on November 15, 2021, 06:41:53 AM
PS: sorry, correction for FAT12 tool in linux, it is in tcz;
You can build the floppy, lucky is does not need to be MS-DOS bootable, floppy is just a container / image for /EFI/BOOT/BOOTx64.EFI
Code: [Select]
tce-load -iw dosfstools.tcz
dd if=/dev/zero of=fat12.img bs=160K count=1
mkfs.fat -F12 fat12.img
mount -o loop fat12.img /mnt/
The rest for UEFI64 (and even for UEFI32 with small logical changes) still stands up true!
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 28, 2021, 01:18:54 AM
Wow Nick, thanks for the research.  I must admit it's a bit over my head, so it will take some extensive study.

Going OT now, but I'm pursuing the ability to simply archive an image, (say zip / gzip etc), and merely unarchive it to a fat32  drive and have it be bootable without any special handling in regards to "making it bootable" for modern uefi-only machines.

Its what I'm replying on now.  I'm puzzled because it seems only Gparted Live and Porteus have this ability to just unarchive and go afaik. Intriguing, but thanks for all your hard work anyway.  Very useful.
Title: Re: Bootx64.efi missing?
Post by: nick65go on November 29, 2021, 02:32:23 AM
@PDP-8: it is ZERO work to do what you want. Just extract ANY archive you have (tar, gzip, blah bla) into ANY FAT-compatible partition (FAT12/16/32) you already have on a HDD/SDD/USB.

The tricks are:
1. The FAT-compatible partition must have "label" as ESP type. Warning: It is NOT the fdisk "label", neither the UUID. It is another marker (gpart can write it).

2. - your archive must have a /EFI/BOOT/BOOTX64.EFI (to auto boot); or else from FIRMWARE menu of the PC/machine just select the EFI file you want to boot from. This EFI can be anywhere into an ESP partition. BTW: you ca have (and boot from) many ESP partitions on the same HDD. [ignore MS-windows how say just one ESP and to be the first one on HDD, or to be only FAT32).

3. [Optional] You need a "good" FIRMWARE, obeying the UEFI standard, aka: can boot from MBR and GPT disks. Most UEFI64 today take short-cuts, meaning they wrongly see only FAT32 and only GPT disks (blame stupid/ cheap vendors).

FYI: my demo was about ISO (from qemu), or burn ISO on a DVD/CDROM to boot UEFI64 from eltorito standard.
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 29, 2021, 03:47:52 PM
I get it, but Gparted Live and Porteus don't use those flags at all. :)

Getting philosophical here - while we know that TC is not a turnkey-solution, TC -at least for 64 bit intended for modern machines (post 2011 or so), the message that the unbootable iso on modern machines says is that if one is not smart enough to figure it out, or build it yourself from distribution files, your kind is not welcome.  Kind of a convenient barrier to restrict all same old questions from distro-hoppers.  I get it.

What I propose is for 64 bit, is to be kind to the newcomers and remove the iso completely, rather than let less-knowledgeable /users/ who want to follow the true TC way, not beat their heads against the wall trying to make it work on machines that are in the majority now.

Being dramatic, if that is the goal - to raise the bar to just devs, developers, or highly advanced users who could quote the El-Torito and boot specs from the back of their hands, then remove even the 32-bit iso's from being downloaded as well, because we certainly don't want anyone burning an iso from old Windows-For-Workgroups vintage computer with Roxio-cd-deluxe and asking further questions.

See the mixed message here?

Obviously, I love TC.  I have a plethora of ways to run it from the classic diy method to relying on 3rd party front ends.

I'm just worried that unless we acknowledge that uefi machines are here to stay, and make it easier to boot - just as doing so blindly with say the Roxio burner of the long past, it will just become a vintage-computer distribution, with vintage users like myself being the only ones who like it.

/rant over/ Nobody should be offended.  I'm just worried.

Title: Re: Bootx64.efi missing?
Post by: gadget42 on November 29, 2021, 08:39:56 PM
for reference see previous post:

i am most worried about the forum vanishing /forever/

seems like losing this vast store of knowledge might/should be paramount?

again. not. pointing. fingers.

no. offense. intended.

not. a. rant.

Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 30, 2021, 01:18:11 AM
Yeah, and no disrepect to the devs either.  Many years of support starting with the appearance in the DSL forums.

I have a deep sense of gratitude for them hanging in there this long, and answering some of the same decade-old questions.  But they are obviously on a whole different plane than we are. :)

My um, rant, is not to change the direction or focus.  It is just a caution about the iso:

Imagine if DSL started life as a floppy-only distribution, and when CD's came along said no problem, look at the el-torito specs and burn an iso yourself from our floppy images.  Imagine how far that would have gone.

Get a real machine, don't put it on your white-box clone!!!  Plus, CD's are a fad, slam a honest to goodness ST-506 HD in that thing!

Still, at the end of the day, it's just a group of guys doing their thing.  Their house, their show, and if it folded up tomorrow, I'd still be very grateful.
Title: Re: Bootx64.efi missing?
Post by: Juanito on November 30, 2021, 02:19:07 AM
Perhaps the way to go would be to propose a modification to tc-install?
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on November 30, 2021, 03:14:22 PM
Hi Juanito!  I agree wholeheartedly about the proposal.

In fact, that is what I am researching before making any proposal.  So yeah, as a user I'm kind of floundering, but I'm looking for clues.

Any attempt to add a uefi-boot option to the current 64-bit iso needs to be done by someone who actually owns uefi-only hardware.  Not just a VM.  Not just a copy of the uefi specs.  Not just an older box that has csm switchable options.  Basically post-2016 hardware.  Keep it generic.  Ie, don't put a sticker on the release saying "only bootable on Intel NUCS". :)

Example: Netbsd long supported some archaic hardware that nobody actually owned anymore, but it passed their automated compilation toolchain with a tweak here or there.  Then they find out that when someone tried it on *actual hardware*, it hadn't been bootable for 7 or 8 years or more.  (Cobalt?  I'll have to look it up)

Should someone be able to just DD, or use some other method like Gparted Live does it where you can mount an iso (or unarchive and zip) and merely copy files to a preformatted fat32 partition?

As a mere user, I'm trying my best to find options on my own suggest how to make an iso convenient to use in post-2016 hardware for others seeking the true TC path of enlightenment as a user.

If the 64-bit iso won't boot on post 2016 hardware, they certainly aren't going to get to the point of using tc-install for convenience.  And no, not everyone scarfs up aging 32-bit machines to use a proposed improvement to the tc-install.  So we're back to the iso.  If that is to be offerred, that has to be able to bootstrap itself onto modern boxes.

Am I making sense?  Any lurkers out there with skills (and actual uefi-only hardware) much larger than mine that can lend a hand to the project and help see it forward?   Make improvements to tc-install?  Make the iso bootstrappable on it's own?

And coordinate with the devs of course so we aren't turning TC into something else!

So even here as a faithful (L)user, I'm looking at whatever I can do for a possible solution.  Anyone here with dev skills have an answer and want to pitch in with code?
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on December 01, 2021, 02:40:37 AM
Maybe Jason from dCore can shed some light:

I was able to do nothing more than dd Jason's dCorePure64-Stretch iso to a usb drive and it boots on uefi-only boxes just fine.  Only dd works, not simple mount iso / file copy method.  I tested anyway.

What I noticed in comparison to TinyCore:

tinycorepure64  has /EFI/BOOT/efiboot.img

Is there simply a naming issue?  Gosh, I'm so tired I don't have the strength to try and swap Jason's EFI.IMG tonight...

Jason's dCore EFI.IMG is 4096k
TinyCorepure64's efiboot.img is only 1440k

Obviously different system architecture support, but just poked out at me.

Can we reach across the aisle and doublecheck things? :)
Title: Re: Bootx64.efi missing?
Post by: nick65go on December 01, 2021, 06:59:30 AM
Maybe you do not like a standard (UEFI), but it must be obeyed by firmware/manufactures.
It is not useful if a firmware allow you to boot from a FAT32 partition NOT marked as ESP type. Because you can not generalize from these isolated cases that worked for you.

Regarding a good ISO for TC, I think I pointed out that what you need is a /EFI/BOOT/BOOTX64.EFI file (yes capital letters is better), and that BOOTX64.EFI to be a grub with a proper embedded configuration. Maybe ()/ is not enough, maybe you need MULTIPLE paths into that config file; so your grub (inside efiboot.img) search for /, then /cd or /cd0 etc. [Have someone look (with 7zip) inside a Ubuntu grub.efi, to see its embedded config? (written in normal/documented grub syntax?]

The efiboot.img is ONLY for DVD/CDROM.
To allow for easy copy the ISO, the ISO root must have an /EFI/BOOT/BOOTX64.EFI (no embedded config is need) and you COPY the iso into an ESP partition. IF you DD the iso on an HDD you destroy HDD GPT disk type. DD works (with an hybrid ISO- hybrid means boot both BIOS/UEFI) only for a MBR HDD/USB. That is all. Because this BOOTX64.EFI is useful only for USB/HDD booting.
Title: Re: Bootx64.efi missing?
Post by: polikuo on December 01, 2021, 07:55:41 AM
Perhaps the way to go would be to propose a modification to tc-install?

It's insanely difficult to implement UEFI into tc-install.

Reinventing the wheel is actually easier than refactoring.

Plus, some machines may have their own specifications.

Manual install is the proper way if you want to go UEFI.
Title: Re: Bootx64.efi missing?
Post by: PDP-8 on December 01, 2021, 01:56:04 PM
Hi Polikuo!  I've got a suggestion then ...

If we followed how Porteus, Gparted Live, and how SystemRescueCd does it, there is no need for tc-install at all!  For those three systems (so far), all that is really needed is simple file-copying after either unarchiving, or mounting an iso.    (see the off-topic threads)

I have noticed some differences between TC and dCore - perhaps this might help.  From my utility log:

Code: [Select]
ISO analysis:
  Image is an ISO9660 image
  Will use '/boot/isolinux/isolinux.cfg' for Syslinux
  Detected Syslinux version: 4.05/0x4f92e181 (from '/boot/isolinux/isolinux.bin')
  Detected EFI bootloader(s) (from '/EFI/BOOT/efiboot.img'):
  ● 'bootx64.efi'
Disk image analysis:
  Image has an unknown Master Boot Record
  Image is a bootable disk image
ISO label: 'TinyCorePure64'
  Size: 27.7 MB (Projected)
  Note: File on disk is larger than reported ISO size by 888 KB...
  Uses: Syslinux/Isolinux v4.05
  Uses: EFI
Using image: TinyCorePure64-12.0.iso (29 MB)

And for dCore64:
Code: [Select]
ISO analysis:
  Image is an ISO9660 image
  Will use '/isolinux/isolinux.cfg' for Syslinux
  Detected Syslinux version: 6.04/20191223 (from '/isolinux/isolinux.bin')
  Detected EFI bootloader(s) (from '/EFI/BOOT/efi.img'):
  ● 'bootx64.efi'
Disk image analysis:
  Image has an unknown Master Boot Record
  Image is a bootable disk image
  Size: 202.6 MB (Projected)
  Uses: Syslinux/Isolinux v6.04
  Uses: EFI
Using image: dCorePlus-stretch64.iso (204 MB)

So the first thing I see is that a different version of Syslinux/Isolinux is used.
AND, possibly TC's file-size being off by only 888kb.  Maybe enough to matter?

Which makes me wonder if TC's efiboot.img might have missing / corrupted components.  Something awry in the El-Torito build chain?  What's causing that 888kb discrepency and does it even matter?

Title: Re: Bootx64.efi missing?
Post by: PDP-8 on December 01, 2021, 02:46:42 PM
Polikuo - btw, did I forget to say thanks for all your hard work?  I'm still loving your editor too.

So I'm in there slugging it out with ya' from a user standpoint looking for something elusive...

The efiboot.img file being the same size as a floppy got me researching and wondering and looking into El-Torito.  ugh.

I don't know if it's related, but seeing the floppy-image sizes being an option netted me this on stack exchange:


Making me wonder if something in libisofs and the el-torito build-chain is fudging a value to 1.4mb to avoid El-Torito / Xorriso not being able to attach an image.

The only reason it caught my eye is that I don't know if that 888kb discrepency might be pointing to something like this or not.

Excuse my ignorance, I don't know.  I'm just throwing darts.
Title: Re: Bootx64.efi missing?
Post by: nick65go on December 01, 2021, 11:57:14 PM
So the first thing I see is that a different version of Syslinux/Isolinux is used.
AND, possibly TC's file-size being off by only 888kb.  Maybe enough to matter?
Maybe you need a coffee break?
First of all, isolinux is specific to BIOS boot. There is no link/implications for UEFI. And you filled this topic to focus on UEFI64 only machines.
Then an ISO has a sector of 2048 bytes, but a HDD has a sector of 4096 bytes. Oh boy...
https://en.wikipedia.org/wiki/Disk_sector (https://en.wikipedia.org/wiki/Disk_sector)

PS: Did I say Xorriso? NO! So, use mkisofs. Beep beep.. flash flash... Remember UEFI booting from 160 KB floppy? Hard to lean new tricks to an old dog.
Title: Re: Bootx64.efi missing?
Post by: polikuo on December 02, 2021, 07:28:08 AM
It's really just technology evolving.
Modern computer is simply way more resourceful than the old one.
Thus, people invent new ways for booting.

The difference is the size limit, giving UEFI more functionality.
There are machines with a fully functional web browser in UEFI mode.
Boot medium becomes optional.

However, the principles are alike.

Legacy BIOS:
- The mobo (motherboard) reads the first 512 byte (MBR) from a hard drive into the memory and hand over the control to the bootloader. (syslinux/extlinux)
- The bootloader finds a partition marked as bootable.
- Loads the PBR to expand the bootloader for more function.
- Boots the system with a given config. (syslinux.cfg/extlinux.conf)

That's all. Legacy BIOS doesn't do much.

- The mobo starts a UEFI shell.
- It looks for a partition marked as EFI.
- Loads the BOOTX64.EFI
- Boots the system with a given config.