Jump to content

alacran

Member
  • Content Count

    306
  • Joined

  • Last visited

  • Donations

    $0.00 

Community Reputation

67 Excellent

About alacran

Profile Information

  • OS
    Windows 7 x64

Recent Profile Visitors

3,420 profile views
  1. There is no rush my friend, take your time, and maybe better waith for new UEFI grub4dos version. By the way as I read grub2 of a1ve do not have that problem since the begining because it is coded to find the EFI on FAT-32 first and FORCE to load it, only when it is not present there, it looks for it on NTFS partition. That's way you were able to boot from it and not from G4E when you had the compressed EFI on NTFS partition. alacran
  2. Yes, that sound fine, I usually make the VHDs from Win10XPE_x64, as it boots as Trusted Installer, there is no problem to remove the x-Boot and x-EFI, but it's better if they are not created, in fact I deleted them and bootmgr and BOOTNXT files before make a new recaptured WIM file, but so far they were created and renamed every time I use VHD_WIMBOOT. It will be good if they are not recreated anymore, as in any future new version approach are also unnecessary. Hope reboot.pro will be online soon. EDIT: Thanks for correcting me, I will take care of not commit that mistake aga
  3. Attached the Wof status, my incredulous friend. alacran WOF_Status_L_EFI_2020-12-29_04-46-37.7z
  4. New version working very fine. Go to my issue Report: https://github.com/chenall/grub4dos/issues/248 Almost at the very end of it you will find a message from yaya, download the BOOTX64.rar.txt, delete the .txt and extrac the new version, he allready implemented the map -- mem --top and now it is possible to load files to the top memory just as on MBR version I just tested it Rambooting a 2 partition VHD of 2.3 GB and it booted very fine. I assume it will be officially released very soon. alacran
  5. Having the VHD attached, I created the boot files/folders with this command bcdboot L:\Windows /s K: /f ALL and latter edited the BCDs with BootIce. alacran
  6. Just to make sure it was not an issue created by a possible mistake I committed, I deleted all the VHDs used for testing since 2020-11-26 version and created a new 900 MB Win10XPE_x64.vhd FAT-32 single partition VHD just extracting the ISO to it, and also a 1088 MB 2 partitions Mini-10-UEFI-WB.vhd (WimBoot VHD), both are booting fine but the virtual Floppies, CDs and VHDs are present too on this new Mini-10-UEFI-WB.vhd. If Rambooting Mini-10-UEFI-WB.vhd on MBR all is fine (no virtual devices on it), then there is no dubt they are created by the UEFI version of grub4dos during loading to R
  7. It seems I found the possible cause of the issue: Once Rambooting from a 2046 MB (just 2 MB smaller than 2 GB) VHD there are 3 virtual floppy drives (A:, B: and M:) + 2 virtual CDs (N: and O:) + 2 VHDs (they appear as un-inicialized) all of them related to SVBus, see attached pictures please. I don't have any resolution set on my menu.lst, after Rambooting and once on desktop the OS resolution is very low and it can't be changed. alacran
  8. Just made a 2046 MB VHD with same partition layout and installed on Compact LZX mode my Mini-10x64 on it and it Rambooted flawlessly on UEFI, This probes I was right when I said there is a 2 GB limit imposed to items loaded on Ram on versions grub4dos-0.4.6a_for_UEFI-2020-11-26 and 2020-12-05 I opened an issue on https://github.com/chenall/grub4dos/issues Related to can't map --mem more than 2 GB on Ram: https://github.com/chenall/grub4dos/issues/248 alacran
  9. New version available: 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. But the 2.3 GB Mini-10x64 Compact mode installed did not boot as VHD or as IMA file: 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 part
  10. 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
  11. 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 o
  12. 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
  13. 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
  14. 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
  15. 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
×
×
  • Create New...