Cvsupped with the tag=RELENG_4_0_0_RELEASE
Edit the supfile carefully; most cvsup problems are bad edits.
tag=RELENG_4 is the tag for 4.x-STABLE; that would work too, possibly with some additional things you need to do; see UPDATING in /usr/src. See NOTES below.
If you want openssh, you need to include (uncomment) cvs-crypto and get that as well as src-all; or uncomment src-crypto and src-secure; actually you don't need src-sys-crypto.
Copied /usr/src/etc/defaults/make.conf to both /etc/make.conf and /etc/defaults/make.conf, and edited the copy in /etc/make.conf, uncommenting selected lines like the line for U.S. residency and the line to use RSAREF, which I have installed. You make your own appropriate choices here.
cd 'd to /dev and did ls >dev.lst, so I have a list of devices I've created on the system.
cd'd to /usr/src/usr.bin/genassym and did make depend all install clean
cd'd to /usr/src/usr.sbin/config and did make depend all install clean
shut down cpu-intensive processes like X and rc5des (now dnetc)
cd'd to /usr/src/sys/i386/conf, cp'd GENERIC to NEWGEN, and just added stuff to NEWGEN--so basically it's a generic kernel with the bells and whistles I like, like options SOFTUPDATES and pseudo-device vn. There are so many changes that using an old config file is sure to get you into trouble.
Nevertheless, I got into some trouble. The 3.4 pn driver, which was running my Netgear ethernet card, has disappeared; the dc driver now does this work, but my ifconfig statement in rc.conf had pn0, so the network didn't come up when I rebooted. Had I been doing a remote upgrade, this would have required on-site attention. The pn driver isn't the only one that's disappeared. The GENERIC kernel with add-ons turned out to be a good strategy here.
Built and installed kernel; rebooted. The handbook remains the best source on how to do this, in case you've never done it. I copied my 3.4 kernel to kernel.34 before I installed the new kernel, so that I wouldn't lose my working 3.4 kernel (kernel always gets copied to kernel.old) if I had to make another one.
You may need to reboot into single user mode to avoid a kernel panic some people have experienced with the linux.ko loading. Then you mount the drives r/w and proceed.
Yikes, not only is the network not up, but I get these messages:
dmesg: /dev/drum not configured
netstat: kvm not available
Routing tables
rt_tables: symbol not in namelist
and of course top and ps don't work.
I proceeded anyway with:
make -j 4 buildworld
make -DNOINFO installworld
make installworld
I do this multi-user; other people are more cautious, at least on the installworld.
Copied /usr/src/etc/MAKEDEV to /dev and did sh MAKEDEV all
Then I did sh MAKEDEV da0 da1 da0s1 da0s2 da0s2 da1s1a da1s2a and
so forth until I had all the disk devices remade as character devices instead of block devices. If you have ide drives, you'd want to make the ad devices you need. You can do ls -l | grep ^b to find block devices that haven't yet been convered to character devices (device nodes, really); these are the ones sh MAKEDEV all didn't create. There are other devices you may need to make; the dev.lst should help to identify them, or you can wait until there's an indication that you need them. But people have had a lot more trouble with ide drives than with scsi drives, and if you have them it may be a good idea to look into this issue--what you want to do to /etc/fstab before you reboot--on the -stable mailing list.
Did a merge of /usr/src/etc with /etc. You can use mergemaster for this. I find it too detailed--I just copy, with cp -r for directories, the files I want to overwrite, being careful not to overwrite stuff I've configured; that I either leave alone (like the password files, rc.conf, and hosts) or do (for example)
diff /usr/src/etc/group /etc/group
to see if there are changes the system needs that I didn't create.
Then, /sbin/reboot; that's all.
You might, of course, run into some problems I haven't run into; this was a lightly configured 3.4-STABLE that wasn't doing much. But basically it should work.
NOTES
Upgrading a 3.4 to 4.0-STABLE (running under vmware on NT, thus an ide
dangerously dedicated drive emulation on a scsi hard disk), I found I had
to follow the /usr/src/UPDATING instructions quite carefully.
This is how it seemed to go:
cvsup sources
(I install make.conf in /etc/make.conf at this point and configure it, possibly saving the old make.conf to compare settings. See /usr/src/UPDATING for what NOT to have in there.)
cd /usr/src
make buildworld
cd /usr/src/sys/i386/conf
or cd /sys/i386/conf (since there's a symbolic link available)
cp GENERIC NEWGEN (or whatever name you want for MY_KERNEL_HERE)
edit NEWGEN
save NEWGEN
cd /usr/src
make buildkernel KERNEL=NEWGEN
make installkernel KERNEL=NEWGEN
This approach has a major advantage: it uses all the stuff in /usr/obj
created with "make buildworld"
To boot this kernel you may need to make some new devices in /dev, and to do that you have to:
cd /usr/src/bin/mknod
make install
cd /usr/src/sys/modules
make install
Enough is now installed to create the new devices:
cd /dev
sh MAKEDEV all
make any disk devices you need that haven't been created, e.g., ad0s1a, and so forth. You can leave the old block devices around for a while in case you need to boot an old kernel. You may, at this point, have to adjust /etc/fstab, especially if you have ide drives.
Test if you like (rather than doing the final kernel install) by interrupting the boot process while the kernel is
loading by pressing the spacebar and, at the prompt, typing "unload" and
then "load NEWGEN" and then "boot", without the quotes of course. At
this point userland and the kernel will be out of sync. Booting the new kernel is neccessary to doing the installworld.
The next step is (with the new kernel loaded)
make -DNOINFO installworld
make installworld
The "make installkernel KERNEL=NEWGEN" process puts NEWGEN in / but doesn't move the old kernel out of the way or rename NEWGEN to kernel and lock it down so it can't be accidentally erased or moved. Thus:
chflags noschg /kernel
chflags noschg /NEWGEN
mv /kernel /kernel.old
mv /NEWGEN /kernel
chflags schg /kernel
You might have done this earlier; if so it doesn't have to be repeated.
You still need to merge the new /usr/src/etc with /etc using mergemaster if you like.
I guess a reinstall would have been easier after all :)
Annelise Anderson
andrsn@andrsn.stanford.edu