frantisek holop wrote:
> hi there,
>
> this is for the dying breed of fdisk gurus...
> prepare some snacks, it's long.
>
> i am about to install openbsd -current (feb 28) on a notebook
> with a 320G hard drive in IDE mode, although it is AHCI really.
> bsd.rd dmesg at the end.
>
> my goal is to have the 2 ntfs partitions followed by a 32G
> openbsd one and then the last partition will be an ext2.
>
> i spent some quality reading time in the man page, and first
> of all let me confess, that i think that the i386 fdisk man
> page section sporting the title "TYPICAL LAYOUT" is more like
> a page out from the history books... i claim to be no fdisk
> jockey but i have seen a couple in my time, and i say, that
> even if we ignore the now exotic geometry (as most drives now
> identify always with an n/255/63 geometry), this particular MBR
I really don't want to ignore what you call an "exotic geometry".
A lot of people seem to think there is something "standard" about
what you are calling "n/255/63 geometry", but life ain't so
simple. Not at all. First of all, there are a lot of non-i386
and non-amd64 systems that use fdisk, and a lot of very usable
machines for OpenBSD are, as you put it, "from the history books".
Without looking very hard, I found these "exotics":
Disk: wd0 geometry: 787/128/63 [6346368 Sectors]
Compaq PII class system (i386)
Disk: wd0 geometry: 969021/16/63 [976773168 Sectors]
Thecus (armish)
Disk: wd0 geometry: 387621/16/63 [390721968 Sectors]
MacPPC
Disk: wd0 geometry: 1938037/16/63 [1953542144 Sectors]
Disk: wd1 geometry: 60801/255/63 [976773168 Sectors]
1.3GHz P4 (i386) (gotta love that one...two different
geometries on one machine!)
Disk: sd0 geometry: 43580/255/32 [355612800 Sectors]
Compaq GL380g2 (1.2GHz PIII) (i386)
I'm actually somewhat surprised how many exceptions I found
with very little effort. The only thing that surprised me
was the lack of my finding a "240 head" system, that's a
classic Compaqism, but apparently my firewall system has too
small a hard disk. :) I think the majority of the machines
I looked at (granted, guessing they would be "odd") were,
well...odd.
> violates the CAVEATS section of the man page on two counts:
>
> 1. the ending boundary of the 0th partition does not "end at
> cylinder boundaries."
> 2. the openbsd partition does not "start on a cylinder boundary
> (head 0, sector 1), except when starting on track 0,
> (these should begin at head 1, sector 1)."
>
> both these are cited as necessary for i386 machines...
no, key word is "SHOULD", it is very far from "necessary" on
most modern OSs.
IN FACT, if you move a disk from a n/240/63 machine and put it
on a n/255/63, things are most likely not going to end on nice
and neat cyl boundaries. Some OSs deal with it better than
others, OpenBSD rocks here, it doesn't care, most others will
complain more about the change in HW than the change in
geometry.
> as a quick refresher, here is the offending part:
>
> # fdisk wd0
> Disk: wd0 geometry: 5168/240/63 [78140160 Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
> #: id C H S - C H S [ start: size ]
>
> -------------------------------------------------------------------------
> 0: 04 0 1 1 - 170 0 63 [ 63: 2570462 ] DOS FAT-16
> 1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
> *3: A6 170 1 1 - 5167 239 63 [ 2570525: 75569697 ] OpenBSD
>
> i am _not_ stating, that this example is a made up fantasy,
> contrarywise, probably it has been copied from a live working
> operating system. i am merely pointing out, that it is far
> from "typical" and more confusing than helping, and i make no
> secret of that i'd like to see it being replaced with something
> fresher and/or more relevant (or "typical")... (the faq has both
> in section 4 and 14 newer layouts)
FAQ used to have a 240/63 system, but..uh..it was a very annoying
Compaq, and at one point, I finally decided it wasn't worth the
trouble anymore, so I replaced it with a Dell which had the less
interesting translation. Guess I need to look a little further. :)
I really, REALLY don't like people thinking that there's something
magic about 255 tracks per cylinder...or 63 sectors per track. Every
time you see someone say "first partition should be offset 63 sectors"
you should be thinking "WRONG!".
# fdisk sd0
Disk: sd0 geometry: 43580/255/32 [355612800 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
-------------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 1 1 - 43579 254 32 [ 32: 355612768 ] OpenBSD
> now on to my problems...
> here is the fdisk session during the install with my comments.
>
> Disk: wd0 geometry: 38913/255/63 [625142448 Sectors]
> Offset: 0 Signature: 0xAA55
> Starting Ending LBA Info:
> #: id C H S - C H S [ start: size ]
> -------------------------------------------------------------------------------
> *0: 07 0 1 1 - 8354 254 63 [ 63: 134223012 ]
> HPFS/QNX/AUX
> 1: 07 8355 0 1 - 25063 254 63 [ 134223075: 268430085 ]
> HPFS/QNX/AUX
> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> Enter 'help' for information
> fdisk: 1> e 2
> Starting Ending LBA Info:
> #: id C H S - C H S [ start: size ]
> -------------------------------------------------------------------------------
> 2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> Partition id ('0' to disable) [0 - FF]: [0] (? for help) a6
> Do you wish to edit in CHS mode? [n]
> offset: [0]
> size: [0]
> fdisk:*1> p
> Starting Ending LBA Info:
> #: id C H S - C H S [ start: size ]
> -------------------------------------------------------------------------------
> *0: 07 0 1 1 - 8354 254 63 [ 63: 134223012 ]
> HPFS/QNX/AUX
> 1: 07 8355 0 1 - 25063 254 63 [ 134223075: 268430085 ]
> HPFS/QNX/AUX
> 2: 00 0 0 1 - 267349 89 4 [ 0: 0 ] OpenBSD
>
> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> fdisk:*1>
>
> let's go line by line. i said i want to edit partition 2, and defined
> its type as a6, openbsd. then fdisk goes into lba editing mode and
> offers me offset 0.
well, you DID take the default for that. As mentioned in faq4.html,
when working around existing partitions, CHS mode is probably easier
than sector count mode.
> this is one of those moments where i dont know
> if this is fdisk's expected behaviour, or a bug. would it not make
> sense if it offered me the first available lba sector with partition
> type 0? i mean even if it doesnt want to offer any "responsible"
> value, 0 is wrong in any case on i386, as the first offset has to be
> at least 63...
"WRONG" :)
Come up with the algorithm for this. It's not easy. Go ahead, I'll
wait.
ok, now test your algorithm against this case:
Four partitions on a disk, laid out front to back as you would probably
assume:
0 10G
1 100G
2 20G
3 120G
Now, delete partitions 1 and 3.
Add a partition. What's its starting sector? What if I want to
add a 120G partition? How do you override it?
NOW...make it all fit on a floppy. I'm sure you just made fdisk
bigger, not smaller, so what drivers are you going to remove from
i386? alpha? amd64? to make it all fit again...
> i got curious and wanted to see where this leads, so i hit enter.
> fdisk then offered size 0, and again, i dont know if this is normal
> fdisk behaviour, but it would maybe make sense if it offered the last
> free lba sector (starting from offset) or up to the end of the disk,
> if that being the case. in any case, even if the offered size was
> 0, the result is obviously wrong, both the starting and ending C/H/S
> values are bogus, although the lba size value is correct.
you are confusing "If you hit enter, here's what I'm going to do"
defaults with "here's a good value" defaults. fdisk really does
very little to come up with "good value" defaults...and coming up
with GOOD ones is very difficult in general. Best you just tell
people to think it through.
Perhaps the answer would be "If you just hit enter, assume the user
wants to bail out of this process" rather than having an assumed
value. (that's thinking(?) out loud..not a considered, thought-
through idea).
> let's stop for a moment at the number in the prompt: 1. the man page
> says about the number in the prompt (0 being the particular example):
>
> 0 is the disk offset of the currently selected boot block being edited.
> This number could be something other than zero when extended MBR parti-
> tions are being edited (using the select subcommand).
>
> no matter how many times i read this, i dont get it. offset of what disk?
> and in my case it's "other than zero" but i am not working with extended
> MBR partitions at all.
yeah, that appears to be a manual bug. jmc@ and I are going to look
at cleaning that up. (one thing I have NOT worked with on OpenBSD's
fdisk much is extended partitions, other than fixing them when hosed
by other OSs)
Yes, that's a bit obtusely worded, but then, extended partitions are
kinda wacko.
Short version: an extended partition has its own partition table, and
if I remember right, each of those partitions can also be extended
partitions. Every extended partition has its own MBR. Easy to get
confused and lost in the web, lots of OSs try to deal with them in
various ways, but about the only ones that seem to do it clearly AND
don't limit your flexibility are the ones that just ignore extended
partitions...
> so next i did the same, but opted for CHS mode:
> BIOS Starting cylinder [0 - 38912]: [0] 25064
> BIOS Starting head [0 - 254]: [0]
> BIOS Starting sector [0 - 63]: [0] 1
did you type this manually? That should be [1 - 63], which is a
pet peeve of mine... "0" is not a valid default..in this case,
1 would be useful, but 0 is not even valid. Easy fix, shouldn't
enlarge fdisk much at all, I'd suspect.
I usually think of fixing it around the time I'm updating the FAQ,
and don't have time to look at it..then forget until next time.
"send diff" :)
> BIOS Ending cylinder [0 - 38912]: [267349] 38912
> BIOS Ending head [0 - 254]: [89] 254
> BIOS Ending sector [0 - 63]: [4] 63
> fdisk:*1> p
> Starting Ending LBA Info:
> #: id C H S - C H S [ start: size ]
> -------------------------------------------------------------------------------
> *0: 07 0 1 1 - 8354 254 63 [ 63: 134223012 ]
> HPFS/QNX/AUX
> 1: 07 8355 0 1 - 25063 254 63 [ 134223075: 268430085 ]
> HPFS/QNX/AUX
> 2: A6 25064 0 1 - 38912 254 63 [ 402653160: 222484185 ] OpenBSD
>
> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
> fdisk:*1>
>
> for the sake of simplicity i entered the whole remaining disk.
>
> here, i would like to point out, that again, according to the CAVEATS
> section in the man page, 0 as a default value makes no sense on i386
> for the BIOS starting sector of any partition. 1 does.
send diff. :)
> now let's suppose i wanted to change the size of the partition to 32G:
> fdisk:*1> e 2
> Starting Ending LBA Info:
> #: id C H S - C H S [ start: size ]
> -------------------------------------------------------------------------------
> 2: A6 25064 0 1 - 38912 254 63 [ 402653160: 222484185 ] OpenBSD
>
> Partition id ('0' to disable) [0 - FF]: [A6] (? for help)
> Do you wish to edit in CHS mode? [n]
> offset: [402653160]
> size: [222484185] 32G
> fdisk:*1> p m
> Starting Ending LBA Info:
> #: id C H S - C H S [ start: size ]
> -------------------------------------------------------------------------------
> *0: 07 0 1 1 - 8354 254 63 [ 63: 65539M ]
> HPFS/QNX/AUX
> 1: 07 8355 0 1 - 25063 254 63 [ 134223075: 131069M ]
> HPFS/QNX/AUX
> 2: A6 25064 0 1 - 29241 85 4 [ 402653160: 32768M ] OpenBSD
>
> 3: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
>
>
> please note the ending CHS for the openbsd partition. nothing
> good can come out of these values...
Really? I haven't seen an issue in a very, very long time, and
that was with OSs I think I'd prefer not to talk about anymore.
> why did not fdisk round
> up these values up to the nearest cylinder boundary?
"send diff"
yeah, If you can make a really small change to fdisk to get it
to round to nearest cylinder boundaries in THIS kind of use, I'm
all for it. But, needs to be over-ridable, as even though they
may not be recommended, they are valid.
> maybe i am expecting something from fdisk that is "not inside the
> openbsd philosophy", i don't know. now, faq 14 is quick to point
> out that:
>
> Unlike the fdisk-like programs on some other operating systems,
> OpenBSD's fdisk assumes you know what you want to do, and for the most
> part, it will let you do what you need to do, making it a powerful tool
> to have on hand. It will also let you do things you shouldn't or didn't
> intend to do, so it must be used with care.
>
> perhaps it is expected that the person doing the editing will enter
> the correct values at every prompt. but even if that is the case,
> i still think offering values way out of range is a bug and should
> be dealt with. but i believe fdisk can be made better (i'd dare say
> more openbsd like), it doesn't have to be "just" the raw byte editor
> of the first 512 bytes of the disk or a tool capable of giving
> intelligent, dependable results only if openbsd is used for the
> whole disk...
>
> any thoughts on these issues?
A very long time ago, I posted a somewhat similar rant to this same
list. I got a very polite private message from Toby, saying,
"Ok, I'm tired of these complaints, what would you do differently?"
and to be honest...I never came up with a good answer.
Undoubtedly, fdisk(8)ing and disklabel(8)ing your disk is the
hardest part of OpenBSD for a new user. It is made much more
complicated by the fact that many new users want to stick OpenBSD in
a corner of an otherwise really important machine, one slip of the
finger and they'll wish they had followed my advice in the FAQ about
not doing that. Plus, with modern disks, the sector counts exceed
the abilities of a standard eight digit calculator (I love using an
80 year old Comptometer or Monroe mechanical for disk calculations),
and some of us are a bit too brain-dead to use paper and pencil.
The first machine I tried to install OpenBSD on was a very old EISA
Compaq...with disk-based setup utilities which had to be loaded
from several floppy disks...and got reloaded several times before
I got it right (i.e., not clobbering the setup partition).
HOWEVER, there are very, very few OSs with an fdisk program that
lets you do ANYTHING the MBR is capable of doing. Most try to
hold your hand and keep you from hurting yourself or your data,
but in the process there are a lot of OSs that will screw up the
MBR in ways they can't undo (short of zeroing the disk...and not
all OSs can do that). OpenBSD's fdisk can fix 'em, and do just
about anything else that needs doing with an MBR. I've used it
a number of times to clean up other OSs messes (or at least look
at what they did).
There are some really wacko things one can do with OpenBSD's
fdisk, some can be called outright "wrong", but might be useful
in certain circumstances where "desperation" outweighs "sanity".
Could it be made better? Probably...but let me give you a set of
criteria that any patch will probably need to meet:
1) gotta fit on the floppy.
2) Still has to be able to do ANYTHING possible with MBRs, even if
wrong, immoral, or against certain political party's platforms.
3) Don't piss off the advanced users who have learned to LOVE the
power of the OpenBSD fdisk tool.
4) Don't look to Linux as a solution, the ones I've seen SUCK (see
#3 above).
5) Must work for all fdisk platforms
6) Must be the ONE tool. I don't think anyone will support two
fdisk-like tools in the tree. It has to be one tool that does
everything properly.
Yes, I do think some improvement can be made, definitely in the
man page (jmc@ and I will be working on that), but also in the
program, without violating the above (starting sector of 1 instead
of zero probably...better defaults for starting and ending track
and sector might be possible, but keep in mind the case of a drive
moved from a different geometry machine...)
Nick.
