jaclaz Posted December 2, 2020 Share Posted December 2, 2020 (edited) Quote map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso map to WHAT? jaclaz Edited December 2, 2020 by jaclaz Link to comment Share on other sites More sharing options...
alacran Posted December 2, 2020 Author Share Posted December 2, 2020 (edited) 34 minutes ago, jaclaz said: Now, more than 10 (ten) years have passed (actually almost 15), and we evolved from a very limited boot environment that could only execute a bunch of assembler, consisting ONLY of MBR code, PBR code and bootloader/bootmanagers to a powerful environment that can run *anything* BUT for which essentially only bootloaders/bootmanagers exist (and was it not for our friend PBatard - Author of Rufus among other things - we would also be limited to FAT32 ): https://github.com/pbatard/uefi-ntfs It creates a very small second partition FAT-32 formated at the very end of the device, where the NTFS drivers requiered to boot from NTFS on a UEFI environment are located, so anyway you HAVE a FAT-32 partition to let you boot from the boot files folders located on the NTFS first partition, this drivers make also possible to boot from files folders located on a exFAT partition. In both cases as long as Secure Boot is disabled. alacran Edited December 2, 2020 by alacran Link to comment Share on other sites More sharing options...
alacran Posted December 2, 2020 Author Share Posted December 2, 2020 7 minutes ago, jaclaz said: map to WHAT? jaclaz My mistake, I forgot to map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff) Will fix the mistake and try again and report back. alacran Link to comment Share on other sites More sharing options...
jaclaz Posted December 2, 2020 Share Posted December 2, 2020 (edited) 49 minutes ago, alacran said: It creates a very small second partition FAT-32 formated at the very end of the device, where the NTFS drivers requiered to boot from NTFS on a UEFI environment are located, so anyway you HAVE a FAT-32 partition to let you boot from the boot files folders located on the NTFS first partition, this drivers make also possible to boot from files folders located on a exFAT partition. In both cases as long as Secure Boot is disabled. alacran Sure. the whole point is that the FAT32 is an artificial limitation that has no technical grounds whatoever AND that if a NTFS driver can be written that runs in EFI/UEFI, then *anything* can be written in it AND that the Secure Boot mechanism is a stupid provision, because: 1) it can be worked around nonetheless as you are well aware (see https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface/Secure_Boot ) 2) the signature mechanism is mis-managed by MS (and by the sheepish manufacturers that follow them) AND that - to be a standard - it is pretty much a failure as everyone makes changes to it: https://wiki.archlinux.org/index.php/GRUB/EFI_examples (possibly even in good faith as the specifications are more than 2,000 (two thousand) page long) jaclaz Edited December 2, 2020 by jaclaz Link to comment Share on other sites More sharing options...
alacran Posted December 2, 2020 Author Share Posted December 2, 2020 (edited) Yes, the Secure Boot is good for nothing, computers get Virus with or without it. The name is a fallacy. But it has being very well sold to the masses. It is only good to make money from the developers and OEMs as their software require to be approved and certified by MS, if not the drivers can't run if Secure Boot is enabled. So far at home all PC's HDs are MBR formated, I usually never format any HD as GPT (an unneeded complication for HDs smaller than 2TB), and as I use to Ramboot VHDs a lot by means of SVBus + grub4dos for MBR, all UEFI PCs at home have CSM enabled and Secure Boot disabled permanently. But for now I'm making an exception booting in UEFI just to test this new version, which seems very promising to me, especially now that almost all new machines are UEFI only. By the way tested the corrected entry on menu.lst: Quote title Start /CD/linuxmint-19.3-cinnamon-64bit.iso find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff) chainloader (0xff) It do not work, message: (initramfs) unable to find a medium containing a live file system. Same message we get if we try the map or map --mem commands on the grub4dos for MBR without the especial (cheat) code: Quote iftitle [if exist (hd1,4)/CD/linuxmint-19.3-cinnamon-64bit.iso] Boot linuxmint-19.3-cinnamon-64bit.iso from second internal HD set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso map (hd1,4)%iso_path% (0xff) map --hook root (0xff) kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash -- initrd /casper/initrd.lz So it seems a especial code will be nedded on UEFI environment too. alacran Edited December 2, 2020 by alacran Link to comment Share on other sites More sharing options...
jaclaz Posted December 2, 2020 Share Posted December 2, 2020 (edited) Sure, that is a so-called "cheat-code" or kernel parameters, it has nothing to do with the booting method (BIOS vs. UEFI), it simply tells the kernel where to look for the rest of the system. Those settings could also be put inside the initrd, but of course you would have to rebuild a custom one. Anyway, generally speaking, linux .iso's cannot normally be booted by chainloading the bootsector, which is normally bypassed by the explicit kernel and initrd commands and the cheat-codes, this is not "news" and it is not "peculiar" to the UEFI. Sticky since 2009: http://reboot.pro/topic/8944-boot-any-iso-image-or-boot-all-iso-images/ jaclaz Edited December 2, 2020 by jaclaz Link to comment Share on other sites More sharing options...
alacran Posted December 2, 2020 Author Share Posted December 2, 2020 (edited) I had to adapt a little the usual especial (cheat code) menu entries as map --hook command is not available and/or required on UEFI version of grub4dos, also avoided the use of variables (just in case), but I think using variables will give same results too, I'll test the use of variables latter. Tried this entries on \EFI\grub\menu.lst Quote title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso map --mem /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff) root (0xff) kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=/CD/linuxmint-19.3-cinnamon-64bit.iso quiet splash -- initrd /casper/initrd.lz title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting as Filedisk find --set-root /CD/linuxmint-19.3-cinnamon-64bit.iso map /CD/linuxmint-19.3-cinnamon-64bit.iso (0xff) root (0xff) kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=/CD/linuxmint-19.3-cinnamon-64bit.iso quiet splash -- initrd /casper/initrd.lz Both entries got a successful boot without any issue. So far it seems Linux Live ISOs capables to boot on MBR and/or UEFI, can be booted on UEFI environment just making very minor adaptations to the cheat code used on MBR. alacran Edited December 2, 2020 by alacran Link to comment Share on other sites More sharing options...
alacran Posted December 2, 2020 Author Share Posted December 2, 2020 (edited) In order to test the use of variables I made following entry on \EFI\grub\menu.lst Quote title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso find --set-root %iso_path% map --mem %iso_path% (0xff) root (0xff) kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash -- initrd /casper/initrd.lz The linuxmint-19.3-cinnamon-64bit.iso Live CD booted flawlessly as expected, so this confirms it is also valid to use variables on the grub4dos for UEFI menu.lst, just same as the MBR version. alacran Edited December 2, 2020 by alacran 1 Link to comment Share on other sites More sharing options...
jaclaz Posted December 3, 2020 Share Posted December 3, 2020 What you should try is to add to the menu.lst entry a: map --hook Two possible results: 1) the entry fails because the "unknown" command creates a blocking error 2) the unknown command creates a warning and the entry works nonetheless If this latter, you can use (minus the iftitle ) the same entry on both normal grub4dos and on UEFI grub4dos. jaclaz Link to comment Share on other sites More sharing options...
alacran Posted December 4, 2020 Author Share Posted December 4, 2020 (edited) A new test trying to Ramboot a VHD by means of grub4dos for UEFI: This time I created on my HD a 10x64-WB.vhd, 800 MB VHD inicialized it as MBR, first primary partition is FAT-32 0C Active 64 MB, second partition is NTFS the rest of espace. Then installed on Wimboot mode the Mini-10x64 on NTFS partition by means of wimlib-clc and created manually boot files and folders on Fat-32 partition, and edited both BCDs as on this post to test if it was capable to boot fine, I tested it Rambooting with grub4dos for MBR, and it booted very fine. Then by means of WinImage I made a 10x64-WB.ima file from the VHD, and added following entries on EFI\grub\menu.lst to test if it can be loaded to Ram and check if it was possible to Ramboot it on UEFI: Quote title 10x64-WB.ima SVBus RAMDISK for UEFI boot from HD find --set-root /VHD/10x64-WB.ima map --mem /VHD/10x64-WB.ima (hd) chainloader (hd-1) title 10x64-WB.ima SVBus RAMDISK for UEFI boot from HD find --set-root /VHD/10x64-WB.ima map --mem /VHD/10x64-WB.ima (hd) chainloader (hd-1,0) I got same result with both, the IMA file was loaded to Ram very fine, and it started booting as I was able to see the dots moving in circle, but it wasn't able to totally boot and a few time latter I got the BSOD: INACCESSIBLE BOOT DEVICE alacran Edited December 4, 2020 by alacran Typo Link to comment Share on other sites More sharing options...
alacran Posted December 4, 2020 Author Share Posted December 4, 2020 On 12/3/2020 at 3:45 AM, jaclaz said: What you should try is to add to the menu.lst entry a: map --hook Two possible results: 1) the entry fails because the "unknown" command creates a blocking error 2) the unknown command creates a warning and the entry works nonetheless If this latter, you can use (minus the iftitle ) the same entry on both normal grub4dos and on UEFI grub4dos. jaclaz I'm able to MBR or UEFI boot, from internal HDs or USB device, MBR menu.lst is on the root of the disk and my UEFI menu.lst is on EFI\grub\menu.lst, as no entry on both menu.lst is shared between MBR and UEFI versions, there is no gain in doing what you suggest, also the developer/author very clearly stated which commands are not available on UEFI version, then it is better to use the right syntax on each case, and don' start trying to twist it. By the way as I found on my very first test, the iftitle do not work on UEFI version, but forgot to comment it. alacran Link to comment Share on other sites More sharing options...
jaclaz Posted December 4, 2020 Share Posted December 4, 2020 38 minutes ago, alacran said: I'm able to MBR or UEFI boot, from internal HDs or USB device, MBR menu.lst is on the root of the disk and my UEFI menu.lst is on EFI\grub\menu.lst, as no entry on both menu.lst is shared between MBR and UEFI versions, there is no gain in doing what you suggest, also the developer/author very clearly stated which commands are not available on UEFI version, then it is better to use the right syntax on each case, and don' start trying to twist it. By the way as I found on my very first test, the iftitle do not work on UEFI version, but forgot to comment it. alacran Sure, as if copy/paste was not a thing. Besides, one could use n .lst files and have in menu.lst each entry ponting to a specific "other" .lst. Example (BIOS /menu.lst): title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst configfile /CD/linuxmint-19.3-cinnamon-64bit.lst Example (UEFI EFI/grub/menu.lst): title Start /CD/linuxmint-19.3-cinnamon-64bit.iso booting from the ISO loaded on Ram find --set-root /CD/linuxmint-19.3-cinnamon-64bit.lst configfile /CD/linuxmint-19.3-cinnamon-64bit.lst linuxmint-19.3-cinnamon-64bit.lst title linuxmint-19.3-cinnamon-64bit.iso set iso_path=/CD/linuxmint-19.3-cinnamon-64bit.iso map (hd1,4)%iso_path% (0xff) map --hook root (0xff) kernel /casper/vmlinuz file=/cdrom/preseed/linuxmint.seed boot=casper iso-scan/filename=%iso_path% quiet splash -- initrd /casper/initrd.lz And of course this would be useful for my personal approach (COSMIAS, which noone else uses BTW) with "embedded" batch and self-mounting (JFYI): http://reboot.pro/topic/17807-release-cosmias-a-new-approach-to-g4d-images/ 38 minutes ago, alacran said: By the way as I found on my very first test, the iftitle do not work on UEFI version, but forgot to comment it. Yep. jaclaz Link to comment Share on other sites More sharing options...
alacran Posted December 5, 2020 Author Share Posted December 5, 2020 (edited) Just to confirm if there could be something wrong during the creation of the IMA file from the VHD file on my previous post, I decided to test it Rambooting on the grub4dos MBR version, using following commands on my vhd.lst, (just to keep more order), which is called by the menu.lst on root of the partition/drive: Quote title 10x64-WB.ima.lz4 - from HD 144 MB - SVBus RAMDISK for MBR boot find --set-root /VHD/10x64-WB.ima.lz4 map --top --mem /VHD/10x64-WB.ima.lz4 (hd) map --hook root (hd-1,0) chainloader /bootmgr title 10x64-WB.ima - from HD 800 MB - SVBus RAMDISK for MBR boot find --set-root /VHD/10x64-WB.ima map --top --mem /VHD/10x64-WB.ima (hd) map --hook root (hd-1,0) chainloader /bootmgr And it Rambooted very fine on MBR version, this confirms nothing was wrong during making an IMA file from the VHD file. Then the BSOD: INACCESSIBLE BOOT DEVICE got when using UEFI version is related to something else, I guess the current intent on this third version of grub4dos for UEFI to find/locate on memory the IMA the second (NTFS) partition/drive by means of translating/relocating the SVBus driver info to info that can be valid/used on UEFI environment is not working fine yet. @jaclaz Hi my friend. As you can see I make use of several different *.lst files called by the MBR menu.lst, just didn't mentioned it (this way) on my previous post for simplicity, I'm also aware the internal menu.lst of grub4dos for MBR can be modiffied very easy with BootIce if required to point to find the external main menu.lst on other location or to a renamed *.lst file. But as I have readen, to do same thing on the UEFI version it has to be done on the source code, and recompile it. Anyway IMHO we should respect the guidances from the author/developer about what commands are valid or not on this new version. alacran Edited December 5, 2020 by alacran Link to comment Share on other sites More sharing options...
alacran Posted December 5, 2020 Author Share Posted December 5, 2020 Just for testing pourposes, (as I do not see any practical use for it), I created a 900 MB VHD, inicialized it as MBR, single partition FAT-32 0C, and extracted there the content of my Win10XPE_x64.ISO (843 MB), only excluded the CDUsb.y file to let it find on internal HDs the partition where it is contained. Made following entrie on \EFI\grub\menu.lst: Quote title Win10XPE_x64.vhd SVBus RAMDISK for UEFI boot from HD find --set-root /VHD/Win10XPE_x64.vhd map --mem /VHD/Win10XPE_x64.vhd (hd) chainloader (hd-1) The VHD was loaded to Ram very fine and it booted flawlessly, this confirms the grub4dos for UEFI is working very fine. Then my statement on previous post is valid: Quote I guess the current intent on this third version of grub4dos for UEFI to find/locate on memory the IMA second NTFS partition by means of translating/relocating the SVBus driver info to info that can be valid/used on UEFI environment is not working fine yet. I can say only issues pending to solve are Rambooting VHDs when using SVBus driver, and load to RAM big size VHDs (2+ GB). In fact I don't know which it the actual size limit to load on Ram some item, so far a 2.3 GB VHD or IMA file is not loaded, it reports not enought Ram, but I was able to load and boot from Ram linuxmint-19.3-cinnamon-64bit.iso which size is 1.89 GB, based on this I assume the limit is currently about 2 GB. alacran Link to comment Share on other sites More sharing options...
alacran Posted December 5, 2020 Author Share Posted December 5, 2020 (edited) New version available: Quote New version: http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a_for_UEFI-2020-12-05/ This new version is capable to UEFI Ramboot my 800MB Wimboot Mini-10x64 as VHD or as IMA: A big thanks to yaya, a1ve, and all other developers involved on this great achievement. Quote title 10x64-WB.vhd SVBus RAMDISK for UEFI boot from HD -1 find --set-root /VHD/10x64-WB.vhd map --mem /VHD/10x64-WB.vhd (hd) chainloader (hd-1) title 10x64-WB.ima SVBus RAMDISK for UEFI boot from HD -2 find --set-root /VHD/10x64-WB.ima map --mem /VHD/10x64-WB.ima (hd) chainloader (hd-1) But the 2.3 GB Mini-10x64 Compact mode installed did not boot as VHD or as IMA file: Quote title 10x64-UEFI.vhd SVBus RAMDISK for UEFI boot from HD find --set-root /VHD/10x64-UEFI.vhd map --mem /VHD/10x64-UEFI.vhd (hd) chainloader (hd-1) title 10x64-UEFI.ima SVBus RAMDISK for UEFI boot from HD find --set-root /VHD/10x64-UEFI.ima map --mem /VHD/10x64-UEFI.ima (hd) chainloader (hd-1) Message is still the same: (hd0,1) Out of memory boot_image_handle not found Press any key to continue.... NOTE: Both, the 800 MB Wimboot and the 2.3 GB Compact mode, where installed on NTFS second partition, and boot files/folders are on first 64 MB FAT-32 0C partition (active to also be MBR bootable) of the (MBR inicialized) VHD or IMA. See pictures of sample BCDs attached on this post. From my previous post: Quote In fact I don't know which it the actual size limit to load on Ram some item, so far a 2.3 GB VHD or IMA file is not loaded, it reports not enought Ram, but I was able to load and boot from Ram linuxmint-19.3-cinnamon-64bit.iso which size is 1.89 GB, based on this I assume the limit is currently about 2 GB. Then only issue remaining is: Load to RAM VHD or IMA files bigger than 2 GB. alacran Edited December 5, 2020 by alacran Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now