Date: 14 Jan 2003 11:01:36 -0800 From: swear@attbi.com (Gary W. Swearingen) To: Mike Meyer <mwm@mired.org> Cc: freebsd-questions@freebsd.org Subject: Re: Dangerously dedicated vs. fully dedicated, etc. Message-ID: <vvsmvvv9m7.mvv@localhost.localdomain> In-Reply-To: <15907.64491.399256.923879@guru.mired.org> References: <r0ptr0d0f9.tr0@localhost.localdomain> <15907.64491.399256.923879@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Mike, I'll pay back your effort in replying to this long thing by working up a patch for the "disklabel" manpage (at least) and, if you want, I'll CC you so you can veto things you don't like. I do worry about how so few people comment on manpage changes before they go in, but they need improvement so badly it's worth the risk of a few errors. If you can't reply or even read it, that's OK too; I think I learned something in the writing of it. Mike Meyer <mwm@mired.org> writes: > In <r0ptr0d0f9.tr0@localhost.localdomain>, Gary W. Swearingen <swear@attbi.com> typed: > > I'm having trouble understanding a couple parts of the "disklabel" > > manpage related to dangerously/fully dedicated disks. > > > > The "BUGS" section has this paragraph: > > > > For the i386 architecture, the primary bootstrap sector contains an > > embedded fdisk table. The disklabel utility takes care to not > > clobber it when installing a bootstrap only (-B), or when editing an > > existing label (-e), but it unconditionally writes the primary > > bootstrap program onto the disk for -w or -R, thus replacing the > > fdisk table by the dummy one in the bootstrap program. This is only > > of concern if the disk is fully dedicated, so that the BSD disklabel > > starts at absolute block 0 on the disk. > > > > 1) Can anyone explain that last sentence to me? Shouldn't that "is only > > of concern" instead be "is not of concern", reversing the sense? > > No, it's right. But you say that a fully dedicated disk has a standard disklabel. So the fdisk table is the dummy one, by definition of "standard". So why would replacing it with another dummy one concern me (as the quote says it should)? I now suspect that "fully" means "dedicated", and I should be concerned that it's fake fdisk table not get overwritten (but I don't see why it even needs a fake table -- more below). And if I have normally sliced disk, whouldn't I also be concerned if "disklabel" was going to "replace the fdisk table" when it "writes the primary bootstrap program"? That depends on definitions. I was confused by FreeBSD referring to boot1 as the "primary bootstrap" while it seems so obvious that boot0 (MBR) is the primary bootstrap. The about manpage quote seemed to imply that the MBR's "fdisk table" could be overwritten; made even more wrong because there is no other fdisk table, really. The boot1 dummy table is not an "fdisk table" because fdisk knows nothing about it on a sliced disk. I think "only of concern if" should be "only true if". I think there's a terminology mess here. Looking further, I see that my filesystem has a block size of 16384, but disklabel.c seems to use a "boot block" size of 8192 (presumably to fit in /boot/boot1 (512) and /boot/boot2 (7680, part of which is a placeholder for the disklabel sector); which the code refers to as "block 0" and "block 1-15"! > > 2) Is a "fully dedicated" disk exactly the same as a "dangerously > > dedicated" disk? If not, what's the difference? Can one use a disk > > (or a slice) which has no space reserved for stage 1 & 2 boot records, > > say, for a non-bootable disk? I know no way to disklabel one that way. > > I've never seen "fully dedicated" anywhere else, so I can't say for > sure. However, I suspect they are using that to distinguish a drive on > a non-PC system - which has a standard disklabel in block 0 - from a > dangerously dedicated drive, which has a dangerously dedicated > disklabel in block 0. So then what's the difference between "a standard disklabel" and "a dangerously dedicated disklabel"? Is it only that the std one has a dummy partition table and the DD one has a "fake" table, where "dummy" means "whatever is in boot1 (some warning text?)" and "fake" means "some data as if the disk was sliced"? (More below.) > > 3) Is "block 0" exactly the same as "sector 0"? > > No. Block 0 is a file system block, whose size depends on the > parameters you gave newfs when you created the file system. I've seen > reports that booting won't work if you don't use the default values on > the root file system, but have never verified them. Sector 0 is the > first sector of block 0. It looked to me like disklabel.c is using 8192, regardless of FS params. I don't know why my root FS has 16384 since it's less than 1 GB so it's supposed to be 8192. But it boots. > > 4) Shouldn't "BSD disklabel starts at absolute block 0" be "FreeBSD > > stage 1 boot record starts at sector 0"? The disklabel immediately > > follows the stage 1 boot record, right? So it would be "block 1"? > > No, both the stage 1 boot and the disklabel are in block 0. OK, I guess the "block 0" is true (but confusing), but I like your disklabel "in block 0" a lot better than the manpages's "starts at block 0". > > Under "Writing a standard label", the manpage says: > > > > PC-based systems have special requirements in order for the BIOS to > > properly recognize a FreeBSD disklabel. Older systems may require > > what is known as a ''dangerously dedicated'' disklabel, which > > creates a fake DOS partition to work around problems older BIOSes > > have with modern disk geometries. > > > > 5) What's "fake DOS partition"? DD disks don't have partitions. Is it > > just trying to not bother saying that it fills in the MBR partition > > table as if there was at least one slice which the DD MBR will ignore. > > DD disks don't have fdisk partitions, but they have an fdisk table. It > has one partition that covers the entire disk. That's probably what > they are referring to. Note that the system also supports accessing > the drive as if it had one fdisk partition, so that da0s1a and da0a > reference the same bit of disk if da0 is DD. It's not clear what "one partition" means. Do you mean data in the table only or some layout of data on the disk? A fully dedicated disk's partition table has dummy data while a DD disk's table is set for one whole-disk slice. OK, for the table, but what about the non-boot parts of the disk? Are the two cases any different as to where the data area starts and stops (as far as the OS is concerned; eg, are da0s1a and da0a the same or even both available)? If the DD disk has a data area that matches the faked partition table, then how does a DD disk differ from a normal disk with one slice? > > 6) Why is the problem limited to older systems? Don't new BIOSes > > check for a normal-looking partition table? > > The BIOS checking the fdisk table isn't what you're avoiding with a DD > disk. What you're avoiding is the BIOS geometry calculations at boot > time. Older BIOSes apparently have trouble with that. Unless they get some help from the bootstrap code (like was usually available in the MSFT world). But I get the picture now, thanks. > > 7) Isn't the first sentence wrong? BIOS don't look for disklabels, do > > they? The special requirements are in order for the BIOS to find the > > FreeBSD stage 1 boot record, no?. (And the FreeBSD installer doesn't > > satisfy the requirements for non-DD disks (as I read the FAQ's DD > > answer). I can't imagine why not. Older systems with a standard > > MBR boot any active slice (even FreeBSD) without problems, no?) > > I think the first sentence has confusing wording, in that PC BIOSes > could be confused if there wasn't an fdisk table. It should say > "recognize disks with a FreeBSD disklabel." > > A standard FreeBSD disklabel does *not* have an fdisk table in > it. That's what gets put at the beginning of fdisk partitions, and at > the beginning of disks on non-PC based systems. If you put that at the > beginning of a disk on a PC, you could confuse the BIOS. The special > requirements are that you have an fdisk table. But if the BIOS doesn't check the table (as you said above), then the BIOS can be confused only if the boot code does something to confuse the BIOS. Isn't the magic of a DD disk, that the boot code and BIOS don't USE the table at all and so there are no calculations to mess up? I just don't see why a DD disk needs to be different than a fully dedicated disk (ie, have a faked table), unless the BIOS checks it or the bootstrap uses it like a non-fake table. > P.S. - I've used "fdisk partition" here since the OP used > "partition". The standard FreeBSD terminology is "slice". I used "slice" three times and "partition" once a few words after the "fake DOS partition" quote, so I thought the "DOS" was implied. I try to not use "partition" except where it's obvious what kind of partition is meant. Otherwise I try to use "slice", "primary partition", "secondary partition", or (starting with your message about "grub") "subpartition". Thanks for the help. It's a shame, with so much documentation devoted to this topic (disklabel(1), boot0cfg(8), boot(8), fdisk(8), newfs(8), handbook, & faq), that it's not more clear what's going on. I'd like to help improve it some, if I can. May I CC you when I submit patches? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?vvsmvvv9m7.mvv>