where any size is acceptable as long as it contains the Ventoy payload size 32M has been replaced by checking for a regular EFI partition case B: or for an EFI partition, checking if the VTOYEFI partition PMBR->PartTbl.StartSectorId != pMBR->PartTbl.StartSectorId + pMBR->PartTbl.SectorCount) the first one in sector order (which is the last one by number) here PartTbl is assumed to be GPT partitions: the "ventoyed" check is that Now, on a practical basis, if we use my 118G drive as an example, it currently is: Recreating a similar partition in gdisk type ef02 / guid 21686148-6449-6E6F-744E-656564454649 from 34 to 2047, which is often unused space on modern OS,ĭoing a cat or a dd to populate this new partition of their system drive with the boot record from their Ventoy drive,įor UEFI boot: by adding the Ventoy.efi payload to the EFI boot menu (using the bios or efibootmgr),įor automatic CSM boot with support for older OS: by making an hybrid MBR/GPT partition table with fdisk or gdisk (ok, it's something slightly hard, but if they can't do that, maybe they shouldn't try to use Ventoy this way.). They would also allow people to install Ventoy on their hard drive to boot Ventoy automatically when in CSM mode, or through a menu entry in UEFI mode, when adding Ventoy.efi after having "ventoyed" the hard drive by: Such changes would be a better way to identify the drive as "ventoyed": they more accurate and unique that just checking if the data partition starts at 2048, while also supporting better aligned Ventoy data partitions (4k, 8k.) In gdisk, I see you use the GPT type 0700 for the VTOYEFI partition: maybe you could move it to EF00 and check if it contains the Ventoy.EFI payload In fdisk, I noticed you have the MBR partition 1 be EE ("protective") : I would also suggest moving to an hybrid GPT/MBR partition table instead, using type EE for 1->2047 as a way to protect both the boot record and the 34->2047 partition, then following this first protective partition by the regular partitions: this would also make the Ventoy volumes accessible by older OS not supporting GPT partition tables, since after this protective partition you would have regular MBR partitions using the same offsets as the GPT partitions (example below) You could do that better by creating a 3rd GPT partition from 34 to 2047, type ef02 in gdisk, to "protect" the post MBR gap, which is something already recommended in some install guides cf around like 580 that triggers ventoy_warn_invalid_device() The core issue seems to be you hardcode 2048 as the start of the first partition: if the verification fails, it cause an error that was non blocking before (just a 10 seconds delay) but that now causes an exit and a reboot: Maybe these changes could be integrated in Ventoy as it all seems for the better?Īlternatively, maybe you could use them in a way that would prevent taking any risk for Ventoy itself, for example to create a separate and different EFI payload (say, Ventoz.efi?), that could be used by those who want to keep Ventoy features on their hard drive? I would like to suggest this as an alternative way that would 1) still perfectly support the current usecases while 2) also enabling Ventoy to be used as a standlone EFI payload and 3) also support better alignment for the Ventoy data partition, which is already desirable for large drives (ex: some Samsung drives should be aligned to 8k, not just 4k) and could be even more desirable in the future while 4) preventing uses from accidentally messing with the VTOYEFI partition by marking it as EFI, meaning extra permissions would be required to access it on Windows The 2 changes would be: 1) check for a special partition from 34 to 2047 and 2) check for a Ventoy.efi payload on the EFI partition, regardless of where this partition may be (thumb drive or hard drive) So what about making these checks implicit? But it still seems like a feature still desired by users: I did a quick analysis and concluded it's likely to be this way because you want Ventoy users to have a seamless experience and catch misconfigurations for them: having the first partition start at 2048 is a nice "canary in the mine": if it doesn't, it means it's likely there's no boot payload from 34 to 2047, which means the drive may not be bootable everywhere. However, using Ventoy.efi as an EFI payload on the EFI partition is not supported, even if it it worked before. Ventoy has quickly become one of my favorite tool to rescue systems, replacing the handcrafting of EFI payloads from say Ubuntu live images and Windows rescue thumbdrives. No response Image file download link (if applicable) No response Image file checksum (if applicable) I have tried the latest release, but the bug still exist.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |