Tiny Core Base > Corepure64
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: ---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).
--- End code ---
Know-how:
--- Code: ---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
--- End code ---
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: ---grub-mkimage -v -d x86_64-efi -O x86_64-efi -o BOOTX64.EFI -p (cd0)/boot/grub part_msdos part_gpt fat iso9660
--- End code ---
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).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version