Re: What is the relationship between fdisk and disklabel?
Your disk layout is strange, an EFI partition is typically initialised by a GPT disk, not MBR. GPT has a number of advantages including no differentiation between primary and extended partitions, and beating the 2TB limit of MBR. When created, GPT also creates a 'protective MBR' covering the whole disk, so that older tools that only understand MBR don't break things. You can, if you know what you're doing, manipulate this protective MBR but you shouldn't - it will have odd effects and different operating systems will interpret it in different ways (Linux will be a bit upset). In short : either use all GPT partitioning tools to edit your disk, or wipe it clean and restart with MBR. Matthew is absolutely right about MBR otherwise. Generally MBR partitions and a disklabel have a direct mapping, but you can for instance, ignore the partition scheme. Imagine you have an old system that only boots partitions below 128GB or less but you want to use over that amount for OpenBSD? A solution is to create two partitions, one up to 128GB and the second over. Then adjust the disklabel to cover the two partitions, but make sure that the root section of the disklabel is entirely contained in the first MBR partition. MBR is also a pain, because not everything understands extended partitions/logical drives, notably FreeBSD. If you are doing multiboot (I set up an epic two Windows, three BSD, and Linux multiboot config last night for bare metal testing on a virtualised system) I'd recommend the following : Generally partition using Windows. It works well, most of the tools are graphical, and it can install in GPT, and both primary and extended MBR partitions. Modify partition IDs using OpenBSD, it's really good for that. FreeBSD does not like extended partitions. What I need to look up is why disklabels stop at 'p', as it's an issue on disks with lots of non OpenBSD partitions. PK
Re: What is the relationship between fdisk and disklabel?
Thanks. I used partition cloning software recently. I'll fix it 😁 вт, 29 окт. 2019 г., 14:10 Peter Kay : > Your disk layout is strange, an EFI partition is typically initialised by > a GPT disk, not MBR. > > > GPT has a number of advantages including no differentiation between > primary and extended partitions, and beating the 2TB limit of MBR. > > > When created, GPT also creates a 'protective MBR' covering the whole disk, > so that older tools that only understand MBR don't break things. You can, > if you know what you're doing, manipulate this protective MBR but you > shouldn't - it will have odd effects and different operating systems will > interpret it in different ways (Linux will be a bit upset). > > > In short : either use all GPT partitioning tools to edit your disk, or > wipe it clean and restart with MBR. > > > Matthew is absolutely right about MBR otherwise. Generally MBR partitions > and a disklabel have a direct mapping, but you can for instance, ignore the > partition scheme. Imagine you have an old system that only boots partitions > below 128GB or less but you want to use over that amount for OpenBSD? A > solution is to create two partitions, one up to 128GB and the second over. > Then adjust the disklabel to cover the two partitions, but make sure that > the root section of the disklabel is entirely contained in the first MBR > partition. > > > MBR is also a pain, because not everything understands extended > partitions/logical drives, notably FreeBSD. > > > If you are doing multiboot (I set up an epic two Windows, three BSD, and > Linux multiboot config last night for bare metal testing on a virtualised > system) I'd recommend the following : > > > Generally partition using Windows. It works well, most of the tools are > graphical, and it can install in GPT, and both primary and extended MBR > partitions. > Modify partition IDs using OpenBSD, it's really good for that. > FreeBSD does not like extended partitions. > > > What I need to look up is why disklabels stop at 'p', as it's an issue on > disks with lots of non OpenBSD partitions. > > > PK
Re: What is the relationship between fdisk and disklabel?
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 (). 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:553568256423202816RAID > c: 10002152160 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.
What is the relationship between fdisk and disklabel?
Hi!. In my opinion disklabel and fdisk whow very different information. Why offset in disklabel for a partition is different from fdisk output? 423202816 and 433358194 When I add label for partition 3 as in fdisk output i get overlapping error. disklabel # /dev/rsd0c: total sectors: 1000215216 boundstart: 433358194 boundend: 1000215183 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a:553568256423202816RAID c: 10002152160 unused i: 1126400 2048 MSDOS fdisk Disk: sd0 Usable LBA: 34 to 1000215182 [1000215216 Sectors] #: type [ start: size ] 0: EFI Sys [2048: 1126400 ] 3: FAT12[ 211014485:222343709 ] 4: OpenBSD [ 433358194:566856989 ] -- Dmitry Orlov
