319 replies to this topic

[steve6375]

P.S. When testing booting from USB ALWAYS switch off PC each time - do NOT use a warm boot\restart.

[EoflaOE]

Thanks Wonko and Steve! I will try out this tool tomorrow because it's night in my time.

[reist]

Greetings.

Is there any way to launch Acronis True Image and Acronis Disk Director using their dat files (init.DAT, kernel.DAT, key.DAT)?

 

 

Using grub4dos everything works.

title Acronis True Image 2019
kernel /_Acronis_True_Image/2019_kernel.DAT vga=0x318 quiet acpi=off noapic quiet 
initrd /_Acronis_True_Image/2019_init.DAT /_Acronis_True_Image/2019_key.DAT


title Acronis Disk Director 12.5
kernel /_Acronis_Disk_Director/12_kernel.DAT vga=0x318 quiet acpi=off noapic quiet 
initrd /_Acronis_Disk_Director/12_init.DAT /_Acronis_Disk_Director/12_key.DAT

[ventoy]

• 2020/08/01 --- 1.0.18 release

1. Support some unix distros: FreeBSD pfSense GhostBSD FreeNAS XigmaNAS
2. Optimization for booting Tails distro
3. Ignore the 0xEF partition type when checking local version
4. New ISO support (total 450+)
   • GhostBSD-20.04.1.iso (Legacy + UEFI)
   • FreeNAS-11.3-U4.1.iso (Legacy + UEFI)
   • FreeNAS-11.2-U8.iso (Legacy + UEFI)
   • XigmaNAS-x64-LiveCD-12.1.0.4.7683.iso (Legacy + UEFI)
   • pfSense-CE-2.5.0-DEVELOPMENT-amd64-latest.iso (Legacy + UEFI)
   • pfSense-CE-2.4.5-RELEASE-p1-amd64.iso (Legacy + UEFI)
   • pfSense-CE-2.3.5-RELEASE-amd64.iso (Legacy)
   • pfSense-CE-2.3.4-RELEASE-amd64.iso (Legacy)
   • pfSense-CE-2.3.5-RELEASE-i386.iso (Legacy)
   • FreeBSD-13.0-CURRENT-amd64-20200730-r363681-disc1.iso (Legacy + UEFI)
   • FreeBSD-12.1-RELEASE-amd64-dvd1.iso (Legacy + UEFI)
   • FreeBSD-12.0-RELEASE-amd64-dvd1.iso (Legacy + UEFI)
   • FreeBSD-12.1-RELEASE-i386-disc1.iso (Legacy)
   • FreeBSD-12.0-RELEASE-i386-dvd1.iso (Legacy)
   • FreeBSD-11.4-RELEASE-amd64-disc1.iso (Legacy + UEFI)
   • FreeBSD-11.3-RELEASE-amd64-disc1.iso (Legacy + UEFI)
   • FreeBSD-11.2-RELEASE-amd64-dvd1.iso (Legacy + UEFI)
   • FreeBSD-11.1-RELEASE-amd64-bootonly.iso (Legacy + UEFI)
   • FreeBSD-11.0-RELEASE-amd64-dvd1.iso (Legacy + UEFI)
   • FreeBSD-11.4-RELEASE-i386-disc1.iso (Legacy)
   • FreeBSD-11.2-RELEASE-i386-bootonly.iso (Legacy)
   • FreeBSD-11.1-RELEASE-i386-bootonly.iso (Legacy)
   • FreeBSD-11.0-RELEASE-i386-dvd1.iso (Legacy)
   • FreeBSD-10.3-RELEASE-amd64-disc1.iso (Legacy)
   • FreeBSD-10.1-RELEASE-amd64-dvd1.iso (Legacy)
   • FreeBSD-10.1-RELEASE-i386-dvd1.iso (Legacy)
   • FreeBSD-10.0-RELEASE-amd64-disc1.iso (Legacy)
   • FreeBSD-9.3-RELEASE-amd64-dvd1.iso (Legacy)
   • FreeBSD-9.3-RELEASE-i386-dvd1.iso.iso (Legacy)

[ventoy]

• 2020/08/14 --- 1.0.19 release

1. Experimental support for booting IMG file (only two Linux distros supported now)
2. Boot menu over serial supported, see Notes
3. Optimization for booting Solus distro
4. Optimization for booting .efi file
5. Fixed a bug about booting Debian-10.5.0
6. Fixed a bug about install Ventoy to a 2TB+ disk, issue #387
7. New image support
   • easy-2.3.2-amd64.img (Legacy + UEFI)
   • volumio-2.799-2020-07-16-x86.img (Legacy + UEFI)
8. New iso support (total 470+)
   • deepin-live-system-2.0-amd64.iso (Legacy + UEFI)
   • Endless OS eos-eos3.8-amd64-amd64.200706-185259.base.iso (Legacy + UEFI)
   • Endless OS eos-eos3.7-amd64-amd64.200210-201928.base.iso (Legacy + UEFI)
   • PhoenixOSInstaller_v3.6.1.564_x64.iso (Legacy + UEFI)
   • PhoenixOSInstaller-v1.6.1.319-x86.iso (Legacy)
   • SteamOSDVD.iso (Legacy + UEFI)
   • hyperbola-milky-way-v0.3.1-dual.iso (Legacy + UEFI)
   • debian-10.5.0-amd64-xfce-CD-1.iso (Legacy + UEFI)
   • vyos-1.3-rolling-202008112114-amd64.iso (Legacy + UEFI)
   • FuryBSD-12.1-XFCE-2020042001.iso (Legacy + UEFI)
   • EasyNAS.x86_64-1.0.0_Beta_5.install.iso (Legacy + UEFI)
   • supergamer_v6.iso (Legacy + UEFI)
   • Live-Raizo-v11.20.06.28p.iso (Legacy + UEFI)
   • OPNsense-20.7-OpenSSL-dvd-amd64.iso (Legacy + UEFI)
   • swiftlinux-19.2-x64-TaylorSwift-2020-0812-061403.iso (Legacy + UEFI)
   • RebeccaBlackOS_amd64.iso (Legacy + UEFI)
   • RebeccaBlackOS_i386.iso (Legacy)
   • daphile-20.08-x86_64.iso (Legacy + UEFI)
   • crux-3.5.iso (Legacy + UEFI)
   • UCS_4.4-1-amd64.iso (Legacy + UEFI)
   • UfficiozeroMantova2.0.1.iso (Legacy + UEFI)
   •  

Edited by ventoy, 15 August 2020 - 02:18 AM.

[ventoy]

• 2020/08/30 --- 1.0.20 release

1. Fixed a bug about booting Debian i386 netinstall.iso
2. Change the default directory and file permissions in linux tarball issue #392
3. New image support
   • Lakka-Generic.x86_64-2.3.2.img (Legacy + UEFI)
   • LibreELEC-Generic.x86_64-9.2.3.img (Legacy + UEFI)
   • freedombox-stable-free_buster_all-amd64.img (Legacy + UEFI)
   • paldo-live-x86_64-stable.img (Legacy + UEFI)
   • ubos_yellow_x86_64-pc_20200817-001259.img (Legacy + UEFI)
   • recalbox-x86_64.img (Legacy + UEFI)
   • batocera-5.26-x86_64-20200527.img (Legacy + UEFI)
   • memtest86-usb.img (UEFI)
4. New iso support (total 550+)
   • wifislax-4-12-final.iso (Legacy)
   • MidnightBSD-1.2--amd64-uefi-disc1.iso (Legacy + UEFI)
   • MidnightBSD-1.2--i386-disc1.iso (Legacy)
   • HP SPP P03093_001_spp-Gen8.1-SPPGen81.4.iso (Legacy + UEFI)
   • HP SPP P26940_001_spp-2020.03.0-SPP2020030.2020_0319.22.iso (Legacy + UEFI)
   • hardenedbsd-12-stable-amd64-disc1.iso (Legacy + UEFI)
   • rescurezilla-1.0.6.1-64bit.iso (Legacy + UEFI)
   • garuda-xfce-lite-200726-linux-zen.iso (Legacy + UEFI)
   • debian-edu-10.5.0-amd64-netinst.iso (Legacy + UEFI)
   • minimal_linux_live_15-Dec-2019_64-bit_mixed.iso (Legacy + UEFI)
   • nethserver-7.8.2003-x86_64.iso (Legacy + UEFI)
   • osgeolive-13.0-amd64.iso (Legacy + UEFI)
   • pardus_topluluk_4.2_9.10.2018_xfce_64bit.iso (Legacy + UEFI)
   • Pinguy_OS_18.04.2_Full-LTS_x86-64.iso (Legacy + UEFI)
   • debian-9.9.0-amd64-netinst-Elastix.iso (Legacy + UEFI)
   • aryalinux-gnome-2.4-x86_64.iso (Legacy + UEFI)
   • efw_community-x64_3.3.0_recovery_softwarex86-64_20181026164637.iso (Legacy + UEFI)
   • hamara-sugam-live-2.1-final-amd64.iso (Legacy + UEFI)
   • Rocks Cluster kernel-7.0-0.x86_64.disk1.iso (Legacy + UEFI)
   • MorpheusArch_2018.4-2018.4-x86_64.iso (Legacy + UEFI)
   • smeserver-9.2-x86_64.iso (Legacy + UEFI)
   • apodio12-beta0.4.1.iso (Legacy + UEFI)
   • lin-comm-server-2019.iso (Legacy + UEFI)
   • PeachOSI.Patriot.19.4.18.04.64bit.LTS.iso (Legacy + UEFI)
   • photon-minimal-3.0-a383732.iso (Legacy + UEFI)
   • plamo-6.2_x86_64_dvd.iso (Legacy + UEFI)
   • SuperX_5.0_Lamarr_build416_amd64.iso (Legacy + UEFI)
   • Bicom serverware-3.3.0.iso (Legacy + UEFI)
   • ploplinux-19.4-x86_64.iso (Legacy + UEFI)
   • lliurex-servidor_64bits_19_latest.iso (Legacy + UEFI)
   • omarine-7.0-dvd.iso (Legacy + UEFI)
   • freespire-6.iso (Legacy + UEFI)
   • DietPi_NativePC-UEFI-x86_64-Buster.iso (Legacy + UEFI)
   • boss-8.0-amd64-DVD-301019.iso (Legacy + UEFI)
   • Pisilinux-2.1.2-Mehmetcik-UEFI_KDE_x86_64.iso (Legacy + UEFI)
   • t2-minimal-glibc-gcc-x86-64-r49128.iso (Legacy + UEFI)
   • blackPantherOS-v18.1SE-x86_64-Renegade-DVD.iso (Legacy + UEFI)
   • pld-new-rescue-th2018-1.6-64bit.iso (Legacy)
   • clonos-19.09-release.iso (Legacy)
   • Vine65-DVD-x86_64.iso (Legacy)
   • Vine65-DVD-i686.iso (Legacy)
   • Vine63-CD-x86_64.iso (Legacy)
   • kolibri.iso (Legacy)
   • Omoikane dvdboot.iso (Legacy)
   • redorescue-2.0.4.iso (Legacy)
   • Secure-K OS live-image-amd64.iso (Legacy)
   • slackellive64-openbox-7.3.iso (Legacy)
   • dragora-3.0-x86_64-beta1-live.iso (Legacy)
   • Express-3.1-SP4-i586.iso (Legacy)
   • Express-3.1-SP4-x86_64.iso (Legacy)
   • lunar-1.7.0-x86_64.iso (Legacy)
   • lunar-1.7.0-i686.iso (Legacy)
   • TENS-3.0.0_public.iso (Legacy)
   • rancheros.iso (Legacy)
   • smgl-test-quinq-x86_64-20090608.iso (Legacy)
   • alpine-standard-3.12.0-x86_64.iso (Legacy + UEFI)
   • alpine-standard-3.12.0-x86.iso (Legacy)
   • alpine-extended-3.12.0-x86.iso (Legacy)
   • Webconverger-e43e9c8b34bc8aac292762556b1b847e70516f52.iso (Legacy)

[steve6375]

FWIW - you can now easily add/update any new version of Ventoy onto an Easy2Boot v2 USB drive.

1. Make an E2B+agFM  drive using E2B v2.05d Beta

2. Update agFM to latest v1.57Beta3 version 

3. Download Ventoy ZIP file from Ventoy website (recent version)

4. Drag-and-drop the Ventoy .zip file onto the \e2b\Update agFM\Add_Ventoy.cmd file (on 2nd partition)

 

https://rmprepusb.bl...oy-support.html

 

You can now MBR-boot to E2B grub2dos menu and then MBR-boot to Ventoy

or

UEFI64-boot (even Secure boot) to agFM menu (grub2) and then press F5 to boot to UEFI64 Ventoy.

 

A side-affect of this is that you should able to secure UEFI64-boot to Ventoy via agFM.

 

[ventoy]

FWIW - you can now easily add/update any new version of Ventoy onto an Easy2Boot v2 USB drive.

1. Make an E2B+agFM  drive using E2B v2.05d Beta

2. Update agFM to latest v1.57Beta3 version 

3. Download Ventoy ZIP file from Ventoy website (recent version)

4. Drag-and-drop the Ventoy .zip file onto the \e2b\Update agFM\Add_Ventoy.cmd file (on 2nd partition)

 

https://rmprepusb.bl...oy-support.html

 

You can now MBR-boot to E2B grub2dos menu and then MBR-boot to Ventoy

or

UEFI64-boot (even Secure boot) to agFM menu (grub2) and then press F5 to boot to UEFI64 Ventoy.

 

A side-affect of this is that you should able to secure UEFI64-boot to Ventoy via agFM.

 

There is a problem in some special case.

Ventoy will write a UUID to the 1st sector(MBR) when install and this UUID is used by Ventoy after boot the image (both legac and UEFI).

The UUID is used to distinguish USB disks if there are more than one USB disks with the same size.

Edited by ventoy, 07 September 2020 - 01:30 AM.

[steve6375]

By UUID do you mean the Disk Signature bytes (1B8h-1BBh)?

Where is the UUID recorded and can it be updated so that the USB stick is recognised as a Ventoy disk?

When is the disk UUID used by Ventoy?

[Wonko the Sane]

Only to use common terminology .

The UUID by definition is for volumes.

If it is written to the MBR it is the Disk Signature (and NOT an UUID).

 

Wonko

[ventoy]

By UUID do you mean the Disk Signature bytes (1B8h-1BBh)?

Where is the UUID recorded and can it be updated so that the USB stick is recognised as a Ventoy disk?

When is the disk UUID used by Ventoy?

 

NO, it's NOT disk signature, that is just for Windows.

In order to distinguish disks, Ventoy will write a UUID (16 bytes) to offset 0x180 of MBR.

That is to say, Ventoy reserve a "hole" in the MBR's boot code for this UUID.

Ventoy will write a random UUID to this position for every USB drive when install Ventoy to it. Not a fixed UUID.

 

When boot an ISO file, after the kernel is booted, Ventoy's hook script will search all the disks to check whether it is Ventoy disk.

First it will check the disk size, if there are more than one disks with the same size as Ventoy disk then UUID will be used.

Edited by ventoy, 07 September 2020 - 09:52 AM.

[steve6375]

OK - so there will only be a problem if more than one Ventoy disks in same system AND they are of the same size.

1. How is a disk determined to be a 'ventoy disk'? By looking for a folder+file on a certain partition?
2. Why not use Disk Signature? I thought it was a standard for all disks?
3. How does Ventoy know that the UUID at 0x180 belongs to the current booted ventoy? It must embed the UUID when the USB disk is made - so where is the UUID embedded?

Wiki says 'The disk signature was introduced by Windows NT version 3.5, but it is now used by several operating systems, including the Linux kernel version 2.6 and later. GNU/Linux tools can use the NT disk signature to determine which disk the machine booted from'

[Wonko the Sane]

Then let's call this HDUUID or Ventoy Dik UUID to avoid confusion.

 

IMHO it is unneeded, as disks are traditionally identified by Disk Signature in a manner (8 bytes) that is usually good enough to avoid collisions.

 

Wonko

[ventoy]

OK - so there will only be a problem if more than one Ventoy disks in same system AND they are of the same size.

1. How is a disk determined to be a 'ventoy disk'? By looking for a folder+file on a certain partition?
2. Why not use Disk Signature? I thought it was a standard for all disks?
3. How does Ventoy know that the UUID at 0x180 belongs to the current booted ventoy? It must embed the UUID when the USB disk is made - so where is the UUID embedded?

Wiki says 'The disk signature was introduced by Windows NT version 3.5, but it is now used by several operating systems, including the Linux kernel version 2.6 and later. GNU/Linux tools can use the NT disk signature to determine which disk the machine booted from'

 

1、Ventoy will pass the UUID as part of ventoy os paramter to OS. Not looking for files, because many Linux distros can't mount exFAT/NTFS partition.

2、As you said, disk signature was used by windows, I'm not sure that whether the OS will overrite it or not. So I design this UUID from the first release of Ventoy. With this I can 100% confirm that it will work.

3、As Q1, the UUID was passed to the OS and ventoy look for disk by the UUID in OS.

[steve6375]

Are you saying that the source Ventoy disk is first identified by its size only - and if there is more than one disk in the system of exactly the same size, then it is identified by the Ventoy-UUID?

Since all the Disk Signatures in a system should always be unique, it would be better to simply use the Disk Signature?

[Wonko the Sane]

@Ventoy

Again, we already have enough confusion in terminology, you use an UUID value written to an arbitrary offset in the MBR that is incompatible with anything else (no worry, even the grub4dos UMBR and my little modified BIOS on GPT MBR use values at non-standard or arbitrary offsets[1]).

That is fine, the risk here is to confuse people with the UUID terminology.

What everyone knows about is "volume UUID" which is commonly shortened to "UUID" (in the context of volumes/booting/etc.) if you call your peculiar way of signing with an unique ID the hard disk in the MBR "UUID" as well, you contribute to this confusion.

 

Wonko

 

[1] the difference, if I may, i that in the UMBR and BIOS on GPT mbr these values are needed and cannot be put anywhere else, in your case there is an already working and "standard" method to uniquely identify a disk which is the Disk Signature (where while the theoretical risk of a collision is higher it never happened on the millions or billions sytems where the Disk Signature has been used in the last - say - 25 years ).

Only for the record as soon as a Disk is connected to a Windos NT system there are three possibilities:
1) there is no other disk connected to the same system with the same disk signature <- nothing happens to the Disk Signature
2) there is a Disk Signature of 00000000 <- a new Disk Signature is immediately generated and written to the MBR
3) the Disk Signature is the same of another disk on the system <- a new Disk Signature is immediately generated and written to the MBR

 

The ONLY case where a Disk Signature is changed by the OS in a way that can alter the dunctioning of a bootable disk is then #3, i.e. ONLY in the case of a collision, something that is very, very, very improbable and NEVER was reported (if not in the special case of fiddling with "clones")

[ventoy]

Are you saying that the source Ventoy disk is first identified by its size only - and if there is more than one disk in the system of exactly the same size, then it is identified by the Ventoy-UUID?

Since all the Disk Signatures in a system should always be unique, it would be better to simply use the Disk Signature?

YES.

As I said above, I'm not sure that whether OS will override the signature and whether two USB drives will be written a same signature in two different computers (if they pluged in the same computer later ...) ... 

So this is a 100% safe way and used from the beginning of Ventoy.

[steve6375]

Disk Signature should be safe to use because it is used by Windows and Linux already. They rely on each disk having a different Disk Signature.

 

I would have thought that the chance of two drives having the same Disk Signature is the same whether Windows\Linux assigns a random Disk Signature or whether the Ventoy2Disk.exe assigns a random UUID - also Windows\Linux will ensure that the new MBR has a unique Disk Signature.

 

I have seen that if Ventoy2Disk.exe is used under Windows to create a USB drive, the Disk Signatures are different every time.

[Wonko the Sane]

YES.

As I said above, I'm not sure that whether OS will override the signature and whether two USB drives will be written a same signature in two different computers (if they pluged in the same computer later ...) ... 

So this is a 100% safe way and used from the beginning of Ventoy.

 

Sorry, our posts overlapped.

 

An existing Disk Signature won't ever be re-written unless there is a collision and each time a new one is generated the probability i 1/2^32, such a collision was never reported.

 

The Disk Signature is 99.99999999% safe and used since the beginning of NT (1993 or 1994).

 

Wonko

 

EDIT: fixed a few typos

[steve6375]

Using Disk Signature instead of Ventoy-UUID would mean Ventoy can be added to other disks which were not made by Ventoy2Disk.exe.

[ventoy]

Sorry, our posts overlapped.

 

An existing Disk Signature won't ever be re-written unle there is a colliion and each time a new one is generated the probability i 1/2^32, such a collision was never reported.

 

The Disk Signature is 99.99999999% safe and ued ince the beginning of NT (1993 or 1994).

 

Wonko

 

Maybe.  Ventoy UUID was used from the beginning, so I don't want to change it.

[ventoy]

Using Disk Signature instead of Ventoy-UUID would mean Ventoy can be added to other disks which were not made by Ventoy2Disk.exe.

 

Ventoy was designed and tested as a whole solution. So I don't think it's a good idea to boot Ventoy from a disk that was not created by Ventoy2Disk.

[steve6375]

I understand that - but why not first use Disk Signature and if that is not unique (which it always will be!)  then use your size + Ventoy-UUID as before. This means Ventoy can be used on disks which were not made by Ventoy2disk.exe.

[Wonko the Sane]

I understand that - but why not first use Disk Signature and if that is not unique (which it always will be!)  then use your size + Ventoy-UUID as before. This means Ventoy can be used on disks which were not made by Ventoy2disk.exe.

This seems to me a very smart solution to workaround the "absolutism" of  the "all your MBR belong to us" current approach while guaranteeing the 0.00000000001% collision safery that is theoretically (and theoretically only)  missing.  

 

If this is correct:

 

 

 

Project started on 2020-04-05 (So, it is fresh, and a work in progress)

 

the "from the beginning" translates to "since 4 months" (and by a small subset of PC users) not really comparable with 25 years and millions or billions.

 

Wonko

[ventoy]

I understand that - but why not first use Disk Signature and if that is not unique (which it always will be!)  then use your size + Ventoy-UUID as before. This means Ventoy can be used on disks which were not made by Ventoy2disk.exe.

 

Ventoy's os parameter structure was defined according to the orignal design of ventoy.

If I use disk signature I have to add this to the parameter. So I prefer to maintain the status.

 

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.

Edited by ventoy, 07 September 2020 - 12:39 PM.