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
Last partition created by fdisk overlaps with GPT secondary header? #2862
Comments
Try to use Update: My reading errors are caused by Linux RAID detection from |
Please try |
Sorry for the delay. I was trying to troubleshoot this a bit more myself.
So, basically, my question: is it a problem that the partition ends 23 sectors (4K sectors) before the end of the disk? Now, about the hardware encryption and the troubles that triggered me opening this. I probably was wrong about the reason for the errors. I found that the partition "probing" process in the kernel and by "partprobe" tool appears to be different. But they all seem to have one thing in common: they read not only the partition table, but also the beginnings (at lest) of each partition. At least this is what I observed with strace over partprobe. I found that partprobe was trying, for some unknown reason, to read the LAST sector of the partition protected by OPAL. Of course, this results in I/O errors. So far I have concluded that, at some point, the alignment to 1Mb happens. Only if I create the encrypted partition where the end of it is aligned to 1Mb mark, I do not get these errors. Anyway, this seems like a separate issue to be reported against cryptsetup. For this issue, I will stick to my original question about "LBA-33" as per Wikipedia. Thanks! |
Hi,
Sorry for probably completely silly question, I am not familiar enough with GPT structure. I will share my observations.
I am using new feature of cryptsetup to configure hardware encryption (OPAL) on an NVME disk. I have noticed that when the range is locked, the kernel complains about errors reading some sectors. This happens in minimal install environment and even at boot time. My conclusion so far that this happens when the kernel reads the partition table (GPT). The disk is partitioned with fdisk, where for the end of the last partition I used the default value - to use the rest of the disk. Here is the current partition table:
With OPAL, I have the area of 487784448 sectors starting from the sector 594176 (partition start + 16Mb of LUKS2 header) locked by the drive.
This makes the range of 594176 to 488378624 locked by OPAL.
Then when the system boots and the sector range is not yet unlocked, I observe the following kernel errors:
As you can see, the kernel is reading the sectors (488378613, 488378614) that fall into the locked range. But they also fall into the partition's own range (590080 to 488378623). 488,378,613 < 488,378,623.
So, these are symptoms. Now I look at the bigger picture.
When I look at https://en.wikipedia.org/wiki/GUID_Partition_Table, I see that GPT uses a "secondary header" located starting from LBA-33 and down. Well, according to my parition table, 488378646-33=488378613). This seems to match exactly the place where the kernel hits the problem.
So, my question. Is it correct for fdisk to allow creation of the partition that appears to overlap with that bottom part of the LBA range?
Thanks!
The text was updated successfully, but these errors were encountered: