Subject: Re: New "release" snapshot
To: Frederick Bruckman <fb@enteract.com>
From: Bob Nestor <rnestor@augustmail.com>
List: port-mac68k
Date: 12/21/1999 20:24:44
Frederick Bruckman  (fb@enteract.com) wrote:

>On Tue, 21 Dec 1999, Bob Nestor wrote:

>> Building an Installation Kernel fails with an error in x_ftp,
>
>Does it help if you "make depend && make" in /usr/src/usr.bin/ftp
>first? The intention is that the installation kernel is to be built as
>part of a "make release", after the tree is fully populated. It should
>work, of course, within /usr/src/distrib/mac68k/instkernel as long as
>the binaries and INSTALL kernel are already made, but I think ftp on
>demand of distrib may be different than doing it from "make build".
>(This is bad, yes, but all the ports seem to have the same situation.)
>
I'll give it a try later.  For now I just changed the sl_add() call so it 
doesn't check the non-existant return code which is causing the 
compilation error.

>> and past that the final merge step fails because of an unresolved
>> reference to softdep code in the INSTALL kernel.
>
>Also bad. (Scott?) You can work around this, for now, by defining
>"options SOFTDEP" in the INSTALL kernel.
>
Ditto. Will try this later.

>
>> The build of the miniroot also bombed, but I never did get that to
>> work even back in the 1.4 source when I first worke don sysinst.
>
>The install kernel needs one or two files from under miniroot, but we
>don't have any reason to build it.

Yeah, I'm sure I can work around it if I can remember what I did back on 
1.4 to get this to work.  In the meantime here are the patches to 
sysinst.  It builds but I haven't tired it in my system yet.  I need to 
rebuild my kernel to take the kernel patch out, re-init the disk under 
MacOS to make sure sysinst work, then do the test. I figured I'd get you 
the patches so you can start working with it ASAP if you want to.  
Looking at the ioctl that Bill suggested I don't see why it shouldn't 
work (i missed that ioctl when I was doing the code months ago). The only 
possible problem is that the disklabel might not be fully populated, but 
I filled in all the fields that the kernel does now when it boots, so it 
should be OK.  Let me know how it goes. 

-bob

--- md.h.orig	Sun Dec 19 10:38:10 1999
+++ md.h	Sun Dec 19 10:38:50 1999
@@ -190,7 +190,7 @@
  * command string.  The Mac Disk Partition Map gets written in the
  * md_pre_disklabel() routine.
  *
- * #define DISKLABEL_CMD
+ * #define DISKLABEL_CMD "/sbin.disklabel -r"
  */
 
 /* Definition of files to retrieve from ftp. */


--- md.c.orig	Sun Dec 19 10:38:04 1999
+++ md.c	Tue Dec 21 19:46:43 1999
@@ -627,8 +627,9 @@
 int
 md_pre_disklabel()
 {
-    int fd;
+    int fd, i;
     char devname[100];
+    struct disklabel lp;
 
     /*
      * Danger Will Robinson!  We're about to turn that nice MacOS disk
@@ -682,8 +683,25 @@
 	exit (1);
     }
     /*
-     * 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.
+     *
+     * First, we grab a copy of the incore table as it existed before
+     * we did anything to it. Then we'll move our new partition info
+     * into it. That way we don't have to update those parts of the
+     * label we haven't changed.
      */
+    ioctl(fd, DIOCGDINFO, &lp);    /* Get the current disk label */
+    lp.d_npartitions = 0;
+    for (i=0;i<MAXPARTITIONS;i++) {
+        lp.d_partitions[i].p_size = bsdlabel[i].pi_size;
+        lp.d_partitions[i].p_offset = bsdlabel[i].pi_offset;
+        lp.d_partitions[i].p_fstype = bsdlabel[i].pi_fstype;
+        if (bsdlabel[i].pi_fstype != FS_UNUSED)
+           lp.d_npartitions = i+1;
+    }
+    ioctl(fd, DIOCSDINFO, &lp);
     close (fd);
     return 0;
 }