alacran

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

In order to test the use of variables I made following entry on \EFI\grub\menu.lst 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

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

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: 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: So it seems a especial code will be nedded on UEFI environment too. alacran

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

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

The UEFI version is also capable to load to Ram files compressed as *.gz or *.lz4, same as the MBR version does, just tested with the following menu.lst entries: The grub4dos for UEFI \EFI\Boot\BOOTX64.EFI (renamed to g4ex64.efi) is located on MBR (hd1, 0) which has a FAT-32 0C Primary partition where the EFI files/folders reside, of course during UEFI booting the HDs order is swap and becomes (hd0,0) as it is the only UEFI capable (seen then as first HD). All of them were loaded to Ram and booted very fine. But linuxmint-19.3-cinnamon-64bit.iso didn't boot fine, I used this entry to try to boot it: alacran

No, this is only valid to run under UEFI environment, so to try to run something, it has to be UEFI capable. And as jaclaz just said DOS is not UEFI capable. IMHO in fact the name is not really appropiate, also many people on wuyou.net forum think same way, some of them have suggested to rename it to grub4efi or grub4uefi. Almost all code has being rebuild and many features do not exists anymore, some because they do not apply on UEFI environment and other because haven't being developed yet, as an example it lacks map --mem --top command, very useful to Ramboot VHDs (having SVbus driver installed) on MBR/CSM machines; from the author on Release Notes: Basically I think there isn't any technical reason to keep using the name grub4dos since almost all code is totally different. So far the only commands (shared with MBR version) I have tested are: find --set-root, map, map --mem, commandline, reboot and halt. Keep using the grub4dos name creates a lot of confussion, also some people has suggested to rename the menu.lst config file to menu.efi. or efi.menu, but just putting it on \EFI\grub\menu.lst lets us avoid confussion in this case. This UEFI version can't be installed on MBR or PBR, do not require to use the grld file, also there is not a file grldr.mbr file which allowed us to run grub4dos from the MS bootmgr on MBR/CSM machines, and the grub.exe file that was used to run grub4dos from grub2 do not exists anymore. On the UEFI version only the BOOTX64.EFI (on \EFI\Boot\BOOTX64.EFI [which I renamed to g4ex64.efi to let it coexists with the MS bootx64.efi]) and the menu.lst files located on a FAT-32 partition are required. To run it from grub2 on UEFI environment I use: if [ "${grub_platform}" == "efi" ]; then if [ -e "/efi/boot/g4ex64.efi" ]; then menuentry "grub4dos for UEFI" { chainloader /efi/boot/g4ex64.efi } fi And to go back to grub2 we can use: exit_g4d alacran

I decided to run another test, this time the VHD is located into VHD folder on the root of the second (MBR) NTFS primary partition of the second internal HD. Using this menu.lst entries (usefull also to check if Gziped files can be loaded to Ram as in the MBR version). No luck, with any of both options for the VHD, I got this message (See attached picture): (hd0,1) Out of memory boot_image_handle not found Press any key to continue.... My comments about the message: (hd0,1) Seems OK, this means the VHD was located, since I'm booting from the only valid UEFI device and the VHD is located then on (hd0,1). Out of memory this is not possible, something is wrong here, this PC has 8 GB of Ram and the VHD is only 2.3 GB boot_image_handle not found I don't understand the meaning of this message. NOTE: Sorry for the photo quality, it was made with the celphone. alacran

Hi my friend, nice to see you around. Excuseme but I don't see how grub4dos for UEFI may be required for that pourpose, to start it is not Secure Boot capable. To do what you want IMHO you may try just creating first all the required NTFS partitions and use WinNTSetup to install the OS on each partion and let it create or edit (as required) the BCD entries for each location, also BootIce could be usefull to edit those entries names to easy diferenciate each one. When you run WinNTSetup the Hidden and with no letter ESP partition is then visible as Z: and then you can use BootIce to edit the Z:\EFI\Microsoft\Boot\BCD, before close WinNTSetup, other option is PartitionGuru which let you assing a temporary letter to the Hidden ESP partition. Or even easier just make VHDs or VHDXs with different names and use WinNTSetup to install the OS on each one and let it create or edit (as required) the BCD entries for each location. alacran

My testing results with the grub4dos-0.4.6a_for_UEFI-2020-11-26: I created a fixed size 2.3 GB VHD (unformated) on a partition of my internal HD, initialized it as MBR, then formated as Win 6.x MBR, first partition is 128 MB FAT-32 0C Active, and second is NTFS (the rest of the espace), by means of wimlib-clc I installed (on Compact LZX mode) the Mini-10-x64 on NTFS partition and created manually the Boot Files/folders on the FAT-32 partition, and edited both BCDs with BootIce, See attached pictures), latter made a new Ramboot entry on old menu.lst (for grub4dos for MBR) as usuall for the VHD located on internal HD: title 10x64-UEFI.vhd - SVBus RAMDISK - 2.3 GB - map as (hd) for MBR boot find --set-root --ignore-floppies /10x64-UEFI.vhd map --top --mem /10x64-UEFI.vhd (hd) map --hook root (hd-1,0) chainloader /bootmgr It booted very fine, not a single issue, so this confirms a VHD with 2 partitions (having boot files/folders on FAT-32 partition) is capable to Ramboot very fine (at least when MBR booting). So far I have being able to UEFI boot Win10XPE_x64.ISO from internal HD or USB, this is my very simple menu.lst (good to start testing with the minimum features): NOTE-1: CSM and Secure Boot are disabled, menu.lst is located on: \EFI\grub\menu.lst; \images\Win10XPE_x64.ISO is on FAT-32 partition; 10x64-UEFI.vhd is on the root of a NTFS partition, BOOTX64.EFI from grub4dos for UEFI was renamed to g4ex64.efi and copied to: \EFI\Boot\g4ex64.efi and an alternative UEFI boot option pointing to it was created on UEFI using BootIce, used when booting from internal HD, not required when booting from USB Win10XPE_x64.ISO boots very fine with no issues from USB or internal HD 10x64-UEFI.vhd do not boot from USB or internal HD, even if using (hd0,1), (hd1,1) or (hd2,1)/10x64-UEFI.vhd, it looks like the NTFS partitions can't be accessed/readen by grub4dos for UEFI. NOTE-2: This were all MBR partitions, but also tried making a GPT partitioned USB device and botting from it got same results, 10x64-UEFI.vhd is not found on the GPT NTFS of this USB. Also noticed the entry: title shutdown halt Makes the PC reboot not shutdown alacran

NOTE: First post was updated with new version released today a few hours ago. ChangeLog_UEFI.txt translated to English with Google Translate for your convenience, also attached: And this is a sample menu.lst translated to English with Google Translate for your convenience, also attached: alacran ChangeLog_UEFI-Eng.txt Sample-menu-Eng.lst

JFYI There is a new version of grub4dos for UEFI, made by yaya, this is his third version: http://grub4dos.chenall.net/downloads/grub4dos-0.4.6a_for_UEFI-2020-11-26/ yaya's post on http://bbs.wuyou.net/forum.php?mod=viewthread&tid=422652 Please remember this is a work in progress so it is an experimental version. This new grub4dos for UEFI was developed by yaya, so in no way I'm involved on it's development, but I think this thread deserves to be on this section of the forum just because the relevance of the subject. I made that desition because unfortunately the author hasn't opened a topic on this forum. Hope this desition is fine with forum admins. On this topic we will talk about the experiences with this new version, as not all the usual commands work on this version. So far our fellow wimb was able to sucessfully UEFI boot Win10XPE_x64.ISO, from internal HD and also from a USB device, hope he will share his experiences with all of us. alacran

Also this may be useful: USB 3.x/XHCI Generic driver for Win7 and Vista alacran

Yes, it boots fine as Filedisk from internal HD and also from USB device, and my old 7x64 VHD also did, but I don't keep the 7 VHD anymore. Maybe you should try making the first 7 installation (using a VHD native bootable version) on a VHD located on a USB device, as long as the VHD and the Boot files/folders will be on a USB device, then WinNTSetup will take care to make all required modifications to load the USB drivers on appropiate timing, (this is based on cdob old commands [valid for USB 2.0 and USB 3.0 if available] made long time ago), You will see on WinNTSetup the option for Enable Native USB Boot on Windows 7 on the very last window just before starting to install, see attached picture, but this will be present only if installing on a USB device, if doing the installation this way USB boot watcher is not necessary. My WimbootCompress.ini is the same we have being using, attached if you want to confirm. My 8.1 x64 VHD (and the old 7 VHD I deleted) also has installed diskmod filter driver so it is able to see all USB removable drives as fixed disks, then it is capable to see all flash drives partitions, just as 10 does now. Attached for your convenience (including also a version signed by Paraglider long time ago). alacran WimBootCompress.zip diskmod.zip

Why? Is it a restriction coded into the program? I have an old 8.1 x64 Compact Mode 8K VHD (made with your old Mini8 program) and it boots fine as Filedisk. alacran

All comments from Jaclaz on previous post are totally right. But I would like to add something else, If you are using any of the Compact mode on all the drive or some of your folders (new compression available starting from Win10) 4K, 8K, 16K or LZX, if the compressed files contained on the drive or into a folder are moved in same drive, the files will not lose the compression, but if they are copied to same drive or another drive (even located on same HD) they will be copied uncompressed, highly increasing the used espace, then in this escenario it will be allways better to defragment the drive (this is a move procedure) and don't copy any folder that may content Compact mode compressed files. alacran

This are the FREE tools I usually use: To remove unwanted Apps and some caracteristics of Win10, or also install some redistributables as DirectX, .Net framework, etc, and also add some tricks on your install.wim Index(s), before install, see: MSMG ToolKit. To install and also add some tricks, see: WinNTSetup To add usefull links to PC context menu, see: http://reboot.pro/topic/22323-compact-mode-installs/page-2#entry215558 To have more control on Telemetry and Updates, see: O&O ShutUp10. And finally to control incoming and outgoing connections, see: Firewall App Blocker (Fab) alacran

@ZhuMa Thanks, just replacing the file C:\Windows\System32\drivers\exfat.sys with your version, and 10x64-19H1 booted fine. Just a question: Does 10 v2004 not require a modded driver? alacran

@ZhuMa 10x86-19H1 boots fine installed on a exFAT drive at usuall speed, but 10x64-19H1 booting is very slow. I can't download the exFAT driver for x64 mentioned on your procedure, without it x64 booting is very slow, Could you please load it to Mediafire? Thanks in advance alacran

For people using WinPEs this info may be usefull: From: http://reboot.pro/topic/22333-useful-info-for-winpes-wimboot-and-compact-installs/#entry215752

I found this and I think it may be intersting for some people:

I saw this and I think it may be interesting for all people that still want/like to use this old systems:

In no way you are ignorant, I never thought or said that. In fact I have learned many thing from your info and also from your precise links and I appreciate that a lot. It is only that in this case related to standard Intel heatsinks my info is more accurate than yours. About the other subject, you forced me to give you that info with this comment. Your friend alacran

Well my friend, just to let you know I'm a retired Mechanical and Electrical Engineer and took thermodynamics during 3 years on College. I repair PCs as a hobby since more than 20 years ago, even long before I was retired. And all Intel processors (wich come with heatsink and fan included into the box) I have installed in the last 20+ years blow air to the heatsink with no exception, but nevertheless if the user changed the heatsink, it usually comes with the fan installed, and if he removed the fan and put it back, it's very improbable to put it on the wrong direction as there is a sticker on the top side of the fan with all fan datas as RPM, Volts, Amperes; also the holes for the screws are usually deeper on the top side, making almost impossible to put it in the wrong direction, but better take a look to the attached picture of a Pentium 4 Socket 478 Heat Sink. From: https://store.cwc-group.com/pe4so478remo1.html I remember long time ago the AMD processors were sold without heatsink and you had to buy it separately, but they also came with the fan installed. alacran