On Tue, 24 Aug 1999, Mat=EDas Giovannini wrote:

> Frederick Bruckman wrote:
> >=20
> > On Tue, 24 Aug 1999, Mat=EDas Giovannini wrote:
> >=20
> > I hadn't realized pdisk worked under MacOS. That's a good thing.
>=20
> MkLinux had a MacOS pdisk from the beginning. In fact, the code assumes
> that if it's not Linux, it must be MacOS, and includes SIOUX.h.

Ahh...

> > > Well, disklabel sd1 and disklabel -r sd1 say different things. You im=
ply
> > > they must be the same?
> >=20
> > "disklabel -r" evidently {reads,writes} a proper *BSD disklabel to
> > block 0 of the raw partition, where it can be read using the raw
> > device. No mac68k kernel code uses it, though! If you change the
> > Apple-style partition table using a program that groks same, that will
> > show up immediately on "disklabel", no "-r", and this one counts. Very
> > different from i386 and other ports that have in-kernel disklabels!
>=20
> what I did was
> # disklabel -i -r sd1
> <<my stuff>>
> # disklabel -r sd1 > foo
> # disklabel -R sd1 foo
>=20
> and I thought, well, now they must be the same, but nope: "disklabel
> sd1" kept groking the disk's original (that is, as formatted by Drive
> Setup) partition table. Furthermore, "newfs /dev/sd1a" only saw the
> small "partition map" partition instead of the big "usr" partition I was
> trying to create.

No, no, no. "disklabel -r", "disklabel -R" are both no-op's. You must
re-partition using a utility that understand's Apple Partition Maps,
such as "Drive Setup". "-r" writes and reads 'em, but they're useless!

> On the other hand, this disk isn't working as it should. So I'm
> beginning to think that maybe the controller is fried in some deep brown
> way, and it's none of disklabel's fault. Thoughts?

"disklabel -r" may have written something into block 0 that's
confusing the driver. Best thing is to re-format and re-partition, or
if not that, at least re-install the driver, and then use Mkfs to make
sure the partitions have the desired types.