09-23-2020, 07:41 PM
(This post was last modified: 09-23-2020, 07:52 PM by parkerlreed.)
Ok so I reordered the partitions and it got far enough to actually show me the error message.
Renumbered so the EFI is second and the EXT4 is first
fdisk output
This allowed Ventoy to show me the message. I assume this is what it was trying to tell me before but was corrupted.
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?
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.
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.
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.