Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
memtest86-efi: compute ESP offset from partitions #86623
Motivation for this change
Hopefully the derivation is less obscure / better documented now.
cdepillabout left a comment
@emilazy Thanks for sending a PR updating this.
I think this is looking really good. It is easy to understand what is going on here, and I feel comfortable keeping this updated in the future.
I have two small concerns, but I don't think they are big enough to prevent this from being merged in.
Like I said in #86470 (comment), it looks like we are still potentially passing both partitions to
My second small concern is that it appears the output format of
Specifying the location of partitions is the intended use of the offset functionality (see e.g. the mtools manual), and in general is just how partitions and filesystems work. Filesystems generally encode their own extent, and there's no "dynamically-sized reads/writes" that would go outside their limits, so unless the image was maliciously constructed as invalid an FAT filesystem that points to sectors outside of the partition, there's no way mtools would even be aware of the rest of the image; that's presumably why it only takes an offset value to begin with, not an offset and a size. If the risk you were worrying about was real, then something like growing a partition would be much more risky and difficult, rather than the routine operation it is.
I don't claim that any of this is particularly obvious, but I think the fact that mtools accepts this syntax in the first place is suggestive of the fact that it's how things are meant to work, and I don't think a diversion about how partition tables and filesystem headers work would really be appropriate for this derivation.
I guess the JSON API is probably pretty new; it was the least kludgy way I could find to parse GPT from userspace programmatically. If anyone knows a better alternative I'd be happy to use that instead.
Hmm, I've discovered something interesting.
If I go back to before #86470, the files output are slightly different:
$ cd /some/path/to/nixpkgs/ $ git checkout b7f80f00eff # an older commit from before https://github.com/NixOS/nixpkgs/pull/86470 was merged in $ nix-build -A memtest86-efi $ ls result/ Benchmark blacklist.cfg BOOTIA32.efi BOOTX64.efi mt86.png unifont.bin $ git checkout 15172cf # the commit from this PR $ nix-build -A memtest86-efi $ ls result/ blacklist.cfg BOOTIA32.efi BOOTX64.efi mt86.png unifont.bin
After playing around with this for a while, I figured out that passing the
I don't think this