Greg Earle reported:

>I tried booting the 1.2.1 install floppies.  Once again, it went down in

As I think you've already discovered, NetBSD/i386 1.2.1 installs from two 
floppies which may cause problems with VirtualPC.  Version 1.2D uses a 
single install floppy with a RAMdisk making for a much simpler install 
under VirtualPC. Make sure you get a copy of the updated Install README 
which has been updated to reflect the one-disk install process.

>
>So, last night I downloaded the SSTO 1.2D snapshot floppy and tried again.
>
>I had a *lot* of trouble getting my home Mac (an 8500/120) to read the 
>floppy!
>When it finally booted - incidentally, the 1.D kernel identifies the Virtual
>CPU as "CPU: Pentium (ConnectixCPU  586-class) with MMX", to the person who

Yeah, the official word from Connectix is that MMX is shipping in first 
release. Unfortunately they're not selling it without one of the 
MicroStuff OSes.  So for about $140 you get your choice of Windows-95 or 
Windows 3.11.  All the mailorder houses are now accepting orders for 
delivery starting next week.
 
>[Much later]  It's happening again.  I booted the 1.2D floppy, then tried
>to figure out where the heck the "netbsd.gz" is on the floppy.  I tried

As I recall the RAMdisk installation in 1.2D installs the filesystem and 
a minmal Kernel. The binary snapshot files include a new KERN save-set 
which contains the GENERIC Kernel.

>> 2) Ethernet emulation would cause probe problems during boot.  Had to 
>>    disable the card.
>
>I haven't gotten this far yet  :-)
>
The ethernet emulation was supposed to make the card look like a DEC 
ethernet card of some type.  The version of the emulator I tested on 
didn't seem to have a 100% faithful emulation of the DEC card, so 
although NetBSD and FreeBSD probed it as such, they couldn't convince it 
to work as they expected.  Hopefully this is corrected in the offical 
release.  Also, the ethernet support doesn't run under MacTCP or OT. The 
emulator grabs the card out from under MacOS blowing away anything that 
might have been using it at the time.

>This is troubling, because it's gonna be hard to get the rest of the
>NetBSD 1.2D snapshot onto the disk if I don't have a network ...
>
Not if the floppy can be coherced into working.  All the binary tarballs 
will fit on about 12 floppies. Of course if shared folder work these can 
all be stored on the MaxOS filesystem and accessed from there as SoftPC 
and SoftWindows do with their shared folder support.

>> 3) CDROM was unsupported, but then NetBSD doesn't support ATAPI CDROMs yet.
>
>Yes, the emulator supports the Mac CD-ROM drive as an IDE/ATAPI CD-ROM drive.
>(Which is weird, since the CD-ROM is a Matshita SCSI CD-ROM drive!  But the
> emulator doesn't support the Mac SCSI, which is sort of a bummer.)  Also,

The emulator supports the Mac SCSI CDROM making it appear as an IDE/ATAPI 
CDROM.  As far as I know ATAPI support of CDROMs isn't in the official 
NetBSD/i386 sources yet, although there is a set of patches one can apply 
to the "wd" driver if one can do a Kernel build.  So even though 
NetBSD/i386 has a Matshita SCSI CDROM driver, you'll need ATAPI support 
in the "wd" driver to access it under VirtualPC.

>the VPC I tried had a folder with two files, VPCQIDECD.SYS and MSCD.EXE,
>that supposedly support being able to use the CD-ROM if you run DOS in the
>emulator instead of NetBSD.)

Apparently the version of VirtualPC I tested on was an early incomplete 
1.0b6 version. I've been told that later versions did have more complete 
support built in, but as you say these drivers are for DOS.

>
>> 4) Shared Folders didn't work.
>
>Not gotten this far ...

If this works in the offical released version it would be a great way to 
bypass the floppy and ethernet problems and do a complete install.
>
>> The only problem I ran into with the 1.2D i386 snapshot, was the that the 
>> installer disk can't write disklabels to a brand new disk.  Looks like a 
>> missing parameter in the install script bundled on the installer 
>> mini-root disk.  A little manual intervention and I was up and running.
>
>I ran into the same problem.  Can you tell me what you did, Bob?
>
The install script on the RAMdisk tries to write the disk label using 
something like
"disklabel -r /dev/wd0 mywd".  I believe this is a re-write operation and 
fails if there is not currently a valid disklabel on the volume.  The 
correct syntax is probably
"disklabel -r -w /dev/wd0 mywd".  Go through the install script until you 
get past the point of setting up the disk partitions. You'll see errors 
from disklabel reporting it couldn't write the labels.  After defining 
your partitions you can Control/C out of the installation script and 
manually enter the
"disklabel -r -w /dev/wd0 mywd"  (I don't recall offhand if it's /dev/wd0 
or /dev/wd0c).
This will write the disk label to a new volume. Then go back and start 
the install script over with a "./install".  It'll ask about disk 
partitions again and you can either enter the same ones as before or 
change them on this pass.

>Also, generic NetBSD/i386 1.2D snapshot question: Where on the boot floppy
>is the "netbsd.gz" kernel stored?  When the floppy boots, if you quit out
>of the install, "mount" shows "root_device on /", but there's no "netbsd.gz"
>there.  I assume it's in another partition (arggh, I *hate* "root_device",
>can't we please use good ol' "/dev/fd0a" or whatnot?!?), but where?  I can't
>get it to boot off of the normal virtual "disk" without a kernel ... (again,
>Bob, how did you handle this part?)

I may not understand your problem, but let me give it a try.  The real 
Kernel you want to install is in the KERN tarball.  But once you've gone 
through the installation script on the 1.2D bootable floppy you should 
have a bootable filesystem on your hard drive, and it should boot up in 
VirtualPC.  If it doesn't you've missed that all important step of doing 
the FDISK partitioning under DOS or of running PFDISK to convert the 
partition into a type 165.  In my case I used an MSDOS bootable floppy 
that contains FDISK and PFDISK and used PFDISK to zap the entire DOS 
Primary Partition into a BSD type 165.  When I did disk partitioning 
under BSD I specified sectors instead of cylinders and used a cylinder 
count one less than the number probed by NetBSD. This forces you to enter 
the size of the NetBSD portion of the DOS disk and an offset of where it 
begins.  FDISK will give you these two values.  This method of 
partitioning leaves the original volume map intact to support additional 
systems.  I've never managed to get NetBSD/i386 to use an entire DOS disk 
volume any other way.  All other methods I've attempted usually result in 
an unbootable disk volume.  Check out the *BSD FAQ by Dave Burgess.  It's 
a goldmine of information for anyone running any one of the BSD 
implementations on any platform.
>
>Thanks, and sorry for all the questions ...
>
No problem.  But unless there's a real interest on the part of other 
users on the i386 or mac68k list, let's take this to E-Mail.

-bob