On Thu, Dec 23, 2021 at 12:08:49PM -0500, Rob Whitlock wrote: > On Thu, Dec 23, 2021 at 1:15 AM Theo de Raadt <dera...@openbsd.org> wrote: > > > > Crystal Kolipe <kolip...@exoticsilicon.com> wrote: > > > > > On Tue, Dec 21, 2021 at 06:04:28PM -0500, Rob Whitlock wrote: > > > > A problem seems to be that there is no disklabel entry for the ExFAT > > > > partition. > > > > > > You probably wrote a BSD disklabel to the disk before creating the > ExFAT partition. > > > > > > If there is no on-disk disklabel, the kernel will create one in memory > based on information from other partitioning schemes, (MBR, GPT). So in > this case, as you change those MBR or GPT partitions, those changes will be > reflected in the disklabel that the kernel sees. > > > > > > Once you actually write a disklabel to the disk, that on-disk disklabel > is then used in place of calculating one each time the disk is attached, > and the automatic parsing of MBR and GPT partition information stops. > > > > > > To solve your problem, you need to add the details of the ExFAT > partition to the BSD disklabel. You can either do that manually with the > disklabel command, or since you do not have any OpenBSD partitions on the > disk, you could overwrite the on-disk disklabel, allow the kernel to > generate one automatically with the correct information, then optionally > force it to be written to the disk by running disklabel and entering 'w' at > the interactive prompt. > > > > This can be investigated with > > > > disklabel -d > > > > (BTW, when the disklabel is constructed from other information on the > disk, > > we call it a "spoofed label") > > I would like to avoid modifying the data on the disk. Is there a way to use > disklabel to update the in-core copy of the disklabel with a spoofed label, > without also writing it to disk? I see in the disklabel(5) manual page that > the DIOCSDINFO ioctl updates the in-core copy, so it seems it should be > technically possible, but I don't see how to do it with the disklabel(8) > program. My understanding of disklabel -d is that it gives you a default > disklabel to start with, but does not affect how or where the disklabel is > written.
The output from 'disklabel -d' will simply show us the spoofed label regardless of whether there is a real disklabel already written to the disk or not, (which I now suspect that there is not, having noticed that your duid is 0000000000000000). If the spoofed label includes your non-OpenBSD partitions, then presumably the disk already has a real label written to it which does not include them. If the spoofed label does not include your non-OpenBSD partitions, then for some reason the kernel is not parsing the data from the GPT, and we will presumably need a hexdump of the GPT to see why.
