USB-ZIP *almost* works on uefi-only install!

[PDP-8]

So I'm hacking on TinyCorePure64 when I should be sleeping.  Everyone is sick of it, but I can't stop.  Just throwing out some data points.

Environment:  TinyCorePure64 up and running - by hook or by crook.
Computer: Modern UEFI-ONLY, no legacy/csm options.
Installer:  TC-GUI installer.
Source of distribution files:  "download from web - 64 bit"

While watching my so-called bios, I used the TC installer itself to create additional boot drives several times.  Results:

Frugal - not recognized as bootable.
USB-HDD - not recognized as bootable.

USB-ZIP - BOTH PARTITIONS recognized as bootable!

Unfortunately, allowing the system to boot from either partition singly, or in a fall-through combination one to the other, results in being dropped to the UEFI shell prompt.  Not a grub prompt, but the uefi shell.

I found that very interesting that the bios on my machine even recognized the partitions when using USB-ZIP as bootable - but alas it never made it past the uefi-shell.

going horizontal now ..... ZZZZzzzzz

[PDP-8]

Addendum:

Noticed that most other distros that DO get recognized and boot use lower-case for the EFI/boot directory, and not EFI/BOOT as TC does.

I know we've researched that in the past and that it shouldn't matter.  Other than the case, what that case change to lower case implicates, I don't know.

I'll rip into the iso and also the TC-gui installed versions and try to see what's up.

[curaga]

FAT32 is case insensitive.

[polikuo]

By default, UEFI bootloaders are installed in FAT32 filesystem.
Some machine do support other types of filesystem, but the FAT32 is a standard.
I believe the logic is, when a UEFI supported motherboard sees a FAT32 partition, there's a good chance it can find a bootloader (since nobody really use FAT32 for storage nowadays), thus the mobo would check for specific files (UEFI firmware) to boot.
For example, with SYSLINUX, the path should be /path/to/the/disk/EFI/BOOT/BOOTX64.EFI
If nothing is spotted, the machine halts with uefi-shell.

[nick65go]

Recognized FAT32 format only on a ESP partion for UEFI, means that it is the fault of former Microsoft's domination and the laziness of UEFI firmware. UEFI standard reconize any FAT. Even Rufus docs say it can be any format type. UEFI FIRWMARE is the key. And the alliance Microsoft-Intel for America first domination shows us the consequences.

FYI: In my laptop I made few ESP partitions, one is FAT16 and UEFI see it. and boot it In Qemu UEFI I can boot from iso, with Floppy emulation in FAT12 mode (yes is a 360 KB FDD). And GPT HDD format is not mandatory, UEFI can boot from MRB HDD.Sometime you could choose wrong the manufacture of UEFI, and ready-made tc-tools not working by-default. But without fear to dirty your hands the problem can be solved. You know what samurai says .. live by the sword - die by the sword.

[PDP-8]

Hi Polikuo!  First, many thanks for writing the installer extensions.  Great interface, clean and for the most part self-explanatory.  Like the little tool-tip popus and watching the whole process in action.  Neat.

Problem is, I know just enough to get myself into trouble on the 64 bit side.  32-bit, no sweat.

What drives me a bit batty though is that for whatever reason, the 64-bit installer seems to elude me on my uefi-only machines.  (or those that have been purposely disabled for legacy/csm)

What I can do:

1) I can gather filesystem and bootloading tools and make my own 64-bit TC.  Juanitos expert advice in a thread from years ago really helped.  Although I do NOT make mine multi-arch.

2) I can use Ventoy as a crutch to boot the tinycorepure64 iso and work that way.

3) I can shoe-horn the distribution files into Porteus' syslinux bootloader with no trouble either.

I can't figure out where me or the 64-bit installer is going wrong.  Mostly me for sure, but I am stumbling on something dumb on my end.

Wonder if the installer is setting up for multi-arch on the 64 bit side, and that's triggering the efi-shell barf?  Saw that the installer was refactored for multi-arch and that got me thinking, but I'm probably throwing darts.

I haven't thrown in the towel, because I really LIKE using your installer otherwise!

[PDP-8]

P.S. - I don't know if this is normal or not ..

When using the USB-ZIP option (two fat32 partitions), I noticed that the resulting syslinux.cfg file is totally empty, whereas the extlinux.conf files created in the other options (frugal, usb-hdd) are populated.

I could edit that no problem, but that darn efi shell dropout occurs first.

[polikuo]

Hi Polikuo!  First, many thanks for writing the installer extensions.

When using the USB-ZIP option (two fat32 partitions), I noticed that the resulting syslinux.cfg file is totally empty, whereas the extlinux.conf files created in the other options (frugal, usb-hdd) are populated.

I didn't invent the installer, the credit is not mine.
I just refactored the script and program for bug fix, 64-bit support and some other stuff.
Besides, the installer does not support UEFI.
I've thought about implementing, but decided not to.
It would break the installer entirely.

I'm not familiar with USB-ZIP, so I never touch that part of the code.
IIRC, it's a special booting mechanic for some old motherboards.
Only the quirkiest mobo would be limited to ONLY that method.
Most motherboards support more than one methods for booting.
Frugal mode should work on most machines you'll ever try on.

[PDP-8]

Wow, thank you for your contribution to the code anyway!  That's what it's all about.

AND, thank you for the confirmation that the installer doesn't handle UEFI in the first place, and is not a bug.  Now I can move forward.

Making your own stick the classic way (again, tnx Juanito!) is always the best way to go, but now I don't feel guilty using other tools or methods either.  That's what's absolutely great about TC's flexibility.

Rock on you guys!