Jump to content


  • Posts

  • Joined

  • Last visited

  • Donations

  • Country


Everything posted by alacran

  1. 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: 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: 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
  2. 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: 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
  3. 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
  4. 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
  5. 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
  6. 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
  7. 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
  8. 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
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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
  17. Also this may be useful: USB 3.x/XHCI Generic driver for Win7 and Vista alacran
  18. 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
  19. 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
  20. 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
  21. 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
  22. @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
  23. @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
  24. For people using WinPEs this info may be usefull: From: http://reboot.pro/topic/22333-useful-info-for-winpes-wimboot-and-compact-installs/#entry215752
  25. I found this and I think it may be intersting for some people:

  • Create New...