Hi.

> boot on any other partition than 'a'. The error message is the following:
> 
> >>boot 5/rz1d/netbsdBoot: 5/rz1d/netbsdopen(5/rz1d/netbsd) failed: 19
> Can't boot '5/rz1d/netbsd'

I think that you're correct, in that the boot loaders assume the
'a' partition.

You can't specify the partition to the DEC PROM boot program either. You
have to use:

boot 5/rz1/netbsd

E.g. you get to choose the disk, no finer granularity than that, AFAIK :)


You _can_ mount the miniroot disk read/write.

'fsck' it first, and then mount it:

mount /dev/rz1a /

It will be mounted.

However, you will be unable to 'umount' it subsequently. 'umount' will
complain that '/' is not an invalid argument... :)

You can get around this with the reset button, but this may damage
the filesystem, as it is mounted and you have no way to unmount it
cleanly. However, I've done this a fair bit recently..

Just remember to type 'sync' a lot whilst using the miniroot.
(You're in single-user mode, there's nothing else flushing the
disk buffers...)

Also, when creating a.n.other boot partition, avoid the pitfall I
recently discovered: using the '-O` option (for a 4.3BSD filesystem) 
creates a root partition that you can't boot from, apparently....

Just use 'newfs /dev/rzXX'.

> Any idea of what went wrong/what I should do now (for boting is one thing but I 
> really look forward to runing a full-featured NetBSD system :-) ?


I've recently got 3 pmax machines converted to NetBSD, 3-4 to go....
Getting easier/faster each time. :)

It's pretty cool. Certainly a lot nicer than any flavour (<<<=== yup, I'm
a Brit) of Ultrix (*barf*) I ever used.


My suggestion would be to either:

1. Juggle it on one disk:
-------------------------
i)	'newfs' the '/dev/rz1d' partition, mount it read/write (on
	/a or similar).

	Copy the entire contents of the miniroot to it.

	mount it as '/', newfs '/dev/rz1a', either copy the files
	from the miniroot back, or unpack the 'base' and 'etc' filesets
	into the root. (Don't forget to './MAKEDEV all' in the new '/dev'
	if you do this).

	I've not actually _done_ this you understand, (I've always had
	the luxury of a.n.other disk), but I can't see why it shouldn't
	work...

Some sequence of commands that looked something like:

newfs /dev/rz1d
mount /dev/rz1d /a
( cd /; tar --one-file-system -c -f - . ) | ( cd /a ; tar xvf - )

sync;sync
cd /
umount /a

mount /dev/rz1d /

newfs /dev/rz1a
mount /dev/rz1a /a

# Copy it back to the original miniroot '/' partition, now
# that we've created a filesystem on there.
( cd /; tar --one-file-system -c -f - . ) | ( cd /a; tar xvf - )

sync;sync; cd /
umount /a

# These contortions are due to the miniroot having a 'fixed' filesystem
# size built into the filesystem (you never 'newfs'd the filesystem right,
# you just 'dd'd it onto a partition?)

Now Reboot. *sigh*. I don't know of any alternative at this stage to 
using either the small reset button or it's larger cousin (marked only 
'0' and '1')..

You'll end up in the miniroot, but the filesystem will be the 'correct'
size, e.g. they'll reflect the size of the 'a' partition.

'fsck' the 'root' partition _before_ mounting it read/write:

fsck /dev/rz1a

(Otherwise, you'll have to 'fsck' _after_ mounting it read/write, then
it'll modify the root filesystem, then you'll have to reboot immediately
with no sync etc. etc.)

Mount your `/usr/ partition for NetBSD (unless you intend keeping '/usr'
on the root partition).

Mount the ultrix partition read-only and unpack the sets you want:

mount -r -t ufs /dev/rz0g /a
tar xvzf /a/NetBSD-1.2/base.tar.gz
tar xvzf /a/NetBSD-1.2/etc.tar.gz

sync;sync;

Put in as much information as you need in the following files:

/etc/hosts:
Localhost, this host, gateway, router?)

/etc/fstab:

# Format like:

/dev/rz1a	/	ffs	rw	1	1
/dev/rz1b	none	swap	sw	0	0
/dev/rz1g	/usr	ffs	rw	1	2

/etc/myname:

myhost.mydomain.com

/etc/hostname.le0:

inet myhost


And, optionally,
/etc/resolv.conf:

domain mydomain.com
nameserver nnn.nnn.nnn.nnn

Sync the disks with 'sync;sync', you should now find that you
can use the 'reboot' and 'halt' commands, after doing a 'hash -r'
command..

Reboot.. Enjoy!! :)


2. Blow away Ultrix
-------------------

i)	'disklabel' the Ultrix disk, 'newfs' /dev/rz0a and your intended
	'usr' partition, mount the new root and 'usr' partitions in some
	mount point, cd to the mount point and unpack the 'base' and 
	'etc' filesets, 'MAKEDEV' the new devices, copy over the GENERIC 
	kernel etc, modify/create files in <mountpoint/etc as above and
	reboot...

I _know_ that this works. Hardest part of this is poncing around with 
'disklabel' changing the default partition sizes using only 'ed' as 
an editor...

But, if it goes wrong, you may end up with a system that you
can't run Ultrix or NetBSD on...


For either method, I find that it can be useful, when running
MAKEDEV, to add the new directories to the PATH (don't forget
to 'hash -r' afterwards) and comment out the line in the
MAKEDEV script that explicitly sets the PATH....

You'll get a few messages relating to 'wheel' 'bin' and
other users not being valid, but I've always ignored these
and it doesn't seem to have bitten me.. :)


Hope this helps, 

Good Luck!! :)

Regards,

AS
	

Disclaimers:

Don't blame me if this trashes your system.

I've not presonally tried the GNU 'tar' magic '--one-file-system' flag
to prevent it descending into mounted filesystems ('coz the man
pages weren't on-line when _I_ did this the first time around :)
I let it run and removed '/a/a/*' later...

I think either way should  work, but I'd advise that you check the 
commands over carefully before running them.. Feel free to email
me if you want to.

All of the above applies to NetBSD/pmax 1.2 *ONLY*, I've never tried 
anything with any other release.