Jump to content











Photo
* * * * * 3 votes

Ventoy - Open source USB boot utility for both BIOS and UEFI


  • Please log in to reply
319 replies to this topic

#76 ventoy

ventoy

    Member

  • Members
  • 83 posts
  •  
    China

Posted 11 May 2020 - 03:59 PM

I see you can use an unattend XMl file with a Windows ISO, but there are no details of HOW exactly you can do this.

 

https://www.ventoy.n...utoinstall.html

 

Anyone any ideas?

Now Ventoy brings a new feature here. You don't need to recreate a new iso file, just use the original one. 
You just need to put a script or template in the USB drive and tell ventoy, that's all. 
You can also update these scripts whenever you want.

so what is file name? where does it go? what extension? how do you 'tell ventoy' ?

Please give example?

 

 

Currently, just put a ventoy.json file under ventoy directory in the USB drive, and config as follows:

(unattend xml/kickstart/autoyast/preseed supported)

{
    "auto_install" : [
        {
            "image": "/ISO/cn_windows_server_2012_r2_vl_x64_dvd_2979220.iso",
            "template": "/ventoy/script/windows_unattended.xml"
        },
        {
            "image": "/000/centos.iso",
            "template": "/ventoy/script/centos_kickstart.cfg"
        },
        {
            "image": "/SLE-12-SP3-Server-DVD-x86_64-GM-DVD1.iso",
            "template": "/ventoy/script/suse_autoyast.xml"
        },
        {
            "image": "/ubuntu-16.04-server-amd64.iso",
            "template": "/ventoy/script/ubuntu_server.seed"
        }
    ]
}

Edited by ventoy, 11 May 2020 - 04:12 PM.


#77 steve6375

steve6375

    Platinum Member

  • Developer
  • 7565 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 May 2020 - 05:42 PM

I made a ventoy v1.0.09 USB Flash Removable 128GB SanDisk drive using a Windows 10 64-bit system.

Explorer only shows one partition which is empty - there is no \ventoy folder visible.

There is an EFI partition but Windows Disk Management does not allow me to assign a drive letter to it.

I had to use DiskPart to assign a drive letter - not very user friendly. I don't see why you should want to hide the 2nd partition anyway?

 

Then I copied a Windows 10 dual architecture ISO to a new \ISO\ folder on the exFAT partition

and an XML file to the same folder.

 

BUT Ventoy did not list any ISOs because I had spaces in the ISO filename.

 

So I removed the spaces.

 

I booted using Virtual Box again and selected the Windows ISO file and got a

'No boot file found for UEFI!

Maybe the image does not support X64 UEFI'

I saw no other messages, so I have no idea if it saw the XML file or not.

 

So I tried a x64 single Windows Install ISO - again same 'no boot file found for UEFI' message.

 

Is there a known issue with VBox 5 (the USB drive would appear as a SATA drive)?

 

I then tested on a real system with UEFI64 booting.

The Dual Architecture Windows Install ISO showed a bootmanager type menu and asked me to choose 32-bit or 64-bit. I chose 64-bit and then it could not find the 'DVD' and asked for a CD\DVD driver to be installed.

 

The same test with a single architecture 64-bit Win10 ISO worked however and I think it also accepted the XML file as it assumed a Pro edition was requested and did not prompt me to select an Edition.

{
    "auto_install" : [
        {
            "image": "/ISO/Windows10_2020_04_20_UK_Both.iso",
            "template": "/ISO/windows_10_Pro.xml"
        },
        {
            "image": "/ISO/Windows10x64UK.iso",
            "template": "/ISO/windows_10_Pro.xml"
        },
        {
            "image": "/000/centos.iso",
            "template": "/ventoy/script/centos_kickstart.cfg"
        },
        {
            "image": "/SLE-12-SP3-Server-DVD-x86_64-GM-DVD1.iso",
            "template": "/ventoy/script/suse_autoyast.xml"
        },
        {
            "image": "/ubuntu-16.04-server-amd64.iso",
            "template": "/ventoy/script/ubuntu_server.seed"
        }
    ]
}

So presumably I can have the XML on the exFAT volume and it does not have to be in the FAT partition?

 

So there are a few Q's:

1. Why can't I boot to a Windows ISO in VBOX when other grub2 solutions just work and have no problem? It makes it very awkward to test!

2. Why can't we have spaces in Windows ISO filenames (and are they allowed in XML filenames)?

3. Why don't standard Microsoft Dual Architecture x86\x64 Install ISOs work?

4. How can I have one Windows 10 ISO but select from a range of different XML files?

5. Why is the 2nd partition made as an EFI type MBR partition so that it is very difficult to add/edit files on it under Windows?

6. Can the ventoy.json file be placed on the exFAT partition (in a \ventoy folder)?

 

HTH

Steve



#78 steve6375

steve6375

    Platinum Member

  • Developer
  • 7565 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 11 May 2020 - 06:14 PM

P.S. An Update destroyed the ventoy.json file on the EFI partition and I see the Ventoy web page does actually say to put the json file on the first partition - my bad!



#79 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 11 May 2020 - 09:15 PM

Hy, nice tool and very useful.

 

I installed Ventoy v1.0.09 on USB Flash Removable + A1ve grubfm_multiarch.iso v7.1.2.

 

And copied linuxmint-19.3-cinnamon-64bit.iso, Win10XPE_x64.ISO and PartedMagic-2019-01-03.iso to exFAT partition.

 

Booting on real machine:

 

On MBR linuxmint-19.3-cinnamon-64bit.iso, Win10XPE_x64.ISO and PartedMagic-2019-01-03.iso boot fine.

 

On UEFI linuxmint-19.3-cinnamon-64bit.iso boots fine.

 

On UEFI Win10XPE_x64.ISO and PartedMagic-2019-01-03.iso do not boot, I got a message (for both):

 

 

    'No boot file found for UEFI!
    Maybe the image does not support X64 UEFI'

 

I know both Isos are fine since I can boot on MBR and on UEFI same Win10XPE_x64.ISO using USB_FORMAT from wimb and (adding A1ve agFM) PartedMagic-2019-01-03.iso boots fine on MBR and UEFI too.

 

Any ideas?



#80 ventoy

ventoy

    Member

  • Members
  • 83 posts
  •  
    China

Posted 12 May 2020 - 01:03 AM

I made a ventoy v1.0.09 USB Flash Removable 128GB SanDisk drive using a Windows 10 64-bit system.

Explorer only shows one partition which is empty - there is no \ventoy folder visible.

There is an EFI partition but Windows Disk Management does not allow me to assign a drive letter to it.

I had to use DiskPart to assign a drive letter - not very user friendly. I don't see why you should want to hide the 2nd partition anyway?

 

Then I copied a Windows 10 dual architecture ISO to a new \ISO\ folder on the exFAT partition

and an XML file to the same folder.

 

BUT Ventoy did not list any ISOs because I had spaces in the ISO filename.

 

So I removed the spaces.

 

I booted using Virtual Box again and selected the Windows ISO file and got a

I saw no other messages, so I have no idea if it saw the XML file or not.

 

So I tried a x64 single Windows Install ISO - again same 'no boot file found for UEFI' message.

 

Is there a known issue with VBox 5 (the USB drive would appear as a SATA drive)?

 

I then tested on a real system with UEFI64 booting.

The Dual Architecture Windows Install ISO showed a bootmanager type menu and asked me to choose 32-bit or 64-bit. I chose 64-bit and then it could not find the 'DVD' and asked for a CD\DVD driver to be installed.

 

The same test with a single architecture 64-bit Win10 ISO worked however and I think it also accepted the XML file as it assumed a Pro edition was requested and did not prompt me to select an Edition.

{
    "auto_install" : [
        {
            "image": "/ISO/Windows10_2020_04_20_UK_Both.iso",
            "template": "/ISO/windows_10_Pro.xml"
        },
        {
            "image": "/ISO/Windows10x64UK.iso",
            "template": "/ISO/windows_10_Pro.xml"
        },
        {
            "image": "/000/centos.iso",
            "template": "/ventoy/script/centos_kickstart.cfg"
        },
        {
            "image": "/SLE-12-SP3-Server-DVD-x86_64-GM-DVD1.iso",
            "template": "/ventoy/script/suse_autoyast.xml"
        },
        {
            "image": "/ubuntu-16.04-server-amd64.iso",
            "template": "/ventoy/script/ubuntu_server.seed"
        }
    ]
}

So presumably I can have the XML on the exFAT volume and it does not have to be in the FAT partition?

 

So there are a few Q's:

1. Why can't I boot to a Windows ISO in VBOX when other grub2 solutions just work and have no problem? It makes it very awkward to test!

2. Why can't we have spaces in Windows ISO filenames (and are they allowed in XML filenames)?

3. Why don't standard Microsoft Dual Architecture x86\x64 Install ISOs work?

4. How can I have one Windows 10 ISO but select from a range of different XML files?

5. Why is the 2nd partition made as an EFI type MBR partition so that it is very difficult to add/edit files on it under Windows?

6. Can the ventoy.json file be placed on the exFAT partition (in a \ventoy folder)?

 

HTH

Steve

 

 

Hi,

 

Yes, you should create a ventoy directory in the first partition and put a ventoy.json file in it. The json file is also the entrypoint for all plugins.

All of these are explained on the website.

 

As for the space in the file name, I have explained in both document and the FAQ,  it is just an artificial limitation in current version, I will fixed it in the future release.

 

 

 

1. Why can't I boot to a Windows ISO in VBOX when other grub2 solutions just work and have no problem? It makes it very awkward to test!

----- You reported it before,  I hava no idea about it. I tested ventoy with latest version of VBOX and it worked well.

 

2. Why can't we have spaces in Windows ISO filenames (and are they allowed in XML filenames)?

----- see the explanation above

 

3. Why don't standard Microsoft Dual Architecture x86\x64 Install ISOs work?

----- You reported it before, Maybe it's a BUG in current release, I will check it.

 

4. How can I have one Windows 10 ISO but select from a range of different XML files?

----- Currently you need to modify the json file, If needed I can provide a dynamic menu to select them before boot, it's simple.

 

5. Why is the 2nd partition made as an EFI type MBR partition so that it is very difficult to add/edit files on it under Windows?

----- I explained in detail why in the website, you can see    https://www.ventoy.n...isk_layout.html

 

6. Can the ventoy.json file be placed on the exFAT partition (in a \ventoy folder)?

----- see the explanation above

 

 

Ventoy was only a month old, and inevitably there will be some problems. So please give me more time  :)



#81 ventoy

ventoy

    Member

  • Members
  • 83 posts
  •  
    China

Posted 12 May 2020 - 01:24 AM

Hy, nice tool and very useful.

 

I installed Ventoy v1.0.09 on USB Flash Removable + A1ve grubfm_multiarch.iso v7.1.2.

 

And copied linuxmint-19.3-cinnamon-64bit.iso, Win10XPE_x64.ISO and PartedMagic-2019-01-03.iso to exFAT partition.

 

Booting on real machine:

 

On MBR linuxmint-19.3-cinnamon-64bit.iso, Win10XPE_x64.ISO and PartedMagic-2019-01-03.iso boot fine.

 

On UEFI linuxmint-19.3-cinnamon-64bit.iso boots fine.

 

On UEFI Win10XPE_x64.ISO and PartedMagic-2019-01-03.iso do not boot, I got a message (for both):

 

 

I know both Isos are fine since I can boot on MBR and on UEFI same Win10XPE_x64.ISO using USB_FORMAT from wimb and (adding A1ve agFM) PartedMagic-2019-01-03.iso boots fine on MBR and UEFI too.

 

Any ideas?

 

I can't give you the answer right away, sorry.

You can test it in virtual machine or another real machine as a comparison.

Or you can test it with memdisk mode (Press F1 before select iso)



#82 gita

gita
  • Members
  • 8 posts
  •  
    Greece

Posted 14 May 2020 - 05:33 PM

Hi,
Any Tipps for me?
My WinPE Boot ISO’s started successful but when booted the apps at this bootcds cant ne loaded (easy2boot requires continuous)

#83 steve6375

steve6375

    Platinum Member

  • Developer
  • 7565 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 14 May 2020 - 05:38 PM

Easy2Boot v2 uses a1ive agFM.

It will MBR or UEFI-boot WINPE files - they do not need to be contiguous.

For MBR-booting of some WinPE ISOs, it is best to use the agFM menu.

It supports direct Secure UEFI64 booting of WinPE, Win install, Linux, Memtest EFI, KonBoot, Linux+persistence, supports .imgPTN files too.



#84 wimb

wimb

    Platinum Member

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

Posted 17 May 2020 - 05:23 PM

Open Up ....  ;) 

 

In Ventoy 1.0.10 you can reformat the 1st partition with NTFS FileSystem, so that you can Boot with

- Win10x64 VHD as FILEDISK from a1ive Grub2 FileManager Or direct from Windows Boot Manager Menu in BIOS or UEFI mode

- Win10XPE boot.wim in RAMDISK loaded from a1ive Grub2 FileManager Or direct from Windows Boot Manager Menu in BIOS or UEFI mode

- Windows Boot Manager Menu in BIOS or UEFI mode

- Grub4dos Menu - in BIOS mode only

- Grub2 Menu in BIOS or UEFI mode

 

- Fedora-Workstation-Live-x86_64-32-1.6.iso Fails to Boot from Ventoy Menu when located on NTFS partition of Portable SSD

- runtimelivecd.iso Fails to Boot from Ventoy Menu, but is booting OK when using Grub4dos or Grub2 Menu entries.

 

On the Ventoy Hidden EFI partition I have modified file grub\grubcfg as shown below to add Boot options for Windows Boot Manager and for Grub4dos and Grub2 Menu

and I have added the necessary files to Ventoy NTFS Drive as illustrated in the Screenshot.

For booting in UEFI mode with Windows Boot Manager I have added the EFI\Microsoft folder to EFI folder on the Hidden EFI drive of Ventoy.

The files jpn_boot.ttf and kor_boot.ttf in folder Microsoft\Boot\Fonts were removed previously since there is not enough space in Ventoy Hidden EFI drive.

 

Ventoy EFI Drive file grub\grub.cfg

#Main menu
if [ $ventoy_img_count -gt 0 ]; then
    if [ $VTOY_DEFAULT_MENU_MODE -eq 0 ]; then
        vt_dynamic_menu 0 0 
    else
        vt_dynamic_menu 0 1
    fi

    if [ "${grub_platform}" == "efi" ] -a [ -e "(hd0,msdos2)/EFI/Microsoft/Boot/bootmgfw.efi" ]; then
    menuentry "Windows EFI BootManager" {
      chainloader (hd0,msdos2)/EFI/Microsoft/Boot/bootmgfw.efi
    }
    fi

    if [ "${grub_platform}" == "pc" ] -a [ -e "(hd0,msdos1)/bootmgr" ]; then
    menuentry "Windows BootManager" {
      chainloader (hd0,msdos1)+1
    }
    fi

    if [ "${grub_platform}" == "pc" ] -a [ -e "(hd0,msdos1)/grub.exe" ]; then
    menuentry "Grub4dos Menu" {
        linux (hd0,msdos1)/grub.exe
    }
    fi

    if [ -e (hd0,msdos1)/grub_Linux.cfg ]; then
    menuentry "Grub2 Menu" {
      set iso_drive=(hd0,msdos1)
      export iso_drive
      configfile (hd0,msdos1)/grub_Linux.cfg
    }
    fi

else
    menuentry "No ISO files found (Press enter to reboot ...)" {
        echo -e "\n    Rebooting ... "
        reboot
    }
fi

=

Ventoy_NTFS_2020-05-17_172203.jpg == Ventoy_a1ive_18051743.png == Ventoy_a1ive_EFI_Menu_18051846.png == Ventoy_EFI_Menu_18051901.png == Ventoy_Grub2_Menu_18051939.png

 

:cheers:



#85 alz52879

alz52879

    Newbie

  • Members
  • 19 posts
  •  
    Germany

Posted 19 May 2020 - 05:42 AM

@ wimb

First off, thanks a lot for all the work you're doing on here.

 

This is what my my USB Flash Disk looks like:

eT3pA.png

I've replaced the original Ventoy's #Main menu with yours, added the grub_Linux.cfg file to the ntfs partition with the following code:

menuentry 'Porteus-Kiosk' {
    set root='hd0,msdos1'
    search --no-floppy --fs-uuid --set=root xxxx-xx-xx-xx-xx-xx-xx
    linux /boot/vmlinuz
    initrd /boot/initrd.xz
}

.. but the Grub2 menu doesn't appear upon booting Ventoy.

Any thoughts?



#86 wimb

wimb

    Platinum Member

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

Posted 19 May 2020 - 07:40 AM

.. but the Grub2 menu doesn't appear upon booting Ventoy.

Any thoughts?

 

You mean that you can boot into Ventoy Menu and that the Grub2 Menu entry is Not visible there ? It should be there.

Anyway I think that your Grub2 menuentry is not OK since the root for Kiosk is not hd0,msdos1 ....

In your case the partitioning has changed by inserting the Kiosk partition.

I think in that case it might be that booting into Ventoy Menu fails already.

I inserted a FAT32 primary partition by first reducing the size of the NTFS partition, and then Ventoy booting fails.

The Ventoy EFI drive is not found ....

 

I did some experiments with Ventoy and Porteus Linux ISO files.

- Porteus ISO files located in images folder on NTFS drive of Portable SSD FAIL to boot from Ventoy Menu

- I can use my Grub2 Menu entry made in grub_Linux.cfg to boot Porteus-CINNAMON-v4.0-x86_64.iso Or Porteus-CINNAMON-v5.0rc1-x86_64.iso

- Grub2 Menu entry made in grub_Linux.cfg for Porteus-Kiosk-5.0.0-x86_64.iso Fails to boot (not suitable to boot as ISO from Grub2 Menu ?)

 

grub_Linux.cfg - entry working for Porteus-CINNAMON-v5.0rc1-x86_64.iso

if [ -e "$iso_drive/images/Porteus-CINNAMON-v5.0rc1-x86_64.iso" ]; then
menuentry "ISO Linux Porteus - Porteus-CINNAMON-v5.0rc1-x86_64.iso $iso_drive" {
  set iso_path=/images/Porteus-CINNAMON-v5.0rc1-x86_64.iso
  loopback loop $iso_drive$iso_path
  linux	(loop)/boot/syslinux/vmlinuz nomagic base_only norootcopy from=$iso_path
  initrd (loop)/boot/syslinux/initrd.xz
}
fi

Ventoy_Porteus_19085537.png == Ventoy_Porteus_19085604.png == Ventoy_Porteus_2020-05-19 08-40-12.png



#87 wimb

wimb

    Platinum Member

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

Posted 19 May 2020 - 10:24 AM

.. but the Grub2 menu doesn't appear upon booting Ventoy.

Any thoughts?

 

Probably the disk number where grub_Linux.cfg is located is not hd0 but may be hd1

 

You can try to modify grub\grub.cfg

    if [ -e (hd1,msdos1)/grub_Linux.cfg ]; then
    menuentry "Grub2 Menu (hd1,msdos1)" {
      set iso_drive=(hd1,msdos1)
      export iso_drive
      configfile (hd1,msdos1)/grub_Linux.cfg
    }
    fi

Otherwise in Ventoy menu press c and use grub command ls to find out what disk number is valid for grub_Linux.cfg

Or better use a1ive Grub2 FileManager and find out where grub_Linux.cfg is located

 

I think it is going offtopic and may be if not solved then you should start a separate topic about the issue



#88 alz52879

alz52879

    Newbie

  • Members
  • 19 posts
  •  
    Germany

Posted 19 May 2020 - 10:50 AM

I tried the following ...

if [ -e (hd1,msdos1)/grub_Linux.cfg ]; then
    menuentry "Grub2 Menu (hd1,msdos1)" {
      set iso_drive=(hd1,msdos1)
      export iso_drive
      configfile (hd1,msdos1)/grub_Linux.cfg
    }
    fi

... but to no avail as the Grub2 Menu still doesn't appear.

This is what grub command ls comes up with:

(proc) (hd0,msdos5) (hd0,msdos2) (hd0,msdos1) (hd1) 

Please take into account that Porteus-Kiosk differs from Porteus-Linux's distros. It has to be dd'ed and you can't boot from the iso file.

Now, the only boot menu that I've got in Ventoy is "No ISO files found (Press enter to reboot ..."



#89 Akeo

Akeo

    Frequent Member

  • Developer
  • 358 posts
  •  
    Ireland

Posted 19 May 2020 - 01:13 PM

How does it work?

 

With apologies to longpanda/ventoy, and since I was curious about it myself, let me detail my findings (which I hope are relatively accurate, but may of course contain errors that I'll be happy to see corrected).

 

The one prerequisite you need to know is the great explanation steve6375 gave here of the outline of WinPE boot process (but even then, the only thing that really matters is that winpeshl.exe is the first executable that is being run during an installation process).

 

  1. As you already know, when a Ventoy bootable drive boots, it boots in a custom version of GRUB 2.04 with extra ventoy features added. This presents the user with the choice of ISOs, and also allows you to add some additional options when booting, such as vt_debug on, which (if you add it through GRUB's e command before you boot the currenty selected image) allows you to get some very informative details on what Ventoy does.
  2. If a Windows ISO is selected, the first thing Ventoy does (as part of its GRUB extension) is:
    1. Open boot.wim from the ISO
    2. Locate and read the original Windows\System32\winpeshl.exe to memory (NB: I'm discounting what happens for multiple wim indexes here)
    3. Depending on the bitness of the image being used, inject either of the 32-bit or 64-bit version of vtoyjump.exe as Windows\System32\winpeshl.exe.
  3. Windows ISO is now booted from the virtual UEFI CD-ROM device (well, technically, I think 2 happens while we are doing this, so one could consider that 2-3 is a single step), which eventually leads to the altered boot.wim being read, extracted to memory and run. At this stage we quit the UEFI environment which means that the UEFI virtual CD-ROM device ceases to be available.
  4. Once the NT kernel launches and has completed performing pre initialisation, the altered Windows\System32\winpeshl.exe (which, again, is just vtoyjump32.exe or vtoyjump64.exe in disguise) is launched.
  5. The first thing the application does is read back the original Windows\System32\winpeshl.exe from memory and copy it to Windows\System32\ventoy\winpeshl.exe.
  6. Then the relevant ISO from the Ventoy exFAT partition (which would usually be available as the D: drive, but of course a proper lookup for it is being made by vtoyjump) is mounted, either using the native Windows 8 or later API or by loading the imdisk driver and executable.
  7. From there, the whole content of the installation media are accessible in a manner that Windows will be able to locate automatically, and the rest of the installation process is handed over to Windows\System32\ventoy\winpeshl.exe (i.e. the original winpeshl.exe from the image).

 

For those interested, I'm also leaving the Windows\System32\ventoy.log that vtoyjump.exe creates below:

[2020/05/19 12:19:34.591] ######## VentoyJump ##########
[2020/05/19 12:19:34.591] argc = 1 argv[0] = <winpeshl.exe>
[2020/05/19 12:19:34.591] Current directory = <X:\windows\system32>
[2020/05/19 12:19:34.591] ReadWholeFile2Buf <winpeshl.exe>
[2020/05/19 12:19:34.607] Success read file size:159232
[2020/05/19 12:19:34.607] Find os pararm at 125952
[2020/05/19 12:19:34.607] SaveBuffer2File <ventoy\winpeshl.exe> len:32256
[2020/05/19 12:19:34.607] Logical Drives=0x80000c Path:<\Win10_1909_EnglishInternational_x64.iso>
[2020/05/19 12:19:34.607] File NOT exist under C:
[2020/05/19 12:19:34.622] File exist under D:
[2020/05/19 12:19:34.622] GetPhyDiskUUID D
[2020/05/19 12:19:34.622] D: is in PhysicalDrive0 
[2020/05/19 12:19:34.622] Disk UUID match
[2020/05/19 12:19:34.622] Find ISO file <D:\\Win10_1909_EnglishInternational_x64.iso>
[2020/05/19 12:19:34.622] This is Windows 8 or latter...
[2020/05/19 12:19:34.622] VentoyMountISOByAPI <D:\\Win10_1909_EnglishInternational_x64.iso>
[2020/05/19 12:19:34.638] OpenVirtualDisk success
[2020/05/19 12:19:34.654] Mount iso by API success
[2020/05/19 12:19:34.654] Mount ISO FILE: SUCCESS
[2020/05/19 12:19:34.654] DeleteVentoyPart2MountPoint Phy0 ...
[2020/05/19 12:19:34.654] File C:\ventoy\ventoy.cpio exist
[2020/05/19 12:19:34.654] LogicalDrive:\\.\C: PhyDrive:0 Offset:31373393920 ExtentLength:33554432
[2020/05/19 12:19:34.654] PhyDisk=0 for C
[2020/05/19 12:19:34.654] Delete ventoy mountpoint: SUCCESS
[2020/05/19 12:19:34.654] auto install no need
[2020/05/19 12:19:34.654] Ventoy jump success ...

For BIOS/Legacy Windows boot, the process is of course pretty much the same, with only the virtual CD-ROM device that's being set for loading of the boot.wim image in a BIOS environment being different.

 

For Linux boot, which I haven't looked into in detail at this stage, my understanding is that it's a bit more straightforward: Ventoy "simply" alters the GRUB or Syslinux boot options from the ISO so that, whereas the kernel being invoked of course remains the same, ventoy.cpio is used as the initrd.

 

Then once ventoy.cpio executes, it performs a lookup of the distro being booted and sets up and mount the relevant virtual CD-ROM image before handing over to the original initrd.

 

 

I have to say that what Ventoy does is quite nifty, though of course, in the case of Windows, it requires altering the original ISO files (boot.wim) and running an non-Microsoft executable early in the boot process, which puts you at the mercy of Microsoft deciding to:

  • Perform an checksum validation of the ISO content, a la Ubuntu 20.04 (though if it's like Ubuntu 20.04, then this would be easy to work around, as you can just alter the checksums that are recorded in a text file on the ISO).
  • Enforce some kind of tampering validation for winpeshl.exe.

Because of their corporate users, who probably want the ability to create their custom installation media without being bothered, I don't personally believe that Microsoft is going to do any of that any time soon, though I'm a bit surprised to see how much of a cavalier attitude Microsoft seems to have by default on the first executable that gets launched in the installation environment, especially considering that setup.exe from install.wim is digitally signed whereas winpeshl.exe isn't.

 

As a matter of fact, if you had asked me, some time ago, whether I thought that the method used by Ventoy of injecting winpeshl.exe had any chance to work, I would have said no. So props to longpanda/ventoy for actually trying it out and demonstrating I was wrong. Oh and, the way I see it, I think that the advent of Ventoy might very well mean the slow death of Rufus/RMPrepUSB/Easy2Boot and other utilities, which, as the author of Rufus, I'm kind of okay with because, even if I see minor issues with it, I think Ventoy does a great job at delivery what users have been wanting for a long time in a very simple and convenient package, so that deserves some props...

 

At this stage, the only major concern I have with Ventoy when it comes to security has to do with Secure Boot:

 

  1. Currently, after users have enrolled the Ventoy certificate to allow it to run in a Secure Boot environment, any unsigned bootx64.efi from any ISO will happily be launched. Ironically, whereas Secure Boot maniacs might see this as a great improvement over utilities like Rufus, that may ask them to temporarily disable Secure Boot ("See? I don't have to disable Secure Boot any more!"), it actually defeats the whole point of Secure Boot which is to only allow the execution of boot files you have some reason to trust, and effectively leaves their system wide open to the many maliciously crafted Windows ISOs that can be found floating around the internet... The irony is certainly not lost on me that some of the very people who clamour for Secure Boot will be the very same people happily leaving their system wide open for the execution of malicious content, that Secure Boot was precisely designed to protect them from....

    Fortunately, fixing this should be relatively simple (famous last words), by having Ventoy detect if Secure Boot is enabled, and, if that is the case, only launch bootx64.efi files that pass the Secure Boot digital signature validation. Then, if users still want to execute non Secure Boot signed media, they still can do that, but it will become very explicit if the ISO they are trying to boot is actually Secure Boot compliant or not, which, for users who actually care about Secure Boot, is what you want.
     
  2. No matter how much I trust Ventoy (which, after having talked extensively to his friendly developer and looked at the source I most certainly do) I really don't like the idea the idea of enrolling somebody else's single global certificate into my machine's Secure Boot store, because you never know if the private key associated with that certificate might be stolen by a third party and used for nefarious purposes.

    Unfortunately, unlike the above, there's no good solution to that problem, though one could provide an option for Ventoy2Disk users that could: Generate a new credential, sign the Ventoy bootx64.efi executable with this credential, destroy the private key (since it should only ever be used to sign that executable and nothing else), and then copy the certificate to the Ventoy ESP to replace ENROLL_THIS_KEY_IN_MOKMANAGER.cer. The problem of course is that, if you do that, then you have to re-enroll the new key every time Ventoy is updated, which isn't ideal. That is, unless you also provide an option for users to save and reuse the private key, which of course opens other security issues (but at least these issues would be limited to one specific user environment and wouldn't affect other Ventoy users in the same way as the leaking of Ventoy's current private signing key would do)...
    If Ventoy becomes as popular as I believe it will, there will be a lot of people suddenly interested in getting their hands on the private key that matches the certificate that Ventoy uses for Secure Boot, and no matter how safe longpanda keeps it, it will always be seen as a major liability of using Ventoy for security conscious users....

 

When I get a chance, I will log issue #1 in the Ventoy issue tracker, because anyone who understands the point of Secure Boot will not take Ventoy seriously unless that is fixed. And I think I'll have a private discussion with longpanda (unless he/she wants to reply here) about #2, because, even if I suspect that most people, including the author of the application, will prefer to keep the current global .cer since it's a lot more convenient, I still think it will be worthwile to provide an alternative, for security minded people...


  • steve6375 likes this

#90 ventoy

ventoy

    Member

  • Members
  • 83 posts
  •  
    China

Posted 19 May 2020 - 02:04 PM

With apologies to longpanda/ventoy, and since I was curious about it myself, let me detail my findings (which I hope are relatively accurate, but may of course contain errors that I'll be happy to see corrected).

 

The one prerequisite you need to know is the great explanation steve6375 gave here of the outline of WinPE boot process (but even then, the only thing that really matters is that winpeshl.exe is the first executable that is being run during an installation process).

 

  1. As you already know, when a Ventoy bootable drive boots, it boots in a custom version of GRUB 2.04 with extra ventoy features added. This presents the user with the choice of ISOs, and also allows you to add some additional options when booting, such as vt_debug on, which (if you add it through GRUB's e command before you boot the currenty selected image) allows you to get some very informative details on what Ventoy does.
  2. If a Windows ISO is selected, the first thing Ventoy does (as part of its GRUB extension) is:
    1. Open boot.wim from the ISO
    2. Locate and read the original Windows\System32\winpeshl.exe to memory (NB: I'm discounting what happens for multiple wim indexes here)
    3. Depending on the bitness of the image being used, inject either of the 32-bit or 64-bit version of vtoyjump.exe as Windows\System32\winpeshl.exe.
  3. Windows ISO is now booted from the virtual UEFI CD-ROM device (well, technically, I think 2 happens while we are doing this, so one could consider that 2-3 is a single step), which eventually leads to the altered boot.wim being read, extracted to memory and run. At this stage we quit the UEFI environment which means that the UEFI virtual CD-ROM device ceases to be available.
  4. Once the NT kernel launches and has completed performing pre initialisation, the altered Windows\System32\winpeshl.exe (which, again, is just vtoyjump32.exe or vtoyjump64.exe in disguise) is launched.
  5. The first thing the application does is read back the original Windows\System32\winpeshl.exe from memory and copy it to Windows\System32\ventoy\winpeshl.exe.
  6. Then the relevant ISO from the Ventoy exFAT partition (which would usually be available as the D: drive, but of course a proper lookup for it is being made by vtoyjump) is mounted, either using the native Windows 8 or later API or by loading the imdisk driver and executable.
  7. From there, the whole content of the installation media are accessible in a manner that Windows will be able to locate automatically, and the rest of the installation process is handed over to Windows\System32\ventoy\winpeshl.exe (i.e. the original winpeshl.exe from the image).

 

For those interested, I'm also leaving the Windows\System32\ventoy.log that vtoyjump.exe creates below:

[2020/05/19 12:19:34.591] ######## VentoyJump ##########
[2020/05/19 12:19:34.591] argc = 1 argv[0] = <winpeshl.exe>
[2020/05/19 12:19:34.591] Current directory = <X:\windows\system32>
[2020/05/19 12:19:34.591] ReadWholeFile2Buf <winpeshl.exe>
[2020/05/19 12:19:34.607] Success read file size:159232
[2020/05/19 12:19:34.607] Find os pararm at 125952
[2020/05/19 12:19:34.607] SaveBuffer2File <ventoy\winpeshl.exe> len:32256
[2020/05/19 12:19:34.607] Logical Drives=0x80000c Path:<\Win10_1909_EnglishInternational_x64.iso>
[2020/05/19 12:19:34.607] File NOT exist under C:
[2020/05/19 12:19:34.622] File exist under D:
[2020/05/19 12:19:34.622] GetPhyDiskUUID D
[2020/05/19 12:19:34.622] D: is in PhysicalDrive0 
[2020/05/19 12:19:34.622] Disk UUID match
[2020/05/19 12:19:34.622] Find ISO file <D:\\Win10_1909_EnglishInternational_x64.iso>
[2020/05/19 12:19:34.622] This is Windows 8 or latter...
[2020/05/19 12:19:34.622] VentoyMountISOByAPI <D:\\Win10_1909_EnglishInternational_x64.iso>
[2020/05/19 12:19:34.638] OpenVirtualDisk success
[2020/05/19 12:19:34.654] Mount iso by API success
[2020/05/19 12:19:34.654] Mount ISO FILE: SUCCESS
[2020/05/19 12:19:34.654] DeleteVentoyPart2MountPoint Phy0 ...
[2020/05/19 12:19:34.654] File C:\ventoy\ventoy.cpio exist
[2020/05/19 12:19:34.654] LogicalDrive:\\.\C: PhyDrive:0 Offset:31373393920 ExtentLength:33554432
[2020/05/19 12:19:34.654] PhyDisk=0 for C
[2020/05/19 12:19:34.654] Delete ventoy mountpoint: SUCCESS
[2020/05/19 12:19:34.654] auto install no need
[2020/05/19 12:19:34.654] Ventoy jump success ...

For BIOS/Legacy Windows boot, the process is of course pretty much the same, with only the virtual CD-ROM device that's being set for loading of the boot.wim image in a BIOS environment being different.

 

For Linux boot, which I haven't looked into in detail at this stage, my understanding is that it's a bit more straightforward: Ventoy "simply" alters the GRUB or Syslinux boot options from the ISO so that, whereas the kernel being invoked of course remains the same, ventoy.cpio is used as the initrd.

 

Then once ventoy.cpio executes, it performs a lookup of the distro being booted and sets up and mount the relevant virtual CD-ROM image before handing over to the original initrd.

 

 

I have to say that what Ventoy does is quite nifty, though of course, in the case of Windows, it requires altering the original ISO files (boot.wim) and running an non-Microsoft executable early in the boot process, which puts you at the mercy of Microsoft deciding to:

  • Perform an checksum validation of the ISO content, a la Ubuntu 20.04 (though if it's like Ubuntu 20.04, then this would be easy to work around, as you can just alter the checksums that are recorded in a text file on the ISO).
  • Enforce some kind of tampering validation for winpeshl.exe.

Because of their corporate users, who probably want the ability to create their custom installation media without being bothered, I don't personally believe that Microsoft is going to do any of that any time soon, though I'm a bit surprised to see how much of a cavalier attitude Microsoft seems to have by default on the first executable that gets launched in the installation environment, especially considering that setup.exe from install.wim is digitally signed whereas winpeshl.exe isn't.

 

As a matter of fact, if you had asked me, some time ago, whether I thought that the method used by Ventoy of injecting winpeshl.exe had any chance to work, I would have said no. So props to longpanda/ventoy for actually trying it out and demonstrating I was wrong. Oh and, the way I see it, I think that the advent of Ventoy might very well mean the slow death of Rufus/RMPrepUSB/Easy2Boot and other utilities, which, as the author of Rufus, I'm kind of okay with because, even if I see minor issues with it, I think Ventoy does a great job at delivery what users have been wanting for a long time in a very simple and convenient package, so that deserves some props...

 

At this stage, the only major concern I have with Ventoy when it comes to security has to do with Secure Boot:

 

  1. Currently, after users have enrolled the Ventoy certificate to allow it to run in a Secure Boot environment, any unsigned bootx64.efi from any ISO will happily be launched. Ironically, whereas Secure Boot maniacs might see this as a great improvement over utilities like Rufus, that may ask them to temporarily disable Secure Boot ("See? I don't have to disable Secure Boot any more!"), it actually defeats the whole point of Secure Boot which is to only allow the execution of boot files you have some reason to trust, and effectively leaves their system wide open to the many maliciously crafted Windows ISOs that can be found floating around the internet... The irony is certainly not lost on me that some of the very people who clamour for Secure Boot will be the very same people happily leaving their system wide open for the execution of malicious content, that Secure Boot was precisely designed to protect them from....

    Fortunately, fixing this should be relatively simple (famous last words), by having Ventoy detect if Secure Boot is enabled, and, if that is the case, only launch bootx64.efi files that pass the Secure Boot digital signature validation. Then, if users still want to execute non Secure Boot signed media, they still can do that, but it will become very explicit if the ISO they are trying to boot is actually Secure Boot compliant or not, which, for users who actually care about Secure Boot, is what you want.
     
  2. No matter how much I trust Ventoy (which, after having talked extensively to his friendly developer and looked at the source I most certainly do) I really don't like the idea the idea of enrolling somebody else's single global certificate into my machine's Secure Boot store, because you never know if the private key associated with that certificate might be stolen by a third party and used for nefarious purposes.

    Unfortunately, unlike the above, there's no good solution to that problem, though one could provide an option for Ventoy2Disk users that could: Generate a new credential, sign the Ventoy bootx64.efi executable with this credential, destroy the private key (since it should only ever be used to sign that executable and nothing else), and then copy the certificate to the Ventoy ESP to replace ENROLL_THIS_KEY_IN_MOKMANAGER.cer. The problem of course is that, if you do that, then you have to re-enroll the new key every time Ventoy is updated, which isn't ideal. That is, unless you also provide an option for users to save and reuse the private key, which of course opens other security issues (but at least these issues would be limited to one specific user environment and wouldn't affect other Ventoy users in the same way as the leaking of Ventoy's current private signing key would do)...
    If Ventoy becomes as popular as I believe it will, there will be a lot of people suddenly interested in getting their hands on the private key that matches the certificate that Ventoy uses for Secure Boot, and no matter how safe longpanda keeps it, it will always be seen as a major liability of using Ventoy for security conscious users....

 

When I get a chance, I will log issue #1 in the Ventoy issue tracker, because anyone who understands the point of Secure Boot will not take Ventoy seriously unless that is fixed. And I think I'll have a private discussion with longpanda (unless he/she wants to reply here) about #2, because, even if I suspect that most people, including the author of the application, will prefer to keep the current global .cer since it's a lot more convenient, I still think it will be worthwile to provide an alternative, for security minded people...

 

Hi pete,
 
I have to say that you have thoroughly researched Ventoy :)
 
For Linux boot, to be exactly ventoy.cpio does not replace the original initrd, it will be concatenated with the original initrd.
That's ventoy.cpio+initrd. If only ventoy.cpio is loaded with the kernel, there will be no driver to access the disk and other hardware.
 
As for the checksum, after the kernel was booted, the virtual cdrom is gone. And ventoy creates a device-mapper based on the original iso file.
So the checksum will be OK, there is no workaround in Ubuntu 20.04, the checksum is indeed match with the iso file.
 
The secure boot solution in Ventoy is not so good. It really needs serious discussion, private discussion is welcome.


#91 steve6375

steve6375

    Platinum Member

  • Developer
  • 7565 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 19 May 2020 - 02:06 PM

Thanks a lot for the explanation. I still would like to know more about the Linux boot process though. :unsure:

What worries me is just how 'universal' the Linux approach is since there are a lot of reports of 'it doesn't work with ISO xyz' and then Ventoy has fixed the problem. So, in the future, do we have to keep asking ventoy and any fellow developers to add patches to cope with the next distro that comes out, and the next, and the next, etc.

Whilst I admit that the partnew approach used in E2B and now a1ive's grub2 is a clumsy approach which requires writeable-media, MBR partitions,  free partition and a contiguous ISO file - at least it will work on 99% of ISOs and it has not needed any 'patches' to boot Linux ISOs in over six years.

 

On another note:

The Secure Boot fix relies on MokManager which I have found to be very unreliable - it either does not work or crashes on many different systems. As Akeo says, it also modifies the whitelist of the target system and so compromises it 'permanently' unless you later remove the entry from the firmware db.

 

 

Currently, I use the Kaspesky shim with A1ive's grub2 and agFM. The Kaspersky shim is signed by Microsoft and so Secure Boots. This runs sbpolicy from the grub.cfg file which 'self-signs' the grubx64.efi file before loading it. Once the grubfmx64.efi file (a1ives grub2) runs, he (somehow) modifies the readonly UEFI Secure Boot Flag to report 'false' instead of 'true'. This allows his grub2 to run signed or unsigned EFI files or linux16 kernels, etc. We can thus use dd to modify the disks or run any payload we like!

 

Microsoft did try to blacklist the shim a few months ago which caused havoc as they quickly found out it was being used by others (AVG\Avast and some notebook OEMs?). I guess at some stage they will roll out the blacklist update again, but until then we have complete freedom to boot anything we like as long as the Secure Boot enabled system does not ask for a password and will boot from an external USB drive.

 

 



#92 ventoy

ventoy

    Member

  • Members
  • 83 posts
  •  
    China

Posted 19 May 2020 - 02:18 PM

Thanks a lot for the explanation. I still would like to know more about the Linux boot process though. :unsure:

What worries me is just how 'universal' the Linux approach is since there are a lot of reports of 'it doesn't work with ISO xyz' and then Ventoy has fixed the problem. So, in the future, do we have to keep asking ventoy and any fellow developers to add patches to cope with the next distro that comes out, and the next, and the next, etc.

Whilst I admit that the partnew approach used in E2B and now a1ive's grub2 is a clumsy approach which requires writeable-media, MBR partitions,  free partition and a contiguous ISO file - at least it will work on 99% of ISOs and it has not needed any 'patches' to boot Linux ISOs in over six years.

 

On another note:

The Secure Boot fix relies on MokManager which I have found to be very unreliable - it either does not work or crashes on many different systems. As Akeo says, it also modifies the whitelist of the target system and so compromises it 'permanently' unless you later remove the entry from the firmware db.

 

 

Currently, I use the Kaspesky shim with A1ive's grub2 and agFM. The Kaspersky shim is signed by Microsoft and so Secure Boots. This runs sbpolicy from the grub.cfg file which 'self-signs' the grubx64.efi file before loading it. Once the grubfmx64.efi file (a1ives grub2) runs, he (somehow) modifies the readonly UEFI Secure Boot Flag to report 'false' instead of 'true'. This allows his grub2 to run signed or unsigned EFI files or linux16 kernels, etc. We can thus use dd to modify the disks or run any payload we like!

 

Microsoft did try to blacklist the shim a few months ago which caused havoc as they quickly found out it was being used by others (AVG\Avast and some notebook OEMs?). I guess at some stage they will roll out the blacklist update again, but until then we have complete freedom to boot anything we like as long as the Secure Boot enabled system does not ask for a password and will boot from an external USB drive.

 

Hi Steve,

 

The patch actually depends on the  initramfs structure of the distro which very few changes. For example, all the centos 7.X and 8.X share the same initramfs structure. So it doesn't need to update ventoy all the time.



#93 alz52879

alz52879

    Newbie

  • Members
  • 19 posts
  •  
    Germany

Posted 19 May 2020 - 06:49 PM

@ winb

Sorted!

1. Install Ventoy.

2. Reformat the exFat partition -> ntfs

3. Edit grub\grub.cfg the way you've shown.

4. Copy grub_Linux.cfg to the ntfs partition with the following menuentry:

menuentry 'Porteus-Kiosk' {
	set root='hd0,msdos3'
	linux /boot/vmlinuz
	initrd /boot/initrd.xz
} 

5. Resize the "ntfs" partition.

6. Create a new Fat32 partition.

7. dd if=/home/tux/Desktop/Kiosk.iso of=/dev/sda3   (sda3 is the newly created Fat32 partition)

8. Boot Porteus-Kiosk from the Grub2 menu.


  • wimb likes this

#94 steve6375

steve6375

    Platinum Member

  • Developer
  • 7565 posts
  • Location:UK
  • Interests:computers, programming (masm,vb6,C,vbs), photography,TV,films
  •  
    United Kingdom

Posted 19 May 2020 - 07:20 PM

well done

or you could

1. Create E2B+agFM USB drive

2. Copy over ISO file to first NTFS partition

3. Make file contiguous

4. MBR or UEFI boot directly to Porteus-Kiosk ISO

 

:)

Attached Thumbnails

  • porteus1.JPG
  • porteus2.JPG
  • porteus3.JPG

  • wimb likes this

#95 wimb

wimb

    Platinum Member

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

Posted 19 May 2020 - 08:17 PM

@alz52879

Ok, Good to hear about succes  :)

So it means that the Grub2 Menu is only shown when there is a valid entry in grub_Linux.cfg.

And (hd0,msdos3) is indeed where booting of Porteus-Kiosk must start in your case.

 

@steve6375

Good that you can use E2B+agFM for booting Porteus Kiosk ISO  :)

But this Kiosk ISO is a dangerous thing since it easily can destroy the booting of your USB drive  :ph34r:  in creating the bootable ISO



#96 alacran

alacran

    Platinum Member

  • .script developer
  • 2710 posts
  •  
    Mexico

Posted 19 May 2020 - 09:16 PM

Open Up ....  ;) 

 

In Ventoy 1.0.10 you can reformat the 1st partition with NTFS FileSystem, so that you can Boot with

- Win10x64 VHD as FILEDISK from a1ive Grub2 FileManager Or direct from Windows Boot Manager Menu in BIOS or UEFI mode

- Win10XPE boot.wim in RAMDISK loaded from a1ive Grub2 FileManager Or direct from Windows Boot Manager Menu in BIOS or UEFI mode

- Windows Boot Manager Menu in BIOS or UEFI mode

- Grub4dos Menu - in BIOS mode only

- Grub2 Menu in BIOS or UEFI mode

 

- Fedora-Workstation-Live-x86_64-32-1.6.iso Fails to Boot from Ventoy Menu when located on NTFS partition of Portable SSD

- runtimelivecd.iso Fails to Boot from Ventoy Menu, but is booting OK when using Grub4dos or Grub2 Menu entries.

 

On the Ventoy Hidden EFI partition I have modified file grub\grubcfg as shown below to add Boot options for Windows Boot Manager and for Grub4dos and Grub2 Menu

and I have added the necessary files to Ventoy NTFS Drive as illustrated in the Screenshot.

For booting in UEFI mode with Windows Boot Manager I have added the EFI\Microsoft folder to EFI folder on the Hidden EFI drive of Ventoy.

The files jpn_boot.ttf and kor_boot.ttf in folder Microsoft\Boot\Fonts were removed previously since there is not enough space in Ventoy Hidden EFI drive.

 

Ventoy EFI Drive file grub\grub.cfg

#Main menu
if [ $ventoy_img_count -gt 0 ]; then
    if [ $VTOY_DEFAULT_MENU_MODE -eq 0 ]; then
        vt_dynamic_menu 0 0 
    else
        vt_dynamic_menu 0 1
    fi

    if [ "${grub_platform}" == "efi" ] -a [ -e "(hd0,msdos2)/EFI/Microsoft/Boot/bootmgfw.efi" ]; then
    menuentry "Windows EFI BootManager" {
      chainloader (hd0,msdos2)/EFI/Microsoft/Boot/bootmgfw.efi
    }
    fi

    if [ "${grub_platform}" == "pc" ] -a [ -e "(hd0,msdos1)/bootmgr" ]; then
    menuentry "Windows BootManager" {
      chainloader (hd0,msdos1)+1
    }
    fi

    if [ "${grub_platform}" == "pc" ] -a [ -e "(hd0,msdos1)/grub.exe" ]; then
    menuentry "Grub4dos Menu" {
        linux (hd0,msdos1)/grub.exe
    }
    fi

    if [ -e (hd0,msdos1)/grub_Linux.cfg ]; then
    menuentry "Grub2 Menu" {
      set iso_drive=(hd0,msdos1)
      export iso_drive
      configfile (hd0,msdos1)/grub_Linux.cfg
    }
    fi

else
    menuentry "No ISO files found (Press enter to reboot ...)" {
        echo -e "\n    Rebooting ... "
        reboot
    }
fi

:cheers:

It works very fine.  As you know we can access EFI partition when booting from Win10XPE_x64.ISO to add all requiered.

 

Also I can confirm if we reduce the NTFS partition and add a new Fat-32 partition, our Ventoy USB device do not boot as usually, but going back to previous layout fixes the issue.

 

Alternatively and easier option to access EFI partition is to change EFI partition ID from your running OS by means of BootIce from EF to 0E, this way EFI partition will be permanently  available from the OS (Win7 & Win8.x require diskmod to see more than a single partition on a USB flash device).

 

@ Ventoy:

 

Thanks for this new version, it is more versatile now.

 

But if you don't mind I have a request:

 

Could you make EFI partition bigger, lets say 64 MB?

 

This will allow put there all files/folders added to Ventoy NTFS partition on wimb's approach, keeping both BCDs on same EFI partition, and easier to update/modify by means of wimb's UEFI_MULTI or VHD_WIMBOOT,

 

alacran


  • wimb likes this

#97 devdevadev

devdevadev

    Silver Member

  • Advanced user
  • 539 posts
  •  
    India

Posted 19 May 2020 - 11:45 PM

@steve6375
Good that you can use E2B+agFM for booting Porteus Kiosk ISO :)
But this Kiosk ISO is a dangerous thing since it easily can destroy the booting of your USB drive :ph34r: in creating the bootable ISO

In E2B+agFM, we just copy ISO file and it just boot using partnew/E2B method.

What you mean by "it easily can destroy the booting of your USB drive :ph34r: in creating the bootable ISO" ??? How ???

AFAIK, E2B+agFM does not create the bootable ISO. It just boot copied ISO using partnew approach without any modifications in copied ISO ...

BTW, there is no need to create an extra (hd0,msdos3) FAT32 Partition just for booting Kiosk.iso ? Why not just keep Kiosk.iso in the NTFS partition and boot using partnew approach via agFM ? May be Ventoy option in latest a1ive agFM can also boot the Kiosk.iso directly from NTFS partition ?

#98 ventoy

ventoy

    Member

  • Members
  • 83 posts
  •  
    China

Posted 20 May 2020 - 12:46 AM

It works very fine.  As you know we can access EFI partition when booting from Win10XPE_x64.ISO to add all requiered.

 

Also I can confirm if we reduce the NTFS partition and add a new Fat-32 partition, our Ventoy USB device do not boot as usually, but going back to previous layout fixes the issue.

 

Alternatively and easier option to access EFI partition is to change EFI partition ID from your running OS by means of BootIce from EF to OE, this way EFI partition will be permanently  available from the OS (Win7 requires diskmod to see more than a single partition on a USB flash device).

 

@ Ventoy:

 

Thanks for this new version, it is more versatile now.

 

Bu tif you don't mind I have a request:

 

Could you make EFI partition bigger, lets say 64 MB?

 

This will allow put there all files/folders added to Ventoy NTFS partition on wimb's approach, keeping both BCDs on same EFI partition, and easier to update/modify by means of wimb's UEFI_MULTI or VHD_WIMBOOT,

 

alacran

 

Maybe in Ventoy 2.X .... :)


Edited by ventoy, 20 May 2020 - 12:47 AM.

  • devdevadev likes this

#99 wimb

wimb

    Platinum Member

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

Posted 20 May 2020 - 03:55 AM

It works very fine.  As you know we can access EFI partition when booting from Win10XPE_x64.ISO to add all requiered.

 

Also I can confirm if we reduce the NTFS partition and add a new Fat-32 partition, our Ventoy USB device do not boot as usually, but going back to previous layout fixes the issue.

 

Alternatively and easier option to access EFI partition is to change EFI partition ID from your running OS by means of BootIce from EF to 0E, this way EFI partition will be permanently  available from the OS (Win7 requires diskmod to see more than a single partition on a USB flash device).

 

@ Ventoy:

 

Thanks for this new version, it is more versatile now.

 

But if you don't mind I have a request:

 

Could you make EFI partition bigger, lets say 64 MB?

 

This will allow put there all files/folders added to Ventoy NTFS partition on wimb's approach, keeping both BCDs on same EFI partition, and easier to update/modify by means of wimb's UEFI_MULTI or VHD_WIMBOOT,

 

alacran

 

Thanks for testing :) my approach to make a MultiBoot Ventoy Drive with support for booting VHD and WIM files in Windows BootManager and Grub4dos Menu and adding Grub2 Menu.

 

I support the request of alacran to make EFI partition bigger, lets say 128 MB so that all added boot files for my approach can be accomodated on the EFI partition.

The EFI partition must be FAT32 with BOOTMGR BootSector instead of unbootable FAT BootSector so that UEFI_MULTI or VHD_WIMBOOT can be used

to make Windows BootManager Menu for booting in BIOS and UEFI mode and Grub4dos Menu for booting in BIOS mode.

The extra space is also useful for making screenshots and may be needed in future ....

 

It would also be handy if we easy e.g. by Hotkey can switch the terminal_output between gfxterm and console

For booting Windows Boot Manager Menu the value console is needed, otherwise sometimes Windows Boot Manager Menu does not appear.

 

The Hidden EFI partition can easily assigned a Drive Letter by means of DiskPart

 

 

- In Ventoy first the Hidden EFI Drive on USB must be made visible

  In Windows 10x64 use DiskPart > list vol - select vol of EFI (in my case nr 14) as illustrated - assign - EFI drive is mounted as Q:

  Also possible is: After booting with Win10XPE from RAMDISK the Hidden EFI Drive is auto mounted

 


#100 wimb

wimb

    Platinum Member

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

Posted 20 May 2020 - 04:03 AM

In E2B+agFM, we just copy ISO file and it just boot using partnew/E2B method.

What you mean by "it easily can destroy the booting of your USB drive :ph34r: in creating the bootable ISO" ??? How ???

AFAIK, E2B+agFM does not create the bootable ISO. It just boot copied ISO using partnew approach without any modifications in copied ISO ...

BTW, there is no need to create an extra (hd0,msdos3) FAT32 Partition just for booting Kiosk.iso ? Why not just keep Kiosk.iso in the NTFS partition and boot using partnew approach via agFM ? May be Ventoy option in latest a1ive agFM can also boot the Kiosk.iso directly from NTFS partition ?

 

If you add the downloaded Porteus-Kiosk-5.0.0-x86_64.iso to Ventoy Drive and launch it in Ventoy Menu with agFM partnew

then configuring the ISO involves writing to the USB Drive so that the original Ventoy way of booting is destroyed and you only can boot in BIOS mode with KIOSK  :ph34r:

The USB does not have drive letter anymore and you need to wipe or clean the drive with DiskPart and create new partition to make it usable again .....






7 user(s) are reading this topic

0 members, 7 guests, 0 anonymous users