Re: [9fans] bug fix to /sys/src/libdisk/disk.c and /386/bin/format

Re: [9fans] bug fix to /sys/src/libdisk/disk.c and /386/bin/format

[Russ Cox]

If I remember correctly, Microsoft's standard
MBR has trouble with booting in more than 2GB.

Thanks for the fix.

Russ

Re: [9fans] bug fix to /sys/src/libdisk/disk.c and /386/bin/format

[Mike Haertel]

>Perhaps a working Plan 9 boot block (512 bytes) could be
>placed on the distribution updates page?  (One could floppy-
>boot the system then copy the new block into place.)

The problem with this idea is that getting the correct bits
in your Plan 9 boot block depends on the disk geometry as
well as the details of the 9fat partition.  So there is
no one-size-fits-all boot block.

But, perhaps the Bell Labs folks could provide a new
install/boot floppy image, with a bugfixed format binary?

In the meantime, here is a sleazy workaround you can do
with the current install/boot floppy that will have the
exact same effect: just prior to doing the "bootsetup"
command, start a new window, and in the new window type
this command:

	dd -if /dev/sd00/data -of /dev/sd00/9fat -count 1

(where sd00 is the disk you are installing Plan 9 on; for IDE
disks it will be something like sdC0, etc.)

Then, go back to the install command window, run "bootsetup",
and select the "plan9" boot method.  (It will ask if you want
to install a new master boot record; in my experience you
can usually decline and things will work fine--you especially
want to say "no" if you are running a multi-boot manager of
some kind.  I use the one that comes with FreeBSD.)

Re: [9fans] bug fix to /sys/src/libdisk/disk.c and /386/bin/format

[Douglas A. Gwyn]

Mike Haertel wrote:
> Upon attempting to boot Plan 9, I got to PBS, and then got
> the failure: Bad format.

Yeah, that has also happened to me (even before the latest big
update) with either the Win/NT multiboot (BOOT.INI) hook or the
partition boot method.  (The boot floppy method works.  Windows
ME doesn't support CONFIG.SYS/AUTOBOOT.SYS, so the Windows 9x
method doesn't work for Win/ME.)  I hope your patch will enable
construction of a usable boot block.  The interaction of Win/ME,
Win/2K, Solaris 8 (x86 boot manager partition), and Plan 9
mangling of the PBR has caused me to rebuild, several times,
*everything* on the 3 20.5MB IDE disks on the new system I'm
trying to get set up (which should eventually take over from
the one I'm typing this on).

Perhaps a working Plan 9 boot block (512 bytes) could be
placed on the distribution updates page?  (One could floppy-
boot the system then copy the new block into place.)

[9fans] bug fix to /sys/src/libdisk/disk.c and /386/bin/format

[Mike Haertel]

I recently attempted to install Plan 9 on a 9GB SCSI disk
using a Tekram controller.

The install process appeared to work fine.  When I reached
the "bootsetup" step, I chose native Plan 9 boot from the
hard disk.  It made the usual whining about disks >2GB [*],
but I had a multi-boot manager in the MBR, so I elected
not to install Plan 9's MBR.

Upon attempting to boot Plan 9, I got to PBS, and then got
the failure: Bad format.

It turned out the reason was that the disk geometry recorded
in the PBS did not match the actual geometry being used by
the SCSI BIOS.

I worked backwards through the scripts and commands to reach
the geometry guessing routines in /sys/src/libdisk/disk.c.
Since I had a SCSI disk, the ATA geometry determination method
(which is probably the most reliable) was not applicable.

Upon inspecting the code, I found that opendisk() would attempt
to look for an MBR in the first sector of the disk partition
being opened, and if it found one, look for a consistent
geometry in that MBR.  Unfortunately, the first sector of
sd00/9fat was *not* the first sector of the disk, it was just
the first sector of the partition, and contained garbage.

As an experiment, I tried running dd from another window on
the install floppy, and copying the MBR from the real first
sector of the disk to the first sector of the 9fat slice, and
then running "bootsetup".  Much to my relief, it created a
Plan 9 boot sector with the correct geometry.  I then began
working on a real fix.

Enclosed is a fix to opendisk() which modifies the routine
partitiongeometry() to try looking for the MBR first in
the whole-disk partition /dev/sdXX/data, and only if that
fails will it look for an MBR in the first sector of the
partition being opened.

There is also another minor bug fix to a call to strdup()
whose return area was being overwritten with a potentially
longer string than the original string given to strdup().

I replaced format on the install floppy with one linked
with my new libdisk, then I bravely zeroed out my 9fat
partition contents, reconstructed the same Plan 9 partitions,
and ran bootsetup again.  It worked.

I am very surprised nobody has complained about this before.
As far as I can tell, without this fix Plan 9 will not install
correctly on any reasonably large (> 1GB) SCSI disk unless it
is installed near the very beginning of the disk.

Footnote:
[*] Just out of curiosity, what OSes' MBRs have trouble
at the 2GB boundary?  I am very familiar with trouble at
the 8GB boundary requiring LBA addressing, but I have never
seen an MBR that chokes at 2GB.

Diffs (against the October release of Plan 9):
% diff /sys/src/libdisk/disk.c disk.c
63c63,65
< 	Table *t;
---
> 	Table *t = (Table *)(buf + Toffset);
> 	char *rawname;
> 	int rawfd;
65,67c67,92
<
< 	if(seek(disk->fd, 0, 0) < 0) {
< 		return -1;
---
> 	/*
> 	 * look for an MBR first in the /dev/sdXX/data partition, otherwise
> 	 * attempt to fall back on the current partition.
> 	 */
> 	rawname = malloc(strlen(disk->prefix) + 5);	/* prefix + "data" + nul */
> 	if (rawname) {
> 		strcpy(rawname, disk->prefix);
> 		strcat(rawname, "data");
> 		rawfd = open(rawname, OREAD);
> 		free(rawname);
> 		if (rawfd >= 0
> 		    && seek(rawfd, 0, 0) >= 0
> 		    && readn(rawfd, buf, 512) == 512
> 		    && t->magic[0] == Magic0
> 		    && t->magic[1] == Magic1) {
> 			close(rawfd);
> 		} else {
> 			if (rawfd >= 0)
> 				close(rawfd);
> 			if (seek(disk->fd, 0, 0) < 0
> 			    || readn(disk->fd, buf, 512) != 512
> 			    || t->magic[0] != Magic0
> 			    || t->magic[1] != Magic1) {
> 				return -1;
> 			}
> 		}
70,77d94
< 	if(readn(disk->fd, buf, 512) != 512) {
< 		return -1;
< 	}
<
< 	t = (Table*)(buf+Toffset);
< 	if(t->magic[0] != Magic0 || t->magic[1] != Magic1)
< 		return -1;
<
279c296
< 	p = strdup(disk);
---
> 	p = malloc(strlen(disk) + 4);	/* disk + "ctl" + nul */
285a303
> 	strcpy(p, disk);