dmitry.sensei writes: > Why offset in disklabel for a partition is different from fdisk output? > 423202816 and 433358194
Something wrote the MBR and/or disklabel incorrectly. Probably a repartitioning or other data shuffling process gone wrong. > When I add label for partition 3 as in fdisk output i get overlapping error. Slight aside but let's get this out of the way: Unfortunately the terminology is confusing and contradictory between the unixes and BSDs. fdisk arbitrarily divides the disc into up to 4[*] partitions. There is no technical reason why they should by disjoint but that way lies madness. FreeBSD calls these slices. A partition of type 0xA6 is OpenBSD and if it contains a disklabel that is parsed for *its* definition of partitions. These are a different type of partition from the MBR's. OpenBSD does a reasonably good job of blurring the distinction during use which helps until the distinction matters, as now. On the whole non-unix OSs, including linux, do not have an equivalent of these (</GPT+EFI-rant>). There is also no technical reason why the disklabel partitions should be disjoint or why they should be within the *guidelines* laid out by the MBR-partitions, although that way lies further madness. The OpenBSD-partitions described by the disklabel are *not* relative to the MBR-partition which has type 0xA6 but to the *whole disc*. That's why label c starts at offset 0 and a starts at, usually, 64 or 2048. It needs to skip the MBR and other administrivia. Note that that has nothing to do with why fdisk's reported size and disklabel c's are different. The answer is don't think about it. MBR-partition types other than 0xA6 are, by the kernel at run-time, assigned effective disklabel-partitions starting at i (that is one MSDOS MBR-partition becomes i; I've no empirical experience with discs containing more or what happens if i is already allocated but I can make an educated guess...). > fdisk > 0: EFI Sys [ 2048: 1126400 ] > 3: FAT12 [ 211014485: 222343709 ] > 4: OpenBSD [ 433358194: 566856989 ] > disklabel > a: 553568256 423202816 RAID > c: 1000215216 0 unused > i: 1126400 2048 MSDOS Depending on where exactly the disklabel is stored you may be unable to get away with adjusting MBR-partition 4's offset. If the kernel and bootloader find the disklabel based on the offset of the MBR-partition, which they almost certainly do, you're stuck with this misconfiguration until you can reformat, although they could look to the end of the allocated block. Luckily though OpenBSD doesn't actually care what the MBR-partition says when processing the disklabel, as you've noticed, so if you can't adjust MBR-partition 4 you can simply create MBR-partition 3 small enough that there's no overlap and pretend like nothing happened. How this came about is anyone's guess although OpenBSD's disc layout tools will definitely not have done this during a regular installation; luckily it doesn't actually matter though, it's just untidy. The net effect is simply that OpenBSD has been writing to disc blocks prior to the 'official' beginning of its MBR-partition. Writing to MBR-partition 3 will eventually also write to those same blocks if they are within its allocated area. Also are you sure you want to use type FAT12 and not FAT32? It also makes no practical difference (that I know of) but it's sloppy. Matthew [*] GPT is basically the same as MBR in its effect but unnecessarily bigger and more complicated and the differences are irrelevant here.
