Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feedback regarding the use of filesystem UUIDs #1

Open
pbatard opened this issue Sep 28, 2024 · 0 comments
Open

Feedback regarding the use of filesystem UUIDs #1

pbatard opened this issue Sep 28, 2024 · 0 comments

Comments

@pbatard
Copy link

pbatard commented Sep 28, 2024

Since this project is asking for feedback, I am going to comment on the following from the liveid readme:

When you install a distribution into an internal hard disk you usually use filesystem UUIDs for detecting that particular installation. That's the way it should be done also in live cds/usbs.

I'm afraid I have to dispute that statement. Using the filesystem UUIDs themselves is not how it should be done for live cds/usbs.

To understand why this is a bad idea, one needs to go back to the promise of UEFI, which is to do away with the need to write bootloaders (and the whole boot paraphernalia) at the block level (MBR, SBR and so on), as this a major drawback of BIOS, to instead write bootloaders at the file system level, thereby aiming at letting users create boot media by simply copying content, onto a properly formatted media, using a simple file copy command. Because this operation consists of transposing boot media content from one file system to another, this is also called File System Transposition or FST for short, and, IMO, it is one of the most desirable goals of UEFI boot media, as it allows users, especially ones running Windows as their main OS, to create boot media from ISOs, without using any third party utilities (since Windows does not come with dd so ISOHybrid is not actually that great a solution there, and it also comes with a handful of other drawbacks).

What this implies however is that you should NOT rely on looking for the actual filesystem UUID to locate your boot media, because that unique UUID may have changed during File System Transposition, as you need to consider that the whole underlying file system may have changed.

This is why the initial approach of looking for media that contains /.disk/info was actually very desirable for FST (because, as long as you don't have multiple boot media which is the most common scenario for people install or running a live Linux, FST "just works"), and any new approach should make sure that it won't introduce a regression for FST. For instance, instead of trying to tie media discovery to IDs that may get altered after the content has been copied over to a new file system, it should be looking for UUID content that does get transposed through file copy, such as a file containing a UUID that is not dependent on the original file system.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant