[issue]: Provide opaque and stable identifier for partition with boot images #259

Open
opened 2025-10-14 18:13:41 -06:00 by navan · 0 comments
Owner

Originally created by @youk on 2/13/2025

Official FAQ

  • I have checked the official FAQ.

Ventoy Version

1.1.02

What about latest release

Yes. I have tried the latest release, but the bug still exist.

Try alternative boot mode

Yes. I have tried them, but the bug still exist.

BIOS Mode

UEFI Mode

Partition Style

GPT

Disk Capacity

64GB

Disk Manufacturer

No response

Image file checksum (if applicable)

None

No response

What happened?

New Linux Remount Feature makes partitions on USB device accessible via alternative locations (/dev/mapper/xxx). Unfortunately, it relies solely on partition names (i.e. /dev/sda1 will be accessible as /dev/mapper/sda1). Such a naming scheme is inflexible. As partition names in Linux are assigned dynamically, the name can be different depending on where USB device is plugged in. Compare this with having well-known and stable identifier. For example, on many modern Linux systems partitions are accessible under /dev/disk/by-label by their label. Should one have some automation script that reads from USB, it won't have to care about the partition name (which is unknown in advance).

VTOY_LINUX_REMOUNT worked transparently and one shouldn't know the partition name. Now that it doesn't work, one have to either manually remove devices mapped by Ventoy (i.e. dmsetup remove ventoy; dmsetup remove sda1) or use hardcoded partition name (/dev/mapper/sda1). Please consider providing a location which doesn't depend on the partition name (ideally, based on the partition label).

BTW, I don't find the name "Linux Remount Feature" especially good. It is confusing and doesn't reflect what is actually happening under the hood. It really should be something like "Partition Mapping/Remapping" or even "Partition Aliasing".

*Originally created by @youk on 2/13/2025* ### Official FAQ - [x] I have checked the official FAQ. ### Ventoy Version 1.1.02 ### What about latest release Yes. I have tried the latest release, but the bug still exist. ### Try alternative boot mode Yes. I have tried them, but the bug still exist. ### BIOS Mode UEFI Mode ### Partition Style GPT ### Disk Capacity 64GB ### Disk Manufacturer _No response_ ### Image file checksum (if applicable) None ### Image file download link (if applicable) _No response_ ### What happened? New [Linux Remount Feature](https://ventoy.net/en/doc_linux_remount.html) makes partitions on USB device accessible via alternative locations (`/dev/mapper/xxx`). Unfortunately, it relies solely on partition names (i.e. `/dev/sda1` will be accessible as `/dev/mapper/sda1`). Such a naming scheme is inflexible. As partition names in Linux are assigned dynamically, the name can be different depending on where USB device is plugged in. Compare this with having well-known and stable identifier. For example, on many modern Linux systems partitions are accessible under `/dev/disk/by-label` by their label. Should one have some automation script that reads from USB, it won't have to care about the partition name (which is unknown in advance). `VTOY_LINUX_REMOUNT` worked transparently and one shouldn't know the partition name. Now that it doesn't work, one have to either manually remove devices mapped by Ventoy (i.e. `dmsetup remove ventoy; dmsetup remove sda1`) or use hardcoded partition name (`/dev/mapper/sda1`). Please consider providing a location which doesn't depend on the partition name (ideally, based on the partition label). BTW, I don't find the name "Linux Remount Feature" especially good. It is confusing and doesn't reflect what is actually happening under the hood. It really should be something like "Partition Mapping/Remapping" or even "Partition Aliasing".
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: github/Ventoy#259
No description provided.