Date: Thu, 25 Jul 1996 15:43:07 +0200 From: Andries.Brouwer@cwi.nl To: bde@zeta.org.au, freebsd-bugs@freebsd.org, j@uriah.heep.sax.de Subject: Re: installation fails Message-ID: <9607251343.AA00204=aeb@zeus-184.cwi.nl>
next in thread | raw e-mail | index | archive | help
> In sys.c:find() the boot code divides by 0, causing a loop of reboots,
> and one way of preventing that is to replace the lines
> /* This little trick is for OnTrack DiskManager disks */
> boff = dl->d_partitions[part].p_offset -
> dl->d_partitions[2].p_offset + sector;
> in disk.c by
> boff = sector;
Apparently the partition table has the wrong offsets in it.
What happens here (my first encounter with the phenomenon of
disk labels went by reading "dd if=/dev/hda4 | od -c")
is that d_partitions[0] and d_partitions[1] contain all zeros,
while d_partitions[2] and d_partitions[3] describe the (same)
partition - they only differed in a type byte. The remaining
partitions are zero again.
`part' and both of the p_offset's should be 0 here.
So part is zero, and so is d_partitions[part].p_offset,
but not dl->d_partitions[2].p_offset. Indeed, the latter
equals sector. The effect is that boff is set to zero,
and later, when the superblock is read, it is looked for
in sectors 16-31 instead of the 408016-408031 where it really was.
Instead of the patch give above, I might have put
part = 3;
to get the same effect. A reasonable thing to do for
a robust booter might be to pick for part the smallest
number different from 2 for which d_partitions[part].p_offset
is nonzero, and 2 if there is no such number.
(And of course the booter should check the magic numbers.)
A couple of lines later, b_size
is set to dl->d_partitions[part].p_size.
By the way, there is a formal bug in the source there, in
that b_size is only defined inside #ifdef DO_BAD144 ... #endif,
while it is used here outside such an ifdef.
>Discussion:
> The above patches work entirely satisfactorily,
> but the real problem is that this Disklabel Editor
> did not write anything in partition[0], while the
> disk.c code assumes that there would be something.
It has to write something there since all of the partition
entries have to be written together. It probably writes 0.
Yes.
Andries
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9607251343.AA00204=aeb>