319 replies to this topic

[steve6375]

AFAIK disks with GPT have the Disk Signature in MBR.

 

Many people will want to use Ventoy on all types of disks in the future. It is a shame to limit it to just disks made by Ventoy2Disk.exe.

Many people are asking on Forums about calling Ventoy from other bootloaders or disks.

Why not change location 0x180 to use Disk Signature now whilst still in development?

 

Is there any other reason why only disks made using Ventoy2Disk.exe will work?

[Wonko the Sane]

Besides, I don't known what's the situation in GPT partition style. Ventoy's UUID is used in both MBR and GPT partition style in the same way.

So is Disk Signature AFAIK.
 

AFAIK disks with GPT have the Disk Signature in MBR.

Sure .
 

Wonko

[ventoy]

AFAIK disks with GPT have the Disk Signature in MBR.

 

Many people will want to use Ventoy on all types of disks in the future. It is a shame to limit it to just disks made by Ventoy2Disk.exe.

Many people are asking on Forums about calling Ventoy from other bootloaders or disks.

Why not change location 0x180 to use Disk Signature now whilst still in development?

 

Is there any other reason why only disks made using Ventoy2Disk.exe will work?

 

As I said above, Ventoy was desgined as a whole solution and I only test it in the disk created by Ventoy2Disk.

There are many assumptions hard coded in the source code and scripts. For example:

1. There must be partition 2 in the disk

2. The partition 2 must be ESP partition and the directory structure must be the same as created by Ventoy2Disk

3. The partition 1 must has a cluster size >= 2048

4. .... and maybe other conditions that I didn't even remember but has subconsciously used

 

In one word, the disk partition layout was designed as part of Ventoy.

Ventoy was not designed to work with chainload or in a disk manully parted.

And I really have no time and energy to fix bugs for this "unofficial" usage.

 

Anyway, Ventoy is 100% open source and anyone can fork and modify it as they want.

Edited by ventoy, 08 September 2020 - 01:27 AM.

[steve6375]

OK - so basically Ventoy can only be used on disks made with Ventoy2Disk.exe.

 

So the Ventoy Compatible structure that you are asking developers to build into ISOs is only any good if the USB disk is made using Ventoy2Disk?

So Ventoy Compatible is a very niche feature which is not very attractive to developers and so is very unlikely to be adopted.

 

You say partition 2 must be ESP - what does that mean? Does the disk need to be MBR or GPT or either? Does the partition type number have to be EF? It seems to work fine with a partition type number of 0C?

 

For >=2048 byte FAT cluster size, the Partition 2 would need to be >128MB for FAT32  or >64MB FAT16 under Windows. I am not sure about defaults used by Linux?

 

I am sure you and many others would wish Ventoy technology to become widely adopted. Several people have already added Ventoy into their own multiboot systems. At the very least you should precisely define it's disk\partition requirements and ensure it works with standard MBRs.

 

The most successful products are always those that are designed to be as compatible as possible.

[ventoy]

OK - so basically Ventoy can only be used on disks made with Ventoy2Disk.exe.

 

So the Ventoy Compatible structure that you are asking developers to build into ISOs is only any good if the USB disk is made using Ventoy2Disk?

So Ventoy Compatible is a very niche feature which is not very attractive to developers and so is very unlikely to be adopted.

 

You say partition 2 must be ESP - what does that mean? Does the disk need to be MBR or GPT or either? Does the partition type number have to be EF? It seems to work fine with a partition type number of 0C?

 

For >=2048 byte FAT cluster size, the Partition 2 would need to be >128MB for FAT32  or >64MB FAT16 under Windows. I am not sure about defaults used by Linux?

 

I am sure you and many others would wish Ventoy technology to become widely adopted. Several people have already added Ventoy into their own multiboot systems. At the very least you should precisely define it's disk\partition requirements and ensure it works with standard MBRs.

 

The most successful products are always those that are designed to be as compatible as possible.

 

1、Actually YES. When I designed Ventoy Compatible structure I only considered the disk layout created by Ventoy. It's just an initiative.

 

2、Partition2 must be ESP, not very accurate. Only need to be FAT filesystem.

 

3、cluster size >=2048 is just for partition 1 not partition 2.

 

 

To be honest, the widespread use of Ventoy is a bit beyond my expectation. I designed it just for my interest and without very very thorough consideration.

[steve6375]

Well there are very few good UEFI multiboot solutions available and modern systems are UEFI-only now.

Ventoy is unique and very innovative so I don't know why you are surprised that others want to use it too! 

[steve6375]

I see Ventoy 1.0.21 UEFI now has added a very annoying check!

 

I understand your reasons, however this message seems to be displayed even if the boot drive has a unique size.

 

Your said there will not be a problem with Ventoy if the boot USB disk has a unique total size - but this 10 second delay is still shown even if the USB drive has a unique total capacity and there is no other drive present of the same size.

 

It would be better to be compatible with a standard MBR and use the Disk Signature instead of your special MBR Ventoy-UUID. The MBR Disk Signature is used by Linux and Windows and is guaranteed to be present and unique by both OS's. Please consider using it if you want Ventoy technology to be adopted by others or at least change the 10-second delay to only warn if there will be a problem.

Attached Thumbnails

• 

[ventoy]

I see Ventoy 1.0.21 UEFI now has added a very annoying check!

 

I understand your reasons, however this message seems to be displayed even if the boot drive has a unique size.

 

Your said there will not be a problem with Ventoy if the boot USB disk has a unique total size - but this 10 second delay is still shown even if the USB drive has a unique total capacity and there is no other drive present of the same size.

 

It would be better to be compatible with a standard MBR and use the Disk Signature instead of your special MBR Ventoy-UUID. The MBR Disk Signature is used by Linux and Windows and is guaranteed to be present and unique by both OS's. Please consider using it if you want Ventoy technology to be adopted by others or at least change the 10-second delay to only warn if there will be a problem.

 

 

Well, I will change the check policy in the next release.

 

The Ventoy/UUID or disk signature is not a big problem, I can add the disk signature as one of the conditions to distinguish disks in the next release.

 

But otherwise there are still some necessary conditions for Ventoy to work. 

Just as I said before, Ventoy was not designed to work with chainload or other disk structure.

 

So the new check policy will be:

 

Necessary Conditions, for example: 

1. There must be partition 1 and partition 2

2. ISO/WIM/VHD/IMG/EFI files must in partition1

3. Partition1's filesystem must FAT/exFAT/NTFS/UFS/XFS/Ext234

4. Partition1's cluster size must >= 2048

5. Partition2 must in FAT file system and hold all the Ventoy's directories and files as installed with Ventoy2Disk

 

These conditions are necessary for Ventoy. So Ventoy will NOT continue to boot if any one of them is not satisfied.

 

If these conditions are all satisfied. Ventoy will continue to boot. 

But I still will show a tip for a disk structure NOT created by Ventoy2Disk. 

The tip can be in a not so annoying way, maybe only a "unofficial" word in the main screen.

 

Because I only tested all the 550+ image files in this way(directly booted from BIOS and with Ventoy's disk layout).

I cannot guarantee that you will not have any problems with other usage(in a different disk layout or chainload).

[Wonko the Sane]

Just thinking aloud , but maybe it would be possible to add to the second partition a "tag file" *like* Ventoy_unofficial.tag.

The Ventoy when booting could - once detected that the disk structure has not been created by Ventoy2disk - check for the presence of this file and read in it a timeout value, or if the file is not present go for the "full" 10 seconds warning.

 

But if the file exists and contains a line *like*:

Ventoy_Unofficial_Timeout=0

the timeout is reduced.

 

Wonko

[steve6375]

Yes - that would be great

1. Use Disk Signature

2. Check conditions - if fail then message + stop

3. If MBR not official then display 'Unofficial'

 

If anyone reports an issue with Ventoy to me, I always ask them to reproduce the issue using an 'official' Ventoy USB drive before reporting the issue to you anyway.

[HansBoot]

 

 

Well, I will change the check policy in the next release.

 

The Ventoy/UUID or disk signature is not a big problem, I can add the disk signature as one of the conditions to distinguish disks in the next release.

 

But otherwise there are still some necessary conditions for Ventoy to work. 

Just as I said before, Ventoy was not designed to work with chainload or other disk structure.

 

So the new check policy will be:

 

Necessary Conditions, for example: 

1. There must be partition 1 and partition 2

2. ISO/WIM/VHD/IMG/EFI files must in partition1

3. Partition1's filesystem must FAT/exFAT/NTFS/UFS/XFS/Ext234

4. Partition1's cluster size must >= 2048

5. Partition2 must in FAT file system and hold all the Ventoy's directories and files as installed with Ventoy2Disk

 

These conditions are necessary for Ventoy. So Ventoy will NOT continue to boot if any one of them is not satisfied.

 

If these conditions are all satisfied. Ventoy will continue to boot. 

But I still will show a tip for a disk structure NOT created by Ventoy2Disk. 

The tip can be in a not so annoying way, maybe only a "unofficial" word in the main screen.

 

Because I only tested all the 550+ image files in this way(directly booted from BIOS and with Ventoy's disk layout).

I cannot guarantee that you will not have any problems with other usage(in a different disk layout or chainload).

 

As we seemingly need an NTFS partition for VHDX boot but as I like an exFAT for copatibility, could the Partition 1 be futher divided in NTFS + exFAT?

 

ProtectMBR

Partition1 NTFS

Partition 2 exFAT

Partition 3 FAT Ventoy

Backup GPT

 

Or ist this the idea of the reserved space?

 

ProtectMBR

Partition1 NTFS

Partition 2 FAT Ventoy

Partition 3 Reserved space exFAT

Backup GPT

 

Thanks

Edited by HansBoot, 20 September 2020 - 04:46 PM.

[steve6375]

You can format Partition 1 to anything you like after making the USB drive.

Maybe the Ventoy2Disk.exe needs an option for Partition 1 to choose  NTFS or exFAT?

[alacran]

As we seemingly need an NTFS partition for VHDX boot but as I like an exFAT for copatibility, could the Partition 1 be futher divided in NTFS + exFAT?

 

Or ist this the idea of the reserved space?

As steve said: You can format Partition 1 to anything you like after making the USB drive.

 

On the reserved space you can make all partitions you want on that space when using GPT partitioning, on MBR you can create an extended partition on that space and several logical partitions into it.  Just as on any HD, of course this is when doing it from a Win10 v1703 or newer, or on older OSs if you have installed on your local OS diskmod.sys driver by Karyonix.

 

Just remember this:

 

2. ISO/WIM/VHD/IMG/EFI files must in partition1

 

alacran

[steve6375]

Ventoy only lists file on partition 1.

[HansBoot]

Thx.

 

Perfect.

 

Will try Partition 1 NTFS (for VHDX) and

 

reserved space with an exFAT Partition for data exchange (win/mac).

 

Nice!

[alacran]

Thx.

 

Perfect.

 

Will try Partition 1 NTFS (for VHDX) and

 

reserved space with an exFAT Partition for data exchange (win/mac).

 

Nice!

 

About using VHDX, I strongly recomend you better use VHD as much as possible.

 

From my Topic: http://reboot.pro/to...ips-and-tricks/

 

Unless your virtual disk requires more than 2 TB, do not use the VHDX format, VHD format is always preferable, as an example: MS Azure only accepts VHDs with a single partition.

 

I suggest you take a look to the mentioned topic for additional info.

 

alacran

[HansBoot]

Will dive into that info.

Much appreciated!!!

 

Despite the ventoy way.

 

Still trying to solve the mystery of booting Win10 from a thunderbolt3 enclosure (Thinkpad X1 Yoga 3rd/Orico TB3 enclosure/Samsung 970Pro 1TB). Drive is seen (preboot acl) but not listed in boot devices. I guess it's either boot vhd from bdc entry or using grub.

 

Idea was setting up 2 drives as native boot window installs (windows partition scheme) so that I can swap them if one goes bad. Put one in the TB3 enclosure so that I can boot from it if all fails. But maybe the vhd is a way better solution.

 

But that's another story, I guess. But any hint is welcome. I don't want to disrupt the topic here...

Edited by HansBoot, 20 September 2020 - 08:19 PM.

[HansBoot]

Just a quick update.

 

With your help I was able too boot VHD from Ventoy (NTFS partition + exFat Reserved Partition)

Sabrent EC-NVME-BLK (any PCB with JMS583 RevA2) + Samsung SM961

constant 1024MB/s R+W

 

 

*and* was able to boot VHD via Thunderbolt3 enclosure from NTFS partition by addingy a BCD entry

Yottamster NVMe enclosure (any PCB with JHL6340) + Samsung 970Pro 1TB

constant 2800MB/s R + 2200MB/s W

 

 

 

Thank you!

Edited by HansBoot, 22 September 2020 - 07:02 AM.

[wimb]

Just a quick update.

 

With your help I was able too boot VHD from Ventoy (NTFS partition + exFat Reserved Partition)

Sabrent EC-NVME-BLK (any PCB with JMS583 RevA2) + Samsung SM961

constant 1024MB/s R+W

 

 

*and* was able to boot VHD via Thunderbolt3 enclosure from NTFS partition by addingy a BCD entry

Yottamster NVMe enclosure (any PCB with JHL6340) + Samsung 970Pro 1TB

constant 2800MB/s R + 2200MB/s W

 

 

 

Does it boot in UEFI Secure mode and in MBR BIOS mode ?

NVMe might be problem for UEFI Secure mode 

 

Have a look at VHD_WIMBOOT to make USB Portable SSD booting Win10x64 in 25 GB VHD as FILEDISK in UEFI Secure and MBR BIOS mode

and with 3.9 GB Expandable VHD from RAMDISK in MBR BIOS mode

[HansBoot]

Does it boot in UEFI Secure mode and in MBR BIOS mode ?

NVMe might be problem for UEFI Secure mode 

 

Have a look at VHD_WIMBOOT to make USB Portable SSD booting Win10x64 in 25 GB VHD as FILEDISK in UEFI Secure and MBR BIOS mode

and with 3.9 GB Expandable VHD from RAMDISK in MBR BIOS mode

 

 

ThinkPad X1Y3

Just switched to UEFI Secure Boot enabled > Works fine. I guess the NVMe drive is just another PCIe lane

 

Thanks for your follow up! Will look into. Still learning.

Edited by HansBoot, 22 September 2020 - 10:53 AM.

[ventoy]

• 2020/09/27 --- 1.0.22 release

1. Add Linux vDisk boot plugin (install linux distro into a vhd/vdi/raw file and boot with Ventoy), see Notes
2. Change the check policy when Ventoy is running on a partition which is not created by Ventoy2Disk
3. Add disk signature to Ventoy os parameter structure
4. Fix bugs in Ventoy2Disk.sh for install Ventoy on NVMe disk
5. Fix a bug with error message null src bitmap in grub_video_bitmap_create_scaled
6. Add VTOY_SORT_CASE_SENSITIVE in global control plugin
7. Optimization for boot Manjaro series distros
8. New iso support
   • mAid_v2020-09-15_11-40_x86_64_forgetful.iso (Legacy + UEFI)

[kyl]

cannot get vdisk boot get to work. Installed mxlinux in virtualbox, applied script but when try to boot it i only get an error "can't find command 'vt_get_vtoy_type'. Unsupported vtoy type"

[ventoy]

cannot get vdisk boot get to work. Installed mxlinux in virtualbox, applied script but when try to boot it i only get an error "can't find command 'vt_get_vtoy_type'. Unsupported vtoy type"

 

You fresh install Ventoy-1.0.22 into an USB drive?

[kyl]

You fresh install Ventoy-1.0.22 into an USB drive?

no, its on ssd, but now i checked uefi and its working 

[@thehop]

Update available (very smart this tool - thank you!)

 

Ventoy 1.0.23 release

 

ventoy released this 8 hours ago

1. Make VTOY_DEFAULT_IMAGE avaliable in both ListView mode and TreeView mode
2. Add VTOY_TREE_VIEW_MENU_STYLE option in global control plugin
3. Change the default resolution to 1024x768
4. Pass ventoy runtime parameter to OS by ACPI table
5. Fix issue #521 (blackarch 2020.06.01 boot fail)
6. Fix issue #516 (archlinux 2020.10.01 boot fail in UEFI mode)
7. Fix issue #512 (file with name .iso)
8. Fix Parabola EFI booting (PR #508)
9. Fix a bug when booting VentoyLiveCD iso
10. New iso support
    • blackarch-linux-live-2020.06.01-x86_64.iso (Legacy + UEFI)
    • archlinux-2020.10.01-x86_64.iso (Legacy + UEFI)
    • GeckoLinux_STATIC_Mate.x86_64-152.200726.0.iso (Legacy + UEFI)
    • fossapup64-9.5.iso (Legacy + UEFI)

See https://www.ventoy.n...n/doc_news.html for detail.

 

Edited by @thehop, 16 October 2020 - 10:10 PM.