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;
}