Subject: install/8434: Sysinst/mac68k fails to partition disk during installation
To: None <gnats-bugs@gnats.netbsd.org>
From: None <rnestor@augustmail.com>
List: netbsd-bugs
Date: 09/17/1999 19:05:46
>Number: 8434
>Category: install
>Synopsis: Sysinst/mac68k fails to partition disk during installation
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: install-manager (NetBSD system installation bug manager)
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Sep 17 19:05:01 1999
>Last-Modified:
>Originator: Bob Nestor
>Organization:
>Release: NetBSD 1.4.1
>Environment:
NetBSD pluto 1.4.1 NetBSD 1.4.1 (GENERICSBC) #1: Wed Sep 15 18:26:09 CDT 1999 bob@pluto:/usr/src/sys/arch/mac68k/compile/GENERICSBC mac68k
>Description:
Sysinst/mac68k correctly partitions the target disk and writes an
updated Apple Disk Partition Map to the disk. It is unable to get
the incore disk label updated since this is normally done when writing
a BSD natve disk label to the disk which is currently unsported in the
mac68k port. By having the mac68k specific writedisklabel() routine
call readdisklabel() before returning, the current values of the
Apple Disk Partition Map are rescanned and the faked incore disk label
used on the mac68k port is reinitialized. This allows sysint/mac68k
to update the Apple Disk Partition Map on disk and issue a NetBSD
I/O call to attempt to write the BSD disk label resulting in an updated
incore disk label. Should native disk labels be supported in the
future, this patch can be replaced with code which handles writing
the native disk label to disk. Alternatively the code now in sysinst
that converts the incore BSD label to an Apple Disk Partition Map
could be used which would provide the appearance of BSD native disk
labels using the existing Apple Disk Partition Map.
>How-To-Repeat:
Attempt to partition a disk with sysinst/mac68k in preparation for
a new system installation. Executing a "diskabel sd?" on the volume
shows the disk has not been modified, but rebooting the system and
executing the "disklabel sd?" shows it in fact has been modified. The
discrepency is the result of not having an updated incore disk label
tracking the updated ondisk Partition Map.
>Fix:
Two patches are necessary, one to /usr/src/sys/arch/mac68k/mac68k/disksubr.c
and one to /usr/src/distrib/utils/sysinst/arch/mac68k/md.c. A third
patch to /usr/src/distrib/utils/sysinst/arch/mac68k/md.h is not required,
but provides some additional documentation to what is happening and
might aid in future modifications.
disksubr.c
--- disksubr.c.orig Tue Sep 14 19:45:32 1999
+++ disksubr.c Fri Sep 17 19:53:04 1999
@@ -564,7 +564,21 @@
brelse(bp);
return (error);
#else
- return 0;
+ /*
+ * Re-analyze the ondisk Apple Disk Partition Map and recompute
+ * the faked incore disk label. This is necessary for sysinst
+ * since it may have modified the disk layout but we don't
+ * support real BSD disk labels ondisk so we have no way of
+ * forcing the incore structure to synch with the ondisk. With
+ * this little hack sysinst can issue an "ioctl(f, DIOCWDINFO, lp)"
+ * which will come to this routine, be ignored, but as a side
+ * effect end up refreshing the incore disk label. We must
+ * still always return sucess even if it's not possible to
+ * reconstruct the incore label from the Disk Partition Map
+ * since vnconfig doesn't build Disk Partition Maps. rgn - 9/13/99
+ */
+ readdisklabel(dev, strat, lp, osdep);
+ return (0);
#endif
}
md.c
--- md.c.orig Fri Sep 17 19:57:22 1999
+++ md.c Fri Sep 17 19:59:10 1999
@@ -629,6 +629,7 @@
{
int fd;
char devname[100];
+ struct disklabel lp;
/*
* Danger Will Robinson! We're about to turn that nice MacOS disk
@@ -683,7 +684,28 @@
}
/*
* Well, if we get here the dirty deed has been done.
+ * Now we need to force the incore disk table to get updated. This
+ * should be done by disklabel which is normally called right after
+ * we return, but may be commented out for the mac68k port. So we'll
+ * try updating the incore table by forcing a dummy update here. This
+ * relies on a change in the mac68k specific writedisklabel() routine.
+ * If that change doesn't exist nothing bad happens here. If disklabel
+ * properly updates the ondisk and incore tables everything still
+ * works. Only if we fail here and if disklabel fails are we in
+ * in a state where we've updated the disk but not the incore and
+ * a reboot is necessary.
+ *
+ * First, we grab a copy of the incore table as it existed before
+ * we did anything to it. Then we call the set-update function to
+ * rewrite it to disk and update the incore tables. Without the
+ * changes to writedisklabel() this all becomes an expensive nop.
+ * With the changes the ondisk table is reread and the incore label
+ * is reconstruced from it. If disklabel() is then called to update
+ * again either that fails because the mac68k port doesn't support
+ * native disklabels, or it succeeds and writes out a new ondisk copy.
*/
+ ioctl(fd, DIOCGDINFO, &lp); /* Get the current disk label */
+ ioctl(fd, DIOCWDINFO, &lp); /* Write it out again */
close (fd);
return 0;
}
md.h
--- md.h.orig Tue Sep 14 19:19:07 1999
+++ md.h Tue Sep 14 19:19:22 1999
@@ -188,9 +188,14 @@
*
* The mac68k port doesn't support real disklabels so we don't define the
* command string. The Mac Disk Partition Map gets written in the
- * md_pre_disklabel() routine.
+ * md_pre_disklabel() routine and it also forces the incore copy to be
+ * updated. If native disklabels are supported or if disklabel() is
+ * fixed to work for writing labels, this command should be defined
+ * to so value that will force the writing of the label. In that case
+ * the code in md_pre_disklabel() which forces the incore updae can be
+ * removed, although its presence won't hurt.
*
- * #define DISKLABEL_CMD
+ * #define DISKLABEL_CMD "/sbin/disklabel -r"
*/
/* Definition of files to retrieve from ftp. */
>Audit-Trail:
>Unformatted: