Date: Wed, 30 Aug 1995 05:49:12 +1000 From: Bruce Evans <bde@zeta.org.au> To: hackers@FreeBSD.org, luigi@labinfo.iet.unipi.it Subject: Re: fdisk & disklabel troubles Message-ID: <199508291949.FAA31110@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
>I am having a hard time in understanding/using the parameters used
>in the disk-maintainance utilities (fdisk, disklabel, sysinstall
>etc.) since the introduction of slices (tried this on both
>2.0.5-RELEASE and the 950726-SNAPSHOT).
Sigh.
>* fdisk cannot read a valid partition table from either disk. The
> "bios idea" of the disk, as printed by fdisk, shows one cylinder less
> than the real size.
fdisk is limited and broken, but operates the much same as before the
slice changes. There is no guarantee that it will get the BIOS geometry
right in either case:
before: it just prints the values in the label. These are at best what
you typed in for the label and are often different from the BIOS
geometry.
after: it just prints the values in the dummy label for the whole disk.
The slice code attempts to guess the geometry based on values in
the partition table. This often works, except for the number
of cylinders which was usually the physical number of cylinders
(bug fixed in -current). If the partition table is empty, then
guessing can't work and the geomtry is usually the geometry
reported by the drive.
In both cases you need to learn the BIOS geometry in another way and
change fdisk's defaults if they are wrong.
>* fdisk cannot write the partition table either (or at least, it cannot
> be read back!). I tried to set the correct parameters and write to
> disk, fdisk did not write any error message but reading again the
> partition table shows the same old values.
> (cannot do further experiments with working fdisks, but my setting is
> easily reproducible).
The geometry can't be changed directly using fdisk; it only writes the
partition table. Changes to partition should stick. Changes to the
partition table may affect the guessed geometry, but the driver won't
change the guessed geometry until all minors on the drive are closed
and one is opened. If the drive has root or active(?) swap on it, all
minors won't be closed until reboot and the guessed geometry won't
change. fdisk writes the partition table without informing the driver
about the changes. This it is not guaranteed that the driver state is
consistent with the disk state.
You should boot from a floppy or from the network or somewhere if you
want to run fdisk on the root disk. Or change a little at a time (for
safety) and reboot to see the changes.
>* (BTW, the "usage" line of fdisk shows a "-r" flag which does not
> exist.
BTW2, there is an undocumented "-a" flag that allows changing only
the active partition.
>Luckily, fdisk does not kill the system. With disklabel, things seem to
>be worse: whenever I try to write a label, the system reboots.
950726-SNAPSHOT probably has a bug amplified on 950725 that causes
`disklabel -e' to reboot for all changes. The bug was fairly harmless
in 1.0...2.0.
>As a reference, here are the different ideas of the disks:
>REAL: 1010 cyl, 12 hd, 55 sec, total 666.600 sectors
>fdisk: 1009 cyl, 12 hd, 55 sec, part. start 1, size 665.939
> beg.: cyl.0 sec.2 hd.0
> end: cyl.1009 sec.1 hd.0
>disklabel: 1009 cyl, 12 hd, 55 sec, size 666.545
>REAL: 1057 cyl, 16 hd, 63 sec, total 1.065.456 sectors
>fdisk: 1056 cyl, 16 hd, 63 sec, part. start 1, size 1.064.447
> beg.: cyl.0 sec.2 hd.0
> end: cyl.32 sec.1 hd.0
>disklabel: 1056 cyl, 16 hd, 63 sec, size 1.065.393
These have the same bugs:
1) the ending head and sector doesn't give the BIOS geometry. The ending
head must be the same as the BIOS number of heads less one and the ending
sector must be the same as the BIOS number of sectors for at least one
slice. fdisk should enforce this for the FreeBSD slice (if any), but it
doesn't, so the user is responsible for it. This requirement hasn't
changed since 386BSD-0.1.
2) the size is one sector too large, or perhaps one cylinder less one
sector too small, so the slice extends one sector into the cylinder
after the last, or perhaps it just ends in a strange place. Bug 1)
is sort of a side effect of this.
These bugs now only affect the guessing of the geometry. The geometry
is only used as a default for fdisk. Before the slice changes, they
would have stopped booting except for simple partition tables above
where the FreeBSD partition starts on the first track.
>I also tried to use /stand/sysinstall for formatting the disk, but
>without luck: the Write option in the partition editor does not
Sysinstall is much better than fdisk, but it isn't really suitable
for use except at compile time, and it is subject to the same problems
with guessed geometries as fdisk.
>So: does anyone know of a safe way to fdisk/disklabel a disk on 2.0.5
>and newer releases ? I have already lost the partition table on two
>disks, and have killed the data on the disks by trying to fix them with
>fdisk &C. And now I am really scared on installing 2.0.5 rather than
>snap950322 on newer machines!
fdisk: same as before. Be careful.
disklabel: as documented in disklabel(8), but not as documented in old
386BSD and FreeBSD documentation and folklore. The first FreeBSD slice
is the whole disk from disklabel's point of view, so the 'c' partition
must begin at offset 0 and extend to the end of the (virtual) disk,
the 'd' partition isn't special, and partitions outside of the (virtual)
disk don't make sense. It's relatively difficult to kill the data
with disklabel. Avoid using `disklabel -e' in SNAPs where it causes
a panic. Use `disklabel -r -w' instead.
Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199508291949.FAA31110>