Jump to content











Photo

a1ive's GRUB 2

grub2 uefi mbr

  • Please log in to reply
38 replies to this topic

#1 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 29 December 2020 - 07:17 AM

I decided to open this topic to talk here about this Fork of GRUB 2 made by a1ive (on reboot.pro forum) or wintoflash (on wuyou.net forum).

 

We all here on the forum are more familiar with the use of grub4dos, especially its old MBR version, but this fork of grub2 has many new features added by his author and it is extremely useful too.

 

Official page on github is: https://github.com/a...rub/tree/latest

 

Fork of GRUB 2 to add various features.

See the file INSTALL for instructions on how to build and install the GRUB 2 data and program files.

Extra modules: https://github.com/a1ive/grub-extras

Download: https://github.com/a1ive/grub/releases

Manual: https://a1ive.github.io/grub2_zh.html

 

NOTE: To create the grubia32.efi, grubx64.efi and core.img files just run the build_grub.bat file included into grub2-latest.tar.gz download.

You can find my English translation of his Manual made using Google translate here on this post:

 

To make things easier for other members and future readers I translated a1ive Grub2 Manual to English by means of Google translate.

 

I hope a1ve do not mind, but I though there is very good info in the Manual and it deserves to be translated to English and shared here.

 

alacran

Attached Files zip.gif  GRUB 2 Manual by a1ve-docx .7z   63.85KB

 

And I didn't know but the good steve6375 already translated the manual:

 

steve already translated the manual a long time ago. https://www.rmprepus...ive-grub2-notes

 

Also there is an interesting topic about Disk emulation under GRUB2 UEFI-GRUB2 on: http://bbs.wuyou.net...3&extra=&page=1

 

 

wintoflash

This post was last edited by wintoflash at 2020-12-10 11:24


The content of this post is no longer updated. Those who are willing to improve can send PR and issue to GitHub.
-------------------------------------------------- ---------------------

grub2 download:
https://github.com/a...ases/tag/latest
If the download is slow, use http://gitd.cc/to download
Instructions:

    map [--pause] [--mem] [--type=CD|HD|FD] FILE
        -m, --mem load into memory
        --rt specifies that the memory disk will not be released after the operating system is loaded
        -l, --blocklist force conversion to blocklist format writable disk
        -t, --type specify the virtual disk type
             --type=CD is designated as a CD, the block size is 2048
             --type=HD specifies the hard disk, the block size is 512
             --type=FD specifies a floppy disk, the block size is 512
        -o, --ro disable virtual disk writing support
        -e, --eltorito=DISK also specify the drive letter to mount the El Torito image
        -n, --nb do not start immediately after loading the virtual disk
        -g, --no_g4d Do not write GRUB4DOS map information to memory
        -f, --first make the device the first in the disk list


Example:

    #When the virtual disk type is not specified, map will automatically determine the disk type.
    map /winpe.iso
    #Load to memory If it is a net start, please use this parameter
    map --mem --type=CD /wepe_64.iso
    #Load a disk/partition as a virtual disk
    map --type=HD (hd0)
    #Load VHD file.
    map --mem --rt (hd1,4)/ramos.vhd.xz


Example custom command:

    grub-mkimage -d x86_64-efi -p /boot/grub -o grubx64.efi -O x86_64-efi acpi affs afs all_video bfs bitmap bitmap_scale blocklist boot bsd btrfs cat chain cmp commandline configfile cpio crc date datehook edd disk efi dm_puga echo efifwsetup efiload eval exfat expr ext2 extcmd f2fs fat fb file font fshelp getenv getkey getkey gfxmenu gfxterm gfxterm_background gfxterm_menu gptsync gzio halt hashsum help hexdump hfs hfs hfsplus iso9660 jfs jpeg keystatus legacy lvmboot multiboot normal lvmdisk lvmboot lvm-icfg iso9660 jfs linux miniac keystatus legacy lcm ntfs part_apple part_bsd part_gpt part_msdos partnew parttool png probe progress raid5rec raid6rec random read reboot regexp reiserfs sbpolicy search setenv shell sleep squash4 syslinuxcfg tar terminal terminfo test tga time true udf vhd wimhd video_colors videoio x video map xnu wimfs video_colors video_fb xnu xnu video map


Note:
  Hard disk mirroring supports MBR partition table and GPT partition table.
Thanks:
Refer to the code of the following projects, thanks to the open source of the relevant authors.
http://bbs.wuyou.net...read&tid=414814
http://www.lab-z.com/stu132rd
https://gitlab.com/J...rub2eh/tree/wip
https://github.com/tianocore/edk2
https://sourceforge....rojects/gnu-efi
https://github.com/ipxe/wimboot
Source code:
https://github.com/a1ive/grub
License Agreement: GPL v3
This topic was added stamp by liuzhaoyzz at 2020-4-10 10:24, recommended by moderators

 

I hope the author a1ive, has some free time to come to this topic to answer your questions, as I'm new in grub2 and I may not be able to help you very much.

 

Your friend

 

alacran


  • liuzhaoyzz likes this

#2 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 29 December 2020 - 07:43 AM

Test UEFI booting from a RamOS (Compact LZX and Wimboot mode) using the -l parameter:

 

From this post: http://reboot.pro/to...-10#entry217503

 

 

582#,http://bbs.wuyou.net/forum.php?mod=redirect&goto=findpost&ptid=417233&pid=4205481&fromuid=298214

 

Quote

If there is no fragment in the file, you can add -l parameter and convert it into blocklist format to speed up reading. If the file is fragmented, it may or may not work.

wintoflash

 

I personally measured the parameter -l, and the 7gb vhd was loaded into memory. The results are as follows:

 

1. Put sx70211.vhd on sata ssd, and there is no fragment.

It takes 1 minute and 23 seconds from 0 to 100% without -l parameter.

menuentry "SX70211.vhd-svbus" "/VHD/SX70211.vhd" {

        efiload /EFI/grub/ntfs_x64.efi

        search --no-floppy --set --file $2

        map --mem --rt $2

}

 

With the -l parameter, it takes 23 seconds.

menuentry "SX70211.vhd-svbus-l" "/VHD/SX70211.vhd" {

        efiload /EFI/grub/ntfs_x64.efi

        search --no-floppy --set --file $2

        map --mem --rt -l $2

}

 

2、 Put sx70211.vhd on the mechanical hard disk, wincontig shows four fragments, and under g4e, blocklist shows three fragments. It takes 1 minute and 13 seconds to change from 0 to 100% without -l parameter. Adding -l parameter from 0 to 100% takes 1 minute and 03 seconds. G4e took 1 minute and 11 seconds.

menuentry "SX70211.vhd-svbus-l" "/VHD/SX70211.vhd" {

        efiload /EFI/grub/ntfs_x64.efi

        search --no-floppy --set --file $2

        map --mem --rt -l $2

}

 

My conclusions:

1. If vhd has no fragments, adding -l parameter will greatly improve the reading speed.

2. If there are fragments in vhd, it is not too much to increase the reading speed by adding -l parameter, but it is accelerated by 10 seconds on the mechanical hard disk. After adding -l parameter, there is almost no difference between the reading speed and that of g4e (there may be card table error); The fragmented ssd has not been tested.

3. Whether there are fragments or not, whether it is direct map or map --mem with -l parameter is feasible.

Therefore, the final conclusion is that grub2' s map is best added with -l parameter.

 

Oh,er...This thread is talking about g4e,but I talk about grub2,it seems digress...


Edited by liuzhaoyzz, Yesterday, 07:48 PM.

 

I tried to make some test using the -l parameter but it didn't work for me.

 

This menuentry works very fine (without the -l parameter):

menuentry "Boot /VHD/Mini-10-UEFI-WB.vhd (FAT+NTFS) UEFI RAMDISK 1330 MB" "/VHD/Mini-10-UEFI-WB.vhd" {
  search --no-floppy --set --file $2
  map --mem --rt $2
}

But following menuentry with the -l parameter do not load to Ram:

menuentry "Boot /VHD/Mini-10-UEFI-WB.vhd (FAT+NTFS) UEFI RAMDISK 1330 MB" "/VHD/Mini-10-UEFI-WB.vhd" {
  search --no-floppy --set --file $2
  map --mem --rt -l $2
}

Also got same results with:

menuentry "Boot /VHD/Mini-10-UEFI.vhd (NTFS) UEFI RAMDISK 2 GB" "/VHD/Mini-10-UEFI.vhd" {
  efiload /EFI/grub/ntfs_x64.efi
  search --no-floppy --set --file $2
  map --mem --rt -l $2
}

menuentry "Boot /VHD/Mini-10x64-2004-2.vhd (FAT+NTFS) UEFI RAMDISK  2.3 GB" "/VHD/Mini-10x64-2004-2.vhd" {
  search --no-floppy --set --file $2
  map --mem --rt -l $2
}

The Mini-10-UEFI-WB.vhd is a Wimboot mode installation and the other two are Compact LZX mode installations, it seems the -l parameter do not like Wimboot or Compact mode installations or perhaps needs more info, tried adding the parameter --type=HD, to see if it may help but with same result:

menuentry "Boot /VHD/Mini-10-UEFI.vhd (NTFS) UEFI RAMDISK 2 GB" "/VHD/Mini-10-UEFI.vhd" {
  efiload /EFI/grub/ntfs_x64.efi
  search --no-floppy --set --file $2
  map --mem --rt -l --type=HD $2
}

I can see it loads ntfs_x64.efi and try to alocate espace for Mini-10-UEFI.vhd, but it never starts loading and the keyboard is dead, and I had to reboot the PC.

 

Any ideas/suggestions?

 

alacran



#3 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 30 December 2020 - 12:47 AM

Test UEFI booting from a RamOS (NTFS Compressed) using the -l parameter:

 

Just for testing pourposes I made a Mini-10x64 installation on a 3.7 GB VHD (fixed size) 2 partitions (FAT-32 Active 64 MB + NTFS the rest), the second partition is NTFS Compressed, free space on the NTFS partition is only 383 MB, so it is a little tight. Fully defragmented internally after deploy the OS.

 

The intention of this tests was to check if the Compact LZX and Wimboot mode were the cause of the failure on the tests documented on my previous post.

 

Unfortunatelly my limited Ram (8GB) do not let me try to boot from a uncompressed RamOS.

 

I will appreciate if some other member with a PC with more Ram can test booting from a uncompressed RamOS with and without the -l parameter and document the time required to load to Ram on both cases, this -l parameter (if working for you) will increase the loading speed and will substantially reduce the time required to load to Ram.

 

Additionally if you can boot using the -l (-L but lowercase) parameter on your PC, this can be a good indicative that it do not work fine with compressed installs.

 

So even if I can't make use of that parameter on my PC, the info from your test will be very usefull for other users.

 

Menu entries tested to boot the RamOS:

menuentry "Boot /VHD/10x64.vhd (FAT+NTFS) UEFI RAMDISK 3.7GB" "/VHD/10x64.vhd" {
  search --no-floppy --set --file $2
  map --mem --rt $2
}

menuentry "Boot /VHD/10x64.vhd (FAT+NTFS) UEFI RAMDISK 3.7GB" "/VHD/10x64.vhd" {
  search --no-floppy --set --file $2
  map --mem --rt -l $2
}

First menuentry without -l parameter booted very fine.

 

Second menuentry with -l parameter didn't load to Ram, and the keyboard didn't respond anymore, it was required to reboot.

 

See attached pictures.

 

NOTE: From a1ive's post

 

blocklist does not support any kind of compression, including all formats of compressed files and NTFS compression.

I don't know what vhd-wimboot or vhd-compact is, but the following two things must be met to convert to blocklist disks.
1. the VHD file cannot be compressed.
2. the file system where the VHD file is located cannot have any kind of compression.

 

alacran

Attached Thumbnails

  • 10x64-NTFS-Compression.jpeg
  • VHD.png

Edited by alacran, 30 December 2020 - 06:29 AM.


#4 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 51 posts
  •  
    China

Posted 30 December 2020 - 02:03 AM

Good navigation post!
Thank you!

  • alacran likes this

#5 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 51 posts
  •  
    China

Posted 30 December 2020 - 02:34 AM

 

 

 it seems the -l parameter do not like Wimboot or Compact mode installations or perhaps needs more info
Oh,I didn't try to boot vhd-wimboot or vhd-compact mode once.I'm not very interested in vhd-wimboot or vhd-compact mode.
I tested boot vhd to RAM without compress mode.It run fine.My test is not sufficient.
Maybe you can try to boot xxx.vhd.xz to RAM like this:
menuentry "Boot /VHD/Mini-10-UEFI-WB.vhd (FAT+NTFS) UEFI RAMDISK 1330 MB" "/VHD/Mini-10-UEFI-WB.vhd.xz" {
  search --no-floppy --set --file $2
  map --mem --rt -l $2
}

Edited by liuzhaoyzz, 30 December 2020 - 02:38 AM.


#6 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 30 December 2020 - 03:37 AM

 

Oh,I didn't try to boot vhd-wimboot or vhd-compact mode once.I'm not very interested in vhd-wimboot or vhd-compact mode.
I tested boot vhd to RAM without compress mode.It run fine.My test is not sufficient.
Maybe you can try to boot xxx.vhd.xz to RAM like this:
menuentry "Boot /VHD/Mini-10-UEFI-WB.vhd (FAT+NTFS) UEFI RAMDISK 1330 MB" "/VHD/Mini-10-UEFI-WB.vhd.xz" {
  search --no-floppy --set --file $2
  map --mem --rt -l $2
}

 

blocklist does not support any kind of compression, including all formats of compressed files and NTFS compression.

I don't know what vhd-wimboot or vhd-compact is, but the following two things must be met to convert to blocklist disks.
1. the VHD file cannot be compressed.
2. the file system where the VHD file is located cannot have any kind of compression.

Edited by a1ive, 30 December 2020 - 03:42 AM.

  • liuzhaoyzz likes this

#7 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 30 December 2020 - 03:57 AM

 

blocklist does not support any kind of compression, including all formats of compressed files and NTFS compression.

I don't know what vhd-wimboot or vhd-compact is, but the following two things must be met to convert to blocklist disks.
1. the VHD file cannot be compressed.
2. the file system where the VHD file is located cannot have any kind of compression.

 

Well, this is the info I was looking for, directly from the author of this improved version of grub2.

 

alacran


  • liuzhaoyzz likes this

#8 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 30 December 2020 - 05:10 AM

Tests UEFI booting from a RamOS (Wimboot mode installed) xz Compressed

 

In fact the xz compression is stronger than lz4 compression used when booting from MBR grub4dos and now on UEFI grub4dos.

 

To have an idea of how powerfull can be the xz compression I made following comparative:

 

Mini-10-UEFI-WB.vhd  >>> Uncompresed size is 1.29 GB

 

Mini-10-UEFI-WB.vhd.lz4  >>>  LZ4 Compresed size is 146 MB

 

Mini-10-UEFI-WB-N.vhd.xz  >>>  XZ Normal compressed with 7-zip size is 84.3 MB

 

Mini-10-UEFI-WB-M.vhd.xz  >>>  XZ Maximum compressed with 7-zip size is 80.4 MB

 

Mini-10-UEFI-WB-U.vhd.xz  >>>  XZ Ultra compressed with 7-zip size is 79.1 MB

 

All of them boot fine and the time required to load them to Ram is in no way as fast as loading a lz4 compressed file using UEFI grub4dos wich is only 4.31 seconds, but it is very reazonable.

 

In order to compare, this is quoted from: http://reboot.pro/to...-10#entry217481

 

Secure Boot = Disabled        CSM = Auto

Mini-10-UEFI-WB.vhd (FAT-32+NTFS)  1330 MB Grub2 >>> 28.94 sec.

Mini-10-UEFI-WB.vhd (FAT-32+NTFS)  1330 MB Grub2 + grub4dos >>> 15.08 sec.

Mini-10-UEFI-WB.vhd (FAT-32+NTFS)  1330 MB grub4dos >>> 15.00 sec.

Mini-10-UEFI-WB.vhd.lz4 (FAT-32+NTFS)  1330 MB Grub2 + grub4dos >>> 4.28 sec.

Mini-10-UEFI-WB.vhd.lz4 (FAT-32+NTFS)  1330 MB grub4dos >>> 4.31 sec.

 

i used following menuentries on grub2.cfg file:

menuentry "Boot /VHD/Mini-10-UEFI-WB-N.vhd.xz (FAT+NTFS) UEFI RAMDISK 1330 MB" "/VHD/Mini-10-UEFI-WB-N.vhd.xz" {
  search --no-floppy --set --file $2
  map --mem --rt $2
}

menuentry "Boot /VHD/Mini-10-UEFI-WB-M.vhd.xz (FAT+NTFS) UEFI RAMDISK 1330 MB" "/VHD/Mini-10-UEFI-WB-M.vhd.xz" {
  search --no-floppy --set --file $2
  map --mem --rt $2
}

menuentry "Boot /VHD/Mini-10-UEFI-WB-U.vhd.xz (FAT+NTFS) UEFI RAMDISK 1330 MB" "/VHD/Mini-10-UEFI-WB-U.vhd.xz"{
  search --no-floppy --set --file $2
  map --mem --rt $2
}

The loading to Ram times were from 16.3 to almost 17 seconds, the stronger the compression the longer the time.
 

When using xz compression (LZMA2 compression) the chunk size on Normal is 64 MB, on Maximum is 128 Mb and on Ultra is 256 MB and this affects a lot the compression time, and do not give a substantial benefit in loading to Ram speed, that would correspond with the time invested during compression. So IMHO is is better to do not invest very much time during compression and just use Normal and the compression time will be acceptable, for that case it took here about 4+ minutes, but of course this will vary depending of your PC characteristics.

 

In this case apply xz compression to a 1.3 Gb Wimboot VHD improved the load to Ram time from 28.94 to 16.3 seconds, reducing the time by 12.64 seconds or 43.67 %, so this works fine in the case of Wimboot installations on VHD.

 

But if the OS on the VHD was installed on Compact mode, it is better DO NOT apply the xz compression to our VHDs as I found that increased the time to load on Ram by a big amount.

 

From post: http://reboot.pro/to...-10#entry217492

 

Mini-10x64-2004-2.vhd (FAT-32+NTFS) 2.3 GB Grub2 >>> 50.89 sec.

Mini-10x64-2004-2.vhd.xz (FAT-32+NTFS) 2.3 GB Grub2 >>> time to load on Ram 70.63 seconds.

 

In this case the free espace into the VHD represents a less percentage than in the case of same OS installed in Wimboot mode, where majority of files are just pointers with zero size, and the free space is bigger in percentage.

 

alacran



#9 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 30 December 2020 - 05:38 AM

.....

I don't know what vhd-wimboot or vhd-compact is, .....

 

A VHD Wimboot or Wimboot VHD is a VHD where the OS was installed in Wimboot mode, (this started on Win 8.1 update 1), for more info about Wimboot installations see: https://docs.microso...-boot--wimboot-

 

A VHD Compact or Compact VHD is a VHD where the OS was installed in Compact mode, (this started on Win 10), for more info about Compact installations see: https://docs.microso...ktop/compact-os

 

alacran



#10 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 51 posts
  •  
    China

Posted 30 December 2020 - 07:35 AM

I personally measured the parameter -l, and the 7gb vhd was loaded into memory. vhd is not compressed(Without wimboot/compact).The results are as follows:

 

1. Put sx70211.vhd on sata ssd, and there is no fragment.

Without the -l parameter, It takes 1 minute and 23 seconds from 0 to 100%.

menuentry "SX70211.vhd-svbus" "/VHD/SX70211.vhd" {

        efiload /EFI/grub/ntfs_x64.efi

        search --no-floppy --set --file $2

        map --mem --rt $2

}

 

With the -l parameter, it takes 23 seconds.

menuentry "SX70211.vhd-svbus-l" "/VHD/SX70211.vhd" {

        efiload /EFI/grub/ntfs_x64.efi

        search --no-floppy --set --file $2

        map --mem --rt -l $2

}

 

 

With the -l parameter, SX70211.vhd.xz 1.38GB,it takes 3 minutes and 18 seconds!But it boot fine.

menuentry "SX70211.vhd.xz-l" "/VHD/SX70211.vhd.xz" {
        efiload /EFI/grub/ntfs_x64.efi
        search --no-floppy --set --file $2
        map --mem --rt -l $2
}

 

Without the -l parameter, SX70211.vhd.xz 1.38GB,it takes 3 minutes and 18 seconds!But it boot fine.

menuentry "SX70211.vhd.xz-l" "/VHD/SX70211.vhd.xz" {
        efiload /EFI/grub/ntfs_x64.efi
        search --no-floppy --set --file $2
        map --mem --rt $2
}
 
So,the fastest combination is to load to RAM with -l parameter,vhd without any compression,including the files in vhd,and outside the vhd.Do not compress the xxx.vhd into xxx.vhd.xz.
 

Edited by liuzhaoyzz, 30 December 2020 - 08:00 AM.

  • alacran likes this

#11 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 30 December 2020 - 08:47 AM

Results on using -l parameter:

 

Mini 10x64 in MBR 2 Partition Fixed VHD located on internal SSD GPT and booting with UEFI Grub2 from RAMDISK

- Apply      Normal   in    6GB load into RAM in 118 sec - same using -l parameter load into RAM in 13 sec

- Apply Compact LZX in 3GB load into RAM in   75 sec - same using -l parameter load into RAM in 24 sec

 

Mini 10x64 in MBR 2 Partition Fixed VHD located on USB SSD MBR and booting with UEFI Grub2 from RAMDISK

- Apply      Normal   in    6GB load into RAM in 155 sec - same using -l parameter load into RAM failed - RECOVERY missing /damaged system file (wrong message)

- Apply Compact LZX in 3GB load into RAM in   78 sec - same using -l parameter load into RAM in 23 sec

 

Interesting Compact LZX Windows in VHD can be loaded into RAM using -l parameter

 

Apply Normal in VHD failed to load into RAM from USB SSD using -l parameter



#12 wimb

wimb

    Platinum Member

  • Developer
  • 3756 posts
  • Interests:Boot and Install from USB
  •  
    Netherlands

Posted 30 December 2020 - 09:58 AM

NOTE: To create the grubia32.efi, grubx64.efi and core.img files just run the build_grub.bat file included into grub2-latest.tar.gz download.

 

 

The grubx64.efi in this way created expects \boot\grub\grub.cfg as configfile so that UEFI Grub2 config file is located inside Microsoft MBR Boot folder.

 

A better location is \grub\grub.cfg as used in USB_FORMAT and UEFI_MULTI and VHD_WIMBOOT

 

In that case grubx64_real.efi is used in UEFI Secure booting Grub2 and made with 

 

build_grub_usb.bat

@echo off
cd /d "%~dp0"

echo i386-efi
set /p modules= < arch\ia32\builtin.txt
grub-mkimage.exe -d i386-efi -p /grub -o grubia32_real.efi -O i386-efi %modules%

echo x86_64-efi
set /p modules= < arch\x64\builtin.txt
grub-mkimage.exe -d x86_64-efi -p /grub -o grubx64_real.efi -O x86_64-efi %modules%

echo i386-pc
set /p modules= < arch\legacy\builtin.txt
grub-mkimage.exe -d i386-pc -p /grub -o core.img -O i386-pc %modules%


UEFI_USB_2020-12-26_101643.jpg


#13 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 30 December 2020 - 10:40 PM

Yes my friend, in fact I use your build_grub_usb.bat if a new build is required.

 

I became a little more familiar with the build_grub.bat and build_grub_usb.bat, just by comparing each other.

 

You forgot to mention where the future readers can find build_grub_usb.bat:

 

\UEFI_MULTI\UEFI_MAN\grub_a1\build_grub_usb.bat and \USB_FORMAT\UEFI_MAN\grub_a1\build_grub_usb.bat

 

Going a little further, we may also edit the files builtin.txt, located on all folders into arch directory depending of our needs, in case we may require to add additional features to our build, selecting from the features located on folders: arm64-efi, arm-efi, i386-efi, i386-multiboot, i386-pc and x86_64-efi

 

As an example:

 

Yaya was asking me to run lsefimmap command from grub2 to get some info about the memory use, and it is not available on standard builds.

 

Then I remembered a liuzhaoyzz post related to add efiload feature to grub2, booted from Win10XPE_x64, and made a new buid after just adding the word lsefimmap (without the .mod extension) to the builtin.txt located on x86_64-efi

 

It could be good to have a full list of the features included on the mentioned folders and their use, I will take a look on a1ive's Manual to see if the info is available there. 

 

alacran



#14 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 31 December 2020 - 12:24 AM

Results on using -l parameter:

....

Interesting Compact LZX Windows in VHD can be loaded into RAM using -l parameter

 

Well, on my tests a Compact LZX OS in a VHD can't load to Ram using the -l parameter.

 

The author says that parameter do not work on any kind of compressed VHD.

 

But you were able to boot from it. Why???

 

I have no doubt of your statement, but I think this requires a further analysis to try to find the conditions that make that possible in your case.

 

I saw you booted from internal and USB SSD units.

 

Before think the PC firmware is the main cause.  I think we may try to find out if the Mass Storage Devices are the cause, as how its internal software shows its physical/logical sectors, and all their content, to the Bios and/or the UEFi firmware and by extension to grub2 could be the cause of your successful test.

 

On my fail intents the VHD was located on second partition of a rotational Sata II second HDD, sector size 512 bytes physical/512 bytes logical.

 

Do you have a spare rotational HDD?  If so please test booting from it.

 

In the main time I will try loading the VHD from my first HDD, which sector size is 4 kB physical/512 bytes logical.

 

alacran



#15 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 31 December 2020 - 09:17 AM


In the main time I will try loading the VHD from my first HDD, which sector size is 4 kB physical/512 bytes logical.

 

alacran

 

It didn't load to Ram from this HD too.

 

alacran



#16 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 31 December 2020 - 10:52 AM

Also tried from a USB device and same result, It didn't load to Ram.

 

alacran



#17 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 31 December 2020 - 12:29 PM

I think this tools (excluding unifont.hex.gz) can be also useful  for you when using a1ive's grub2:

 

From: http://reboot.pro/to...-10#entry217539

 

This are some useful tools we may add to our UEFI grub4dos:

 

ntfs_x64.efi (NTFS driver): From refind-cd-0.11.4.zip: https://sourceforge....d/files/0.11.4/

 

CrscreenshotDxe.efi (to make screenshots): https://github.com/L...CrScreenshotDxe

 

EfiGuardDxe.efi [to disable PatchGuard and Driver Signature Enforcement (DSE)]: https://github.com/Mattiwatti/EfiGuard

 

unifont.hex.gz (Colection of fonts): Taken from the very well known Easy to Boot (E2B) by steve6375 (hope he doesn't mind as E2B is free software)

 

For your convenience I put all on a Zip file attached, including a README.txt with some samples of use.

 

alacran

Attached Files zip.gif  Useful tools.zip   693.69KB

 

Just remember on grub2 the command is efiload XXXX

 

alacran



#18 liuzhaoyzz

liuzhaoyzz

    Member

  • Members
  • 51 posts
  •  
    China

Posted 01 January 2021 - 04:49 AM

Yes my friend, in fact I use your build_grub_usb.bat if a new build is required.
 
I became a little more familiar with the build_grub.bat and build_grub_usb.bat, just by comparing each other.
 
You forgot to mention where the future readers can find build_grub_usb.bat:
 
\UEFI_MULTI\UEFI_MAN\grub_a1\build_grub_usb.bat and \USB_FORMAT\UEFI_MAN\grub_a1\build_grub_usb.bat
 
Going a little further, we may also edit the files builtin.txt, located on all folders into arch directory depending of our needs, in case we may require to add additional features to our build, selecting from the features located on folders: arm64-efi, arm-efi, i386-efi, i386-multiboot, i386-pc and x86_64-efi
 
As an example:
 
Yaya was asking me to run lsefimmap command from grub2 to get some info about the memory use, and it is not available on standard builds.
 
Then I remembered a liuzhaoyzz post related to add efiload feature to grub2, booted from Win10XPE_x64, and made a new buid after just adding the word lsefimmap (without the .mod extension) to the builtin.txt located on x86_64-efi
 
It could be good to have a full list of the features included on the mentioned folders and their use, I will take a look on a1ive's Manual to see if the info is available there. 
 
alacran

Just have a look at command.lst in grub2.tar.gz,the modules and the commands are in it.You can open it with windows notepad.exe.

F:\bak\grub2\grub2-latest2020-12-29\x86_64-efi\command.lst,like below:

 

*acpi: acpi

*all_functional_test: functional_test
*background_image: gfxterm_background
*blocklist: blocklist
*bls_import: blscfg
*blscfg: blscfg
*btrfs-get-default-subvol: btrfs
*btrfs-list-subvols: btrfs
*cat: cat
*chainloader: chain
*clear_menu: normal
*cmp: cmp
*cpuid: cpuid
*cputemp: cpuid
*crc: hashsum
*cryptomount: cryptodisk
*date: date
*dd: dd
*dp: dp
*echo: echo
*efi_connect_all: efiload
*efiload: efiload
*efiusb: dp
*expr: expr
*extract_syslinux_entries_configfile: syslinuxcfg
*extract_syslinux_entries_source: syslinuxcfg
*file: file
*fucksb: sbpolicy
*functional_test: functional_test
*getargs: getargs
*getenv: getenv
*getkey: getkey
*gettext: gettext
*gptprio.next: gptprio
*grubfm: grubfm
*grubfm_about: grubfm
*grubfm_cat: grubfm
*grubfm_get: grubfm
*grubfm_hex: grubfm
*grubfm_open: grubfm
*grubfm_set: grubfm
*halt: halt
*hashsum: hashsum
*hdparm: hdparm
*help: help
*hexdump: hexdump
*hiddenentry: normal
*html_list: grubfm
*inb: iorw
*ini_get: ini
*inl: iorw
*inw: iorw
*isotools: map
*keystatus: keystatus
*kfreebsd: bsd
*knetbsd: bsd
*kopenbsd: bsd
*list_env: loadenv
*load_env: loadenv
*loadfile: memrw
*loopback: loopback
*ls: ls
*lsacpi: acpi
*lspci: lspci
*lua: lua
*map: map
*md5sum: hashsum
*menuentry: normal
*mkinitrd: newc
*nes: nes
*ntboot: ntboot
*partnew: partnew
*pcidump: pcidump
*pop_env: normal
*probe: probe
*rand: uuid
*rdmsr: rdmsr
*read_byte: memrw
*read_dword: memrw
*read_word: memrw
*regexp: regexp
*reset: reboot
*save_env: loadenv
*sbpolicy: sbpolicy
*search: search
*serial: serial
*setenv: setenv
*setkey: setkey
*setpci: setpci
*sha1sum: hashsum
*sha256sum: hashsum
*sha512sum: hashsum
*shell: shell
*sleep: sleep
*smbios: smbios
*stat: stat
*strconv: conv
*submenu: normal
*submenu_exit: normal
*syslinux_configfile: syslinuxcfg
*syslinux_source: syslinuxcfg
*terminfo: terminfo
*test_blockarg: test_blockarg
*testspeed: testspeed
*tetris: tetris
*tr: tr
*trust: pgp
*uuid4: uuid
*verify_detached: pgp
*vhd: loopback
*videomode: videoinfo
*wimboot: wimboot
*wimtools: wimboot
*zfskey: zfscrypt
.: configfile
[: test
alias: alias
appleloader: appleldr
authenticate: normal
background_color: gfxterm_background
backtrace: backtrace
badram: mmap
bcfg: bcfg
boot: boot
break: normal
btrfs-info: btrfs
btrfs-mount-subvol: btrfs
cat: minicmd
cbmemc: cbmemc
checktime: date
clear: normal
commandline: commandline
configfile: configfile
continue: normal
coreboot_boottime: cbtime
cp: fatfs
crc32: crc
cutmem: mmap
decrement: increment
distrust: pgp
dump: minicmd
efi-export-env: efienv
efi-load-env: efienv
eval: eval
exit: minicmd
export: normal
extract_entries_configfile: configfile
extract_entries_source: configfile
extract_legacy_entries_configfile: legacycfg
extract_legacy_entries_source: legacycfg
fakebios: loadbios
false: true
fix_video: fixvideo
fixmmap: fixmmap
fwsetup: reboot
gptrepair: gptrepair
gptsync: gptsync
help: minicmd
hexdump_random: random
increment: increment
initrd16: linux16
initrd: linux
initrdefi: linuxefi
keymap: keylayouts
kfreebsd_loadenv: bsd
kfreebsd_module: bsd
kfreebsd_module_elf: bsd
knetbsd_module: bsd
knetbsd_module_elf: bsd
kopenbsd_ramdisk: bsd
legacy_check_password: legacycfg
legacy_configfile: legacycfg
legacy_initrd: legacycfg
legacy_initrd_nounzip: legacycfg
legacy_kernel: legacycfg
legacy_password: legacycfg
legacy_source: legacycfg
linux16: linux16
linux: linux
linuxefi: linuxefi
list_trusted: pgp
loadbios: loadbios
loadfont: font
lscoreboot: cbls
lsefi: lsefi
lsefienv: getenv
lsefimmap: lsefimmap
lsefisystab: lsefisystab
lsfonts: font
lsmmap: lsmmap
lsmod: minicmd
lssal: lssal
macppcbless: macbless
mactelbless: macbless
mkdir: fatfs
module2: multiboot2
module: multiboot
mount: fatfs
mouse_test: efi_mouse
mousectl: ps2mouse
multiboot2: multiboot2
multiboot: multiboot
mv: fatfs
nativedisk: nativedisk
net_add_addr: net
net_add_dns: net
net_add_route: net
net_bootp6: net
net_bootp: net
net_del_addr: net
net_del_dns: net
net_del_route: net
net_dhcp: net
net_efi_add_addr: efi_netfs
net_efi_bootp6: efi_netfs
net_efi_bootp: efi_netfs
net_efi_ls_addr: efi_netfs
net_efi_ls_cards: efi_netfs
net_efi_ls_routes: efi_netfs
net_get_dhcp_option: net
net_ipv6_autoconf: net
net_ls_addr: net
net_ls_cards: net
net_ls_dns: net
net_ls_routes: net
net_nslookup: net
normal: normal
normal_exit: normal
nthibr: nttools
ntversion: nttools
outb: iorw
outl: iorw
outw: iorw
parttool: parttool
password: password
password_pbkdf2: password_pbkdf2
play: play
read: read
read_file: read
reboot: reboot
rename: fatfs
return: normal
rm: fatfs
rmmod: minicmd
search.disk_uuid: search_disk_uuid
search.file: search_fs_file
search.fs_label: search_label
search.fs_uuid: search_fs_uuid
search.part_label: search_part_label
search.part_uuid: search_part_uuid
setparams: normal
setup_var2: setup_var
setup_var: setup_var
setup_var_3: setup_var
shift: normal
source: configfile
terminal_input: terminal
terminal_output: terminal
test: test
testload: testload
time: time
touch: fatfs
true: true
type: alias
umount: fatfs
unalias: alias
usb: usbtest
version: version
videoinfo: videoinfo
videotest: videotest
write_byte: memrw
write_bytes: memrw
write_dword: memrw
write_file: fatfs
write_word: memrw
wrmsr: wrmsr
xnu_uuid: xnu_uuid
zfs-bootfs: zfsinfo
zfsinfo: zfsinfo
 

Edited by liuzhaoyzz, 01 January 2021 - 05:02 AM.

  • alacran likes this

#19 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 01 January 2021 - 05:29 AM

Thanks liuzhaoyzz

 

Your info is wellcome as always.

 

EDIT: When I wrote this Post the edited post from liuzhaoyzz was not yet loaded here on my location, I apologize if I'm repeating something already mentioned on previous post.

 

For new users (as myself) of this grub2 version:

 

To be a little more especific about the location of the command.lst mentioned by our good friend liuzhaoyzz:

 

Once we download the last version of grub2-latest.tar.gz and fully extact it, we go to following path to find the x64 list that will be the more interesting for us:  \grub\x86_64-efi\command.lst of course on each one of this folders there is the respective list too: arm64-efi, arm-efi, i386-efi, i386-multiboot, i386-pc and x86_64-efi

 

I recommend to open it with Notepad++ to can read it fine on Windows environment, if you don't do it this way it is almost impossible to read and understant its content.

 

Hope this can be useful for new users of a1ive's GRUB 2 (as myself).

 

alacran


Edited by alacran, 01 January 2021 - 07:05 AM.


#20 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 01 January 2021 - 10:21 PM

I think this info deserves to be quoted here as it is related in some way to a1ve's grub2 and may be useful.

 

From: http://reboot.pro/to...-10#entry217552

 

This are good news for people as myself with only 8GB of Ram, yaya2007 made a new test version named as BOOTX64_ok.rar.txt and uploaded it here.

 

This version allowed me to boot a 2.5 and also a 3 GB RamOS installed in "Compact LZX mode" on a two partitions 3GB VHD, booting first with a1ve's grub2 and chainloading to G4E to load and boot the VHD, it is working fantastic. So far I'm still testing it and will keep you informed of my tests results.

 

alacran

 

alacran



#21 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 02 January 2021 - 02:31 AM

I think this info deserves to be quoted here as it is related in some way to a1ve's grub2 and may be useful.

 

From: http://reboot.pro/to...-10#entry217552

 

alacran

Please execute the following commands in grub2 and grub4dos and take screenshots.

blocklist /path/to/your/virtualdisk.vhd

On which file system is vhd located? fat or ntfs?



#22 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 January 2021 - 03:28 AM

Please execute the following commands in grub2 and grub4dos and take screenshots.

blocklist /path/to/your/virtualdisk.vhd

On which file system is vhd located? fat or ntfs?

 

All are on second HD, second partition (NTFS), into VHD folder but I also have a copy of Mini-10-UEFI-WB.vhd on the root of the second HD,  first partition (FAT-32). And all are fixed size and externally not fragmented.

 

alacran



#23 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 02 January 2021 - 04:13 AM

All are on second HD, second partition (NTFS), into VHD folder but I also have a copy of Mini-10-UEFI-WB.vhd on the root of the second HD, first partition (FAT-32). And all are fixed size and externally not fragmented.

alacran

I still need blocklist info in both grub2 and grub4dos.

#24 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 02 January 2021 - 04:24 AM

Just made the pictures for you.

 

alacran

Attached Thumbnails

  • G2.jpeg
  • G4E.jpeg
  • VHD.png


#25 a1ive

a1ive

    Member

  • Developer
  • 58 posts
  •  
    China

Posted 02 January 2021 - 01:17 PM

I think this info deserves to be quoted here as it is related in some way to a1ve's grub2 and may be useful.

 

From: http://reboot.pro/to...-10#entry217552

 

alacran

please use this grubx64.efi to load vhd: https://drive.google...iew?usp=sharing







Also tagged with one or more of these keywords: grub2, uefi, mbr

1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users