advice on compiling a new kernel & upgrading to the latest
keramida at ceid.upatras.gr
Mon Jan 15 03:17:17 UTC 2007
On 2007-01-14 15:35, Bill Moran <wmoran at collaborativefusion.com> wrote:
> Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> [copious snippage]
> > > 2. Cd /usr/src/sys/amd64/conf which contains the file MYKERNEL
> > No it doesn't. CVSup will delete the files it doesn't know about, so
> > you should *SAVE a copy* of your favorite kernel config file outside of
> > the source tree and *copy* it into `/usr/src/sys/amd64/conf' after CVSup
> > finishes updates the sources.
> Really? What have I been doing wrong? I've been keeping custom kernel
> configs for years and cvsup has never deleted any of them.
That's what the ``*default delete use-rel-suffix'' option does, AFAIK.
The default supfile examples in `/usr/share/examples/cvsup' have this
option enabled, and cvsup(1) says about it:
delete The presence of this keyword gives cvsup permission to
delete files. If it is missing, no files will be deleted.
The presence of the delete keyword puts cvsup into
so-called exact mode. In exact mode, CVSup does its
best to make the client's files correspond to those on
the server. This includes deleting individual deltas
and symbolic tags from RCS files, as well as deleting
entire files. In exact mode, CVSup verifies every
edited file with a checksum, to ensure that the edits
have produced a file identical to the master copy on
the server. If the checksum test fails for a file,
then CVSup falls back upon transferring the entire
In general, CVSup deletes only files which are known to
the server. Extra files present in the client's tree
are left alone, even in exact mode. More precisely,
CVSup is willing to delete two classes of files:
o Files that were previously created or updated by CVSup
o Checked-out versions of files which are marked as dead on
If the option doesn't work this way, then I stand corrected.
>>> 4.Copy everything under /etc to /root/etc
>> Why? This isn't mentioned in `/usr/src/UPDATING' and it doesn't really
>> help much if you manage to trash your /lib and /usr/lib trees. A better
>> suggestion is to ``make sure you have good level 0 dumps'', as suggested
>> by ``/usr/src/UPDATING''.
> While not mentioned in /usr/src/UPDATING, this is good practice in my
> opinion. mergemaster can be a tedious task, and making a local backup
> of /etc has allowed me to undo some careless keystrokes a number of times.
> I don't disagree with the dump advice, but an additional copy of /etc
> around doesn't hurt anything and occasionally makes fixing a mistake
> much faster an easier.
Heh, true :)
More information about the freebsd-questions