Subject: upgrade comments and an idea
To: None <current-users@sun-lamp.cs.berkeley.edu>
From: Luke Mewburn <lm@rmit.edu.au>
List: current-users
Date: 12/31/1993 01:02:50
After weeks of stuffing around, I pulled the finger out on tuesday
and downloaded the entire current src dir from sun-lamp in preparation
for an upgrade. I removed the old /usr/src, installed the new one, and
went about upgrading to -current as per Marc W's instructions.
A few comments on going from -0.9 to -current.931228, following Marc's
instructions:
- had to recompile make fairly early on, so that $OBJDIR or whatever
works, otherwise gas, sh, and other things don't compile. (Realised
this after doing most the tree ;)
- had to include <sys/types.h> in libgcc/libgcc2.c so that gcc_bcmp worked
(size_t wasn't defined.). Otto vdL. noted this in an earlier
post (which I read after I found and solved the problem at home)
- applied Lennart A's pio.h fix after doing most of the install. It
meant that a newly compiled kernel actually recognises the HD now,
but it gives three wd timeout messages after the `biomask' message
and hangs (just before the `Automatic reboot in progress' step.)
I'm still on a NetBSD0.9 kernel because of this. The messages are
of a style i've not seen before (more informative), but I can't
remember their exact wording.
- the machine is rather flaky with everything installed (shared libs
and all). Everything (besides the kernel) is -current now. It is
rebooting all the time about five minutes into any make, and inetd
keeps on syslogging pmap_ errors. Is there code outside the kernel
that uses <machine/pio.h> that would have been affected by the
pre-Lennart fix?
- I added -pipe to CFLAGS in mk/sys.mk cause it makes the difference
in compiling (average improvement on my system is about 12-15%
faster). Also hacked the kernel makefile for the same. Using the
486dx50 my flatmate borrowed from work gives me <7m kernel compiles
that took >15m on my 386dx40.
Now, to my idea. I am often changing my unix HD around machines. A lot
of the time it's at home as the 2nd drive. Sometimes I take it to work
to rdump backup to a 1.7GB drive (ethernet beats floppies ;), where it
becomes the primary drive. This means I spend a lot of time changing
the fstab file. What I propose is a special series of devices, e.g,
/dev/bdxx or something like that. (bd == boot device.) It would be a
series of links or virtual nodes (the former is easier to kludge in
the kernel at startup time - the latter maybe conceptually `cleaner')
that would reference the device that the kernel loaded from.
E.g, if I boot of drive 0, tell the boot manager to load drive 1's
boot sector (the netbsd 1) which prompts me with:
netbsd.... wd(1,a)/netbsd: ....
(the new boot sectors are smart :), and I hit return, before the kernel
loads /etc/rc, or maybe even before swapping starts, /dev/bdxa points
to /dev/wd1a, thru to /dev/bdxh -> /dev/wd1h.
If we extend the concept further, we could theoretically config
kernels like:
config netbsd root on bdx swap on bdx
(unless a syntax exists - does
config netbsd generic
imply this?)
This way my fstab file can look like:
/dev/bdxa .... /
/dev/bdxb .... swap
etc.
Comments?
--
``Concealment is never as hard as people think, you Luke Mewburn
must understand that. It's action while hiding that's <lm@rmit.edu.au>
the hard part''
-- Coyote, in Kim Stanley Robinson's `Green Mars'
------------------------------------------------------------------------------