cvsup bug fix and upgrading to 4.4
The Billionium came and went and few people noticed. But all cvsup mirrors noticed. And so did some cvsup clients. On Sun Sep 9 01:46:40 UTC 2001, the Unix date changed from 999,999,999 to 1,000,000,000. This uncovered a long-standing bug in CVSup. The bug places a heavy load on the servers not to mention the clients. Upgrading is strongly recommended. All versions of CVSup prior to SNAP_16_1d contain a bug which affects the timestamps of files which have been modified on or after Sun Sep 9 01:46:40 UTC 2001. If you don’t know that 4.4-RELEASE came out, you’re probably not on the Net much. I upgraded a few boxes recently. Some were 4.2, the rest were 4.3. The first box I upgraded was in New Zealand. It’s actually cvsup.nz.freebsd.org, but it needed to be upgraded in order to install the cvsup bug fix. If you haven’t upgraded your local copy of cvsup, you’ll soon find yourself unable to any cvsup server. This version of cvsupd will reject clients created prior to the bug fix date. You need to be on at least the following versions:
$ cvsup -v
CVSup client, non-GUI version
Copyright 1996-2001 John D. Polstra
Software version: SNAP_16_1d
Protocol version: 16.1
Operating system: FreeBSD4
http://www.polstra.com/projects/freeware/CVSup/
Report problems to cvsup-bugs@polstra.com
$ /usr/local/sbin/cvsupd -v
CVSup server
Copyright 1996-2001 John D. Polstra
Software version: SNAP_16_1e
Protocol version: 17.0
Operating system: FreeBSD4
http://www.polstra.com/projects/freeware/CVSup/
Report problems to cvsup-bugs@polstra.com
Locked out after upgrade…
You might think it odd that I choose to first upgrade a box an ocean and a hemisphere away, but it was the one with the most need. The box was on 4.2 and I was unable to install CVSup from source. The packages were for 4.4. Upgrading seems to be the right thing to do. Everything went well. The box came back after I installed the new kernel. And then again after I intalled the new world. Happily, everything about the upgrade went smoothly. That was good. My next upgrade (of the dual XEON box) was not so successful. After the reboot, the box came back. But I was locked out. I could not get in via ssh. Luckily, this box was only two feet away from me. Granted, the handbook does recommend single user mode…. I suspected the problem was related to my firewall, IP Filter. I don’t blame ipf. I blame me. The problem was that ipf was non-functional; it wouldn’t load the rules. I suspect this was because I was using a 4.4 kernel with 4.3 world. If I tried to load the rules, something like this was the result:
1:ioctl(add/insert rule): No such process
This is not a good thing….
Fixing the lock out
Not being able to load your firewall rules is a big deal. I logged into the console and modified my kernel configuration file to comment out this option:
options IPFILTER_DEFAULT_BLOCK
Fast box/slow box
I was able to upgrade my firewall by mounting the/usr/obj/ and /usr/src/
directories from the XEON box via NFS. I wrote about that process back in February.
I still think it’s the fastest way to upgrade multiple boxes. Build once; install many.
I’ve been trying on an off for a few days to install 4.4 from an iso, web, cdrom, etc.. all with failures relating to coping the kernel file over. So, I’m installing 4.3 and then will upgrade from there. Anyone else having these issues with either a cdrom, the iso image (local anon ftp), or from the freebsd servers?
Perhaps if you gave more detail on the problem. And perhaps if you asked in the phorum rather than the article comments.
Are you sure its not just the immutable flag ?
root # ls -lo /kernel
-r-xr-xr-x 1 root wheel schg 4135768 Sep 7 16:33 /kernel
^^^^
root # chflags noschg /kernel
And try again.
Another nice problem is when you run vinum. I had a 4.2-STABLE box from early May or so with /home on a bunch of vinum partitions over several drives. Installed the 4.4. kernel (via NFS, that’s just so cool 🙂 and rebooted. Well, upon boot vinum was printing a few errors about my home partition (don’t remember the details, but in essence it said that all disks making up home are invalid … ooops!). After some back and forth it turned out that this was also caused by a versioning problem. This time between the userland part of vinum (still 4.2) and the vinum kernel module (4.4.), Fortunately, my /var, /usr and / were on normal partitions. From the console I could do installworld and mergemaster. After another reboot even /home came up fine in a sleek 4.4-RELEASE system.
This is one of the reasons why I’m not going to do any reboots during the upgrade process. Some people have suggsested rebooting after installing a new kernel. But that sometimes gives you an unusable system.
If you’ve got console access to a box, rebooting to or atleast dropping to single mode is a good idea when doing installworld. I have made a computer totally unusable by not installing a new kernel before the installworld, and this was when going from 3.x-S to 4.x-S. I had to get an ISO and do a complete reinstall for that mistake. I’ve also rendered a box unable to do what is was supposed to do by doing installworld while operating. It didn’t take long to fix, but it was annoying sitting there waiting for that old 133MHz to get done so I had ‘Net access again 🙂
I also know of some others who have had to reinstall since they didn’t reboot to new kernel in single mode or atleast dropped to single mode when installing. I can see the difficulties of doing that remotely, but it really sucks when your new 4.x-S bins doesn’t understand anything about the old 3.x-S kernel, making them core dump on SIGSEG. And yes, that probably includes bins like install, make, sh, etc, all which are frequently run when doing installworld. I always reboot to single now 🙂
I did almost the same thing the other day. I also build world and kernel (through make buildkernel KERNCONF=XYZ) and then installed over NFS on my firewall box. Same problem, although I never use kernel option default block for ipfilter. I don’t see any merit in doing so, after all who would use a firewall with no rules.
I.M.H.O. , as indicated in the article the problem has something to do with kernel and world being out of sync. What saved the day is not changing a ipf kernel option but rather merely compiling a new kernel (the old fashioned way, make config, make depend, etc). I realised that when dmesg didn’t work either. The moral: when upgrading world, compile and install a GENERIC kernel first. That one will work, custom kernels might not. Then after installworld and mergemaster install the custom kernel. Yes, I know, this is also the method recommended in the Handbook but we all try to cut corners don’t we 😉
Where exactly the difference lies, I don’t know. I suspect the automated make depend step when using buildkernel. Any comments?
P.S.
Before the upgrade I used a custom rc.ipfilter script to start ipf, ipnat and ipmon from. Here’s a tip when using ipf with the rc.network script (unmodified): The ipmon_flags default to -Ds, (D=run as daemon) setting it to -s only like I did before will keep your shell occupied when booting making it look like the box hangs during boot. Also, by setting ipnat_flags to "> /dev/null" you can get rid of the ugly ipnat output during boot.
Greetings,
Danny
Ahhh, *click*
There will be a difference between the old GENERIC and the new GENERIC……
But in my case, yes, it was the custom kernel which locked me out of the box. Everything else, AFAIK, was functioning correctly.
If you are having troubles installing cvsup by sources you can use the "pkg_add -r cvsup" -command. This will get the latest pre-compiled package for your FreeBSD system and install it.