GRUB2 UEFI 下的磁盘仿真

JaKTo

感谢楼主分享，谢谢！

hhhhwwww

    用来网启不错，可以支持proxydhcp了，哈哈

rbwrbw

学习了!!!!!!!!!!!

zpiao119

初学者前来学习一下，感谢分享

tanglf

谢谢分享

duhe303

感谢分享

liuzhaoyzz

wintoflash 发表于 2021-6-17 20:04
我也是醉了。你下载 grub-2.06.tar.gz (或者 tar.xz)，里面有个 NEWS。

想看详细的，就看它的提交历 ...

想请教下，对于你魔改的grub2和官方GNU grub2，对于启动linux方面，具体有哪些革命性的改进，就是说原来GNU grub2做不到的，你做到了？我感觉linxu用loopback+内核支持挂载iso的话，感觉很多都可以启动。map启动linux的话，感觉不能算是革命性的改进。map对于WINPE和RAMOS支持可以算是革命性的改进。
过安全启动支持算不算是改进？我对安全启动没怎么研究。

有优点尽管说！请不要谦虚！

wintoflash

liuzhaoyzz 发表于 2024-4-29 09:31
想请教下，对于你魔改的grub2和官方GNU grub2，对于启动linux方面，具体有哪些革命性的改进，就是说原来G ...

对于Linux的启动，基本没有什么改动。
各Linux发行版基本上都是用的grub2启动，grub2肯定对Linux的支持是最完善的，这也没什么改进空间啊。

liuzhaoyzz

wintoflash 发表于 2024-4-29 16:25
对于Linux的启动，基本没有什么改动。
各Linux发行版基本上都是用的grub2启动，grub2肯定对Linux的支持 ...

哦，了解了。

scdragonlcy

感谢wintoflash大神的杰作，解决了efi启动下的磁盘仿真，让我实现了efi启动下的win7+vhd+svbus的内存系统ramos驱动。真的很兴奋，但有一点遗憾：grub2的map加载vhd到内存速度太慢，只有55m/s，而grub4dos(mbr版)的加载速度可达500m/s，都是用固态硬盘测试。希望wintoflash大神改进一下map的加载到内存的速度，相信wintoflash大神肯定能行。另外，说实话：wintoflash的grub2比老外的grub2强多了，功能丰富而且实用，用了后直接把老外的grub2win卸载了。

scdragonlcy

感谢wintoflash大神的杰作，解决了efi启动下的磁盘仿真，让我实现了efi启动下的win7+vhd+svbus的内存系统ramos驱动。真的很兴奋，但有一点遗憾：grub2的map加载vhd到内存速度55m/s，而grub4dos(mbr版)的加载速度可达500m/s，都是用固态硬盘测试。希望wintoflash大神改进一下map的加载到内存的速度，相信wintoflash大神肯定能行。另外，说实话：wintoflash的grub2比老外的grub2强多了，功能丰富而且实用，用了后直接把老外的grub2win卸载了。

scdragonlcy

blocklist，我试了一下，map加|参数，不行

wintoflash

财源茂盛 发表于 2024-7-4 16:06

滚。别捣乱。

一品校长

谢谢你的共享

82247888ok

感谢分享

wn168cn@163.com

感谢分享

vyuha

赞

zifeng

谢谢分享

wn168cn@163.com

感谢分享

zifeng

感谢分享

vyuha

感谢太强大 了啊

liuzhaoyzz

scdragonlcy 发表于 2024-6-25 20:10
感谢wintoflash大神的杰作，解决了efi启动下的磁盘仿真，让我实现了efi启动下的win7+vhd+svbus的内存系统ra ...

我无意间看到了你的这个回帖。你的测试不完全正确，你用的菜单的菜单参数应该有问题。wintoflash魔改的grub2的map速度要比g4e的速度读文件更快，因为它支持块模式。map -l参数了解下。

menuentry "SX70211.vhd-svbus-ntboot" "/VHD/SX70211.vhd" {
search --no-floppy --set --file $2
map --mem --rt -l $2
ntboot --win --highest=no --efi=(vd0,1)/EFI/boot/bootx64.efi --winload=\\Windows\\System32\\winload.efi (vd0,1)
}

scdragonlcy

谢谢，我试一下

ntcjq999

强大的仿真

scdragonlcy

liuzhaoyzz兄弟(665#)，根据你的提示，我重写cfg文件，如下
menuentry "win7.vhd-svbus-ntboot" "/system/win7.vhd" {
search --no-floppy --set --file $2
map --mem --rt -l $2
ntboot --win --highest=no --efi=(vd0,1)/EFI/boot/bootx64.efi --winload=\\Windows\\System32\\winload.efi (vd0,1)
}
结果启动选择该项后，直接跳回主菜单

而我原来的菜单，选择后仍然可以启动，只是加载速度慢，为55m/s，如下：
menuentry "BOOT VHD2" {
map --mem --rt  (hd1,gpt3)/system/win7.vhd
chainloader (hd3,gpt1)/EFI/Microsoft/Boot/bootmgfw.efi
}

注意：我一共3个实硬盘hd0、hd1、hd2。hd1是放vhd文件的硬盘，hd3是加载vhd后形成的虚拟硬盘。

请你修改一下你的启动代码，我再试一下
拜托啦，最后有点注释，我容易看懂(我是小白)

419545168

谢谢分享

awengers44

Hello; Dear @wintoflash, I forked github.com/a1ive/grub and when I tried to compile it,
it gave a compilation error and failed to compile. The compilation error is as follows:

build.yml
name: release

on:
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
    - name: checkout
      uses: actions/checkout@v4
    - name: initialize
      run: |
        sudo apt-get -y update
        sudo -E apt-get -y install build-essential python3 python-is-python3 iasl lzop unifont autopoint bison flex gettext gcc-aarch64-linux-gnu gcc-arm-linux-gnueabi gcc-mingw-w64
    - name: bootstrap
      run: ./bootstrap

    - name: i686-w64-mingw32 configure
      run: |
        ./configure --prefix=/ --target=i686-w64-mingw32-gcc --with-platform=none --host=i686-w64-mingw32-gcc
    - name: i686-w64-mingw32 make
      run: |
        make
        make install DESTDIR=$PWD/PKG
    - name: i686-w64-mingw32 clean
      run: make clean
-----
-----

i686-w64-mingw32 make

grub-core/osdep/unix/hostdisk.c:91:2: error: #error "No large file support"
   91 | #error "No large file support"
      |  ^~~~~
make: *** [Makefile:14758: libgrub.pp] Error 1
Error: Process completed with exit code 2.

Could you please provide an update for build.yml?

wintoflash

awengers44 发表于 2026-1-5 17:25
Hello; Dear @wintoflash, I forked github.com/a1ive/grub and when I tried to compile it,
it gave a  ...

This project is discontinued.
As a result, over time it has become incompatible with newer toolchains and build environments.
If you still need to compile it, the easiest workaround is to use an older toolchain—e.g. pin the GitHub Actions runner to Ubuntu 22.04—or build in Docker with an older base image/toolchain.