Thanks everyone for clarifying that the sectors 0 to 79 should be considered reserved on OpenBSD MBR partitions (and thus within the context of the "disklabel" tool).
There is just one thing I don't understand now, and that is what dysfunction-potential there is in inappropriate handling of sectors 64 to 79. I'll specify my Q below - so what do you say? Last, I agree that the concept of "binary blob partitions" is slightly archaic, but not by any standards obsolete. Probably the most common blob-level use of partitions you do would be "dd"-based backuping - and we learned here now, that restoring such a partition backup could trash the disklabel if it started at less than offset = 512 * 8 ! Thanks *Impression:* Based on what Benny and I think someone else said, I got an approximative impression something like that the whole disklabelling system is actually designed with the intention that every disklabel is required to 1) Have an "a" partition that 2) Starts on sector 64 and continues at least up to and including sector 79 and 2) Be of the 4.2BSD or RAID type, Because otherwise something bad happens. *Example, for clarity:* I mean, if on an 9999999-sector disk where I want to put an 99999-sector binary blob in its own partition, and then give all the remaining space to a "main" UFS-partition, if it wasn't for this conversation I'd just have gone into the "disklabel" tool, wipe the disklabel and then first have added my blob partition at the beginning of the disk and then the "main" partition after it (i.e. blob partition would be sectors 64 to 100063 and the UFS partition would be sectors 100064 to 9999998). This conversation shows that the binary blob partition should be put at sectors >= 80 (i.e. sector 80 to 100078 would have worked for it, so then the UFS partition at sectors 100079 to 9999998), BUT, Because of what possible dysfunction is it that I should put the UFS partition in the beginning and the binary blob partition after it (i.e. UFS partition on sector 64 to 9899991, and blob partition on sector 9900000 to 9999998)? 2015-10-07 2:48 GMT+08:00 Benny Lofgren <bl-li...@lofgren.biz>: ... > If you place a 4.2BSD or a RAID partition from the first sector (64) of > the BSD usable part of the disk (as limited by the "boundstart" and > "boundend" disklabel parameters) you will never get in trouble. Anything > else and you need to know more about the system internals to be safe. > > You ask about saved butts. Just a couple of example scenarios: > > Consider the option to encasing the partition metadata in the first > partition (and again, first physical address-wise, not first partition > letter-wise), which is to leave a gap in the beginning: First of all, > I'm not even sure the boot code is able to cope with that scenario, but > let's say it is. Whenever you want to add a new partition, disklabel > will suggest you populate the first free area on your disk - guess where > that is going to be... > > If you wreck your disklabel and have done something non-standard, such > as move the first partition from its expected position, you're pretty > much in the dark when it comes to actually *find*, not to mention > hopefully recover, your partitions. > > It is well known and understood since decades what's on these first > sectors of a) a disk, b) of the BSD usable area and c) of each partition > (type). Why are you having trouble accepting that things are the way > they are and that they WORK as they are, if you don't turn everything on > its head? Well, at least they work until you start messing with things > you have not yet had any experience with. The upside is you'll quickly > gain useful experience, of how not to do. :-)
