Open mrjrt opened 8 years ago
grub4dos does not support UEFI booting, so it would not work when UEFI-booting The grub4dos map command is useless as soon as you MBR boot to an OS like Windows or linux because the mapping is lost when it's own drivers are loaded. Further, you can have FAT32+NTFS for UEFI booting as used by Rufus.
Further, you can have FAT32+NTFS for UEFI booting as used by Rufus.
Indeed. Rufus should be able to create an NTFS bootable UEFI drive, through UEFI:NTFS. You can set a blank UEFI:NTFS drive in Rufus by doing the following:
Once you have done just that, you should have an UEFI bootable NTFS drive. All that's needed then is copy a /efi/boot/bootx64.efi
or /efi/boot/bootia32.efi
bootloader on the NTFS partition, that can handle your images, such as GRUB 2.0 or Syslinux (both of which, I believe, offer an UEFI bootloader), or even your own UEFI boot application.
The UEFI/FAT32 side of things is more for having a stick that can be booted in multiple ways. I've not reached that point yet, but it is my cursory understanding that certain modern OSes will only boot that way so at that point I would not want to use G4D when trying to boot them, hence the desire to have a disk that boots either way. I'd rather not discover it won't work a long way down the road, hence the desire to keep things as simple as possible at the base level of partitions and filesystem support as ideally I'd like to just have the one stick and not risk it becoming corrupted due to buggy 3rd party filesystem drivers. Incidentally, I've read in my research that NTFS is terrible for flash media as it's very noisy with its metadata - hence the preference for FAT32 and exFAT. The old OSes one might wish to install can't be guaranteed to support exFAT, so a fallback to FAT32 is unavoidable.
Finally, the map command is far from useless - Firadisk and WinVBlock provide windows drivers that enable Windows to continue to use the virtual disks after the switch to protected mode, I'm using these and they work fabulously.
As stated in the request, the only issue blocking G4D from handling these large ISOs on a simple standard setup is the filesystem filesize limitation, which I suspect could be worked around reasonably easily.
4GB limit of FAT is always a headache. If we want to create a G4D flash disk carrying large images while being a compatible FAT drive, we should partition it. One partition is FAT on which G4D is installed and containing other necessary boot stuff (like "easy2boot"); The other is NTFS containing ISO or HDD images. As you know, G4D can be easily configured to find its images from another partition, however there are notes: 1- Windows mounts only the first usable partition of a flash disk; Thus, we have to assign most of its capacity to the first partition, else, major capacity won't be available to us under windows. 2- If we also connect this flash to TV/satellite receivers (for recording/playing), or car/home players, its large partition should be FAT, else, major capacity won't be available for that purpose.
If one wants to satisfy both of these requirements, should make the first partition as a large FAT, followed by a NTFS large enough to accommodate the desired images, but not too larger, because usually its extra space won't be used. Copying images to that NTFS partition requires linux or a special utility under windows (I don't know). The partition having G4D should be active because non-EFI BIOSes rely on MBR and MBR boots the active partition. Exception is when GRUB is installed on MBR (or both MBR and BS).
Grub4DOS is largely used for building boot disks, and the current trend is to store these on flash sticks with multiple disk images on them as the modern equivalents of digital swiss army knives. Flash storage is now available in huge capacities, and this leads to reduced pressure to minimise the size of these disk images.
To clarify, I'm referring to the "map" command in g4d, i.e.
Unfortunately, the UEFI standard mandates FAT32 for booting from removable storage, and this places a limit on disk file sizes to one byte less than 4GB, which makes a full DVD ISO of 4.3GB unable to be stored on such a partition. The alternatives are to switch to NTFS or exFAT, but then UEFI won't boot the media.
So, given the only real legitimate reason to have files > 4GB is large disk images, it makes sense to simplify things by supporting split images to sidestep the issue. The code just needs to maintain an in-order short list of file parts, and when the block request comes in divide the block number by the part size to see which file to reference, and mod the block number by the part size to get the offset.
I'd have a stab at coding it myself, but I've several large projects on the go at the minute, so I'm just going to leave this here and work around it in the meantime. :)