On 9 February 2014 16:58, d...@genunix.com <d...@genunix.com> wrote: > warning: really long post with some questions and thinking. > > Hello dear OpenBSD types. > > I have been using UNIX in various forms and flavours for a long time now > and could even go so far as to say a "very" long time. Therefore it just > seems so very familiar to me and yet, a bit new. > > First thing I see is that it was so very easy to install. I was almost > expecting to need to curse and recurse but the install was trivial. I > kept a log of the whole process in case something went wrong but nope, > it is just a nice simple log.
Perhaps you can share this log. At least give us a clue what machine you are installing on. > > However upon first boot I see that my disk slices are a bit odd in terms > of size. I would have liked to arrange things differently. Certainly I > will need to create a mount point for a /opt filesystem and that means I > need to read fdisk and disklabel man pages over and over. > > The questions on my mind, in order of importance seem to be : > > 1) how do I do a full low level backup and then verify that I > can restore the system ? To an NFS mount or tape or whatever. Why? If you just installed, I would simply install again rather than trying to preserve the installed bits. > > 2) how do I edit the disk slices or "partitions" to be what I want? disklabel(8) is the normal tool to edit disklabels. fdisk(8) the tool to edit MBRs. Both are on offer during install. Although fdisk(8) will only be offered on MBR reliant architectures like i386 and amd64. > > 3) how do I eventually contribute software packages or similar? Read the documentation, especially ports(7), create a port, don the obligatory asbestoes undergarments and send it to po...@openbsd.org. > > So number (1) would seem to need a dump command and I see a lot of very > friendly and familiar looking goodness in dump(8). The disk low level > bits seem to use 512 byte blocks and so I am going to guess that I can > do a level 0 dump of each filesystem one at a time to some NFS mounted > location and that would suffice for the filesystem level. Not too sure > how to deal with the partition table and boot records etc. I see from > the fdisk command this : > > # fdisk -e sd0 > Enter 'help' for information > fdisk: 1> print > Disk: sd0 geometry: 7508/19/248 [35378533 Sectors] > Offset: 0 Signature: 0xD6BC > Starting Ending LBA Info: > #: id C H S - C H S [ start: size ] > ------------------------------------------------------------------------------- > 0: 55 64103 7 97 - 64111 12 157 [ 302055168: 38997 ] EZ-Drive > 1: D5 103269 3 18 - 103270 17 37 [ 486604289: 8204 ] <Unknown > ID> > 2: 92 153115 15 134 - 153118 17 75 [ 721481733: 14574 ] <Unknown > ID> > 3: 86 338260 4 10 - 106301 12 65 [ 1593882121: 3201978528 ] NT FAT VS > fdisk: 1> exit So this MBR is complete garbage. First clue: signature 0xD6BC. This is not an MBR, and most certainly not one created by an OpenBSD install. > > Looks like there is some black magix at work in partition id 0 through > 2 and then one big fat large chunk at id 3 wherein my OpenBSD 5.4 install > must live. I am not too sure how to dump or backup the partition table > info such that a totally blank disk could be inserted and then a restore > done. Perhaps my whole thinking appoach here is old school wrong? > > Whatever the case the disklabel tool shows me this : > > # disklabel sd0 > # /dev/rsd0c: > type: SCSI > disk: SCSI disk > label: ST318404LSUN18G > duid: c5cd4c19ed688052 > flags: vendor > bytes/sector: 512 > sectors/track: 248 > tracks/cylinder: 19 > sectors/cylinder: 4712 > cylinders: 7508 > total sectors: 35378533 > boundstart: 0 > boundend: 35378533 > drivedata: 0 > > 16 partitions: > # size offset fstype [fsize bsize cpg] > a: 1201560 0 4.2BSD 2048 16384 1 # / > b: 1201560 1201560 swap # none > c: 35378533 0 unused > d: 1903648 2403120 4.2BSD 2048 16384 1 # /tmp > e: 2855472 4306768 4.2BSD 2048 16384 1 # /var > f: 2879032 7162240 4.2BSD 2048 16384 1 # /usr > g: 1672760 10041272 4.2BSD 2048 16384 1 # /usr/X11R6 > h: 6266960 11714032 4.2BSD 2048 16384 1 # /usr/local > i: 2511496 17980992 4.2BSD 2048 16384 1 # /usr/src > j: 3491592 20492488 4.2BSD 2048 16384 1 # /usr/obj > k: 11393616 23984080 4.2BSD 2048 16384 1 # /home > # In the complete absence of a valid MBR disklabel(8) simply assumed you were using the entire disk and wrote a disklabel at block 0. Or perhaps 1 depending on the architecture you are installing on. Clue here is that partition 'a' starts at offset 0., i.e. the first block of the disk. > > So that tells me I have 35378533 blocks ( at 512 bytes each ) stuffed in > the big magic partition id 3 and that sd0:c ( correct notation? ) is > what we old Solaris/SunOS types would call the overlap slice. Seems to > make sense by the numbers : There is no MBR magic partition. There is no MBR. :-). Partition 'c' *is* sort of magical in that is always reflects the entire disk, even when there is an MBR present that defines a smaller area as the OpenBSD portion. In this case 'boundstart' and 'boundend' would reflect the limits of the OpenBSD portion until/unless you manually change them. > > # bc > 35378533 * 512 > 18113808896 > > Yep, that is an old 18G disk there. However the word "partition" has me > wondering if I am looking at a "partition" table or a disk label. Not > entirely clear .. yet. The disklabel(5) man page sheds a bit of light > and the three disklabel.h headers shed even more : > > # ls -l /usr/include/dev/sun/disklabel.h /usr/include/sparc64/disklabel.h \ >> /usr/include/sys/disklabel.h > -r--r--r-- 1 root bin 4706 Apr 25 2010 /usr/include/dev/sun/disklabel.h > -r--r--r-- 1 root bin 2016 Jun 20 2007 /usr/include/sparc64/disklabel.h > -r--r--r-- 1 root bin 15300 Jun 11 2013 /usr/include/sys/disklabel.h > # I am beginning to suspect you are on a sparc64 box. In this case, there is no MBR, should be no MBR, and you will only be confused by looking at or for an MBR. > > So really I don't see where the data from fdisk lives and I am getting > mixed up between "MBR partition table" data and the disklabel. At the > very least I don't yet see where those id numbers 55, D5, 92 and 86 come > from. Certainly when fdisk(8) says : > > id MBR partition type identifier. OpenBSD reserves the magic > number hexadecimal A6 (166 decimal). > > Well I don't have an 0xa6h anywhere. I have 0x86h which seems to be one > bit away from 0xa6h == 1010 0110b. So maybe the bit 5 has some special > value here. Not sure. Anyways, I don't know where the MBR boot record > data lives but I am guessing sector 0 on track/cylinder zero of the disk. An MBR, if one did exist, would be on the first block of the disk. > > The real problem on my mind is how to take /dev/sd0k and break it up a > bit. I didn't want a 5.3GB /home : Then you must choose '(c)ustom' when presented with the default disklabel and configure your space as you like. > > # df -h > Filesystem Size Used Avail Capacity Mounted on > /dev/sd0a 575M 116M 431M 21% / > /dev/sd0k 5.3G 40.0K 5.1G 0% /home > /dev/sd0d 914M 8.0K 868M 0% /tmp > /dev/sd0f 1.4G 420M 895M 32% /usr > /dev/sd0g 801M 139M 622M 18% /usr/X11R6 > /dev/sd0h 2.9G 104M 2.7G 4% /usr/local > /dev/sd0j 1.6G 2.0K 1.6G 0% /usr/obj > /dev/sd0i 1.2G 2.0K 1.1G 0% /usr/src > /dev/sd0e 1.3G 9.3M 1.3G 1% /var > thor-int:/export/boot 35.4G 15.4G 20.0G 43% /mnt/thor > > There seems to be plenty of room left over for a "partition" or "slice" > or thingy which allows /home to be 1GB and then a /opt created with 4GB > or so at /dev/sd0l ( the letter ell ). > > So is there a webpage somewhere that may explain some of the inner bits > I am seeing? The page at http://www.openbsd.org/faq/faq14.html seems a > bit glossy on the topic of how to wrangle these label bits. > > Dennis > > ps: as for dump and backup .. I can figure that out but really how to > sort out the disk MBR record and partition table and slice or label > bits seems more important first. > .... Ken
