Bootx64.efi missing?

[nick65go]

@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.

[PDP-8]

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.

[PDP-8]

Forgot:

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.

[nick65go]

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).
Know-how:

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).

[nick65go]

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"
http://forum.tinycorelinux.net/index.php/topic,23912.msg151130.html#msg151130

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).

[nick65go]

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!

[PDP-8]

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.
 

[nick65go]

@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.

[PDP-8]

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.

[gadget42]

for reference see previous post:
http://forum.tinycorelinux.net/index.php/topic,24873.msg162202.html#msg162202

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.

peace.

[PDP-8]

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.

[Juanito]

Perhaps the way to go would be to propose a modification to tc-install?

[PDP-8]

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.

Proposal:
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)

DESIGN
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?

STRUGGLING
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.

Chicken-and-egg
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?

[PDP-8]

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:

dCore has /EFI/BOOT/EFI.IMG
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?

[nick65go]

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.