I created a Ventoy USB stick and it worked great.
![[Image: ap2BmAl.png]](https://i.imgur.com/ap2BmAl.png)
I wanted to replicate the setup on my pre-existing portable USB drive and am hitting a weird issue.
EFI/BOOT/bootx64.efi I copied to the EFI/BOOT/ folder
grub, tool and ventoy folders from the root of ESP I copied as well.
When I load bootx64.efi it ignores the grub.cfg and drops straight to grub console
![[Image: K6toLPs.png]](https://i.imgur.com/K6toLPs.png)
Then when I load the cfg manually, the screen resizes like I would expect from ventoy, but it doesn't render the UI correctly at all.
![[Image: mzJhTKE.png]](https://i.imgur.com/mzJhTKE.png)
It does this both in Virtualbox and real hardware.
Is there any way to get this working for a pre-existing EFI folder?
EFI + MS Reserved + Windows NTFS + Linux + Hybrid MBR Grub.
For the current testing I am just booting solely EFI
Code:
Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 937703088 sectors, 447.1 GiB
Model: PNY ELITE PSSD
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): DB510777-3A28-41BB-A25B-4BC1BC276E15
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 937703054
Partitions will be aligned on 2048-sector boundaries
Total free space is 3693 sectors (1.8 MiB)
Number Start (sector) End (sector) Size Code Name
1 2048 206847 100.0 MiB EF00 VTOYEFI
2 206848 239615 16.0 MiB 0C01 Microsoft reserved ...
3 239616 517144575 246.5 GiB 0700 Basic data partition
4 517144576 937699327 200.5 GiB 8300
5 937699328 937701375 1024.0 KiB EF02
![[Image: NPUETvI.png]](https://i.imgur.com/NPUETvI.png)
Necessary conditions for Ventoy to work:
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
At that point is that not just arbitrary?
What reason other than Windows reading the volume is there for the storage to be first? GRUB itself doesn't care. I never plan to access the storage on Windows. Why is the storage as first partition a forced requirement?
(09-23-2020, 06:36 PM)parkerlreed Wrote: [ -> ]... Why is the storage as first partition a forced requirement?
Could it be the developer's preference for how he sees it to benefit use?
If you built a car, might you build with how you wanted it to operate?
Just some thoughts that might help.
Ok so I reordered the partitions and it got far enough to actually show me the error message.
![[Image: znCVN7F.png]](https://i.imgur.com/znCVN7F.png)
Renumbered so the EFI is second and the EXT4 is first
fdisk output
Code:
Disk /dev/sda: 447.13 GiB, 480103981056 bytes, 937703088 sectors
Disk model: PNY ELITE PSSD
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: DB510777-3A28-41BB-A25B-4BC1BC276E15
Device Start End Sectors Size Type
/dev/sda1 517144576 937699327 420554752 200.5G Linux filesystem
/dev/sda2 2048 206847 204800 100M EFI System
/dev/sda3 206848 239615 32768 16M Microsoft reserved
/dev/sda4 239616 517144575 516904960 246.5G Microsoft basic data
/dev/sda5 937699328 937701375 2048 1M BIOS boot
This allowed Ventoy to show me the message. I assume this is what it was trying to tell me before but was corrupted.
![[Image: aal0j52.png]](https://i.imgur.com/aal0j52.png)
The EXT4 partition appears to be > 2048 on the cluster size. I guess in the end, does Ventoy need the partitions physically arranged storage before EFI or should the partition numbering work?
Code:
tune2fs 1.45.6 (20-Mar-2020)
Filesystem volume name: <none>
Last mounted on: /run/media/parker/99612787-a9d4-4b07-a776-e40c4ffeb058
Filesystem UUID: 99612787-a9d4-4b07-a776-e40c4ffeb058
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr resize_inode dir_index filetype extent flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 13148160
Block count: 52569344
Reserved block count: 2628466
Free blocks: 48198415
Free inodes: 12970763
First block: 0
Block size: 4096
Fragment size: 4096
Reserved GDT blocks: 1011
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 8192
Inode blocks per group: 512
RAID stripe width: 8191
Flex block group size: 16
Filesystem created: Sun Sep 20 02:54:56 2020
Last mount time: Tue Sep 22 20:22:04 2020
Last write time: Tue Sep 22 20:23:53 2020
Mount count: 10
Maximum mount count: -1
Last checked: Mon Sep 21 18:01:54 2020
Check interval: 0 (<none>)
Lifetime writes: 18 GB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 32
Desired extra isize: 32
Journal inode: 8
Default directory hash: half_md4
Directory Hash Seed: bf44b27a-a1e0-468a-afe6-4c6ea0708d19
Journal backup: inode blocks
Checksum type: crc32c
Checksum: 0xd8e268b8
I see this error is thrown because the storage partition does not start at 2048. So the number doesn't mean shit.
https://github.com/ventoy/Ventoy/blob/9e...oy.c#L1533
Please consider not hardcoding partition assumptions. I wanted to use Ventoy to compliment my already existing disk but I cannot without completely recreating from scratch.