kernel patch script AND Re: More Debian v1.2 things...
On Mon, 21 Oct 1996, Richard Kaszeta wrote:
> > Also, the article mentioned something about lilo not automaticaly being
> > installed, and that the reviewer had to run lilo manually to make sure it
> > came up at boot time, I don't remember this being that case, but maybe it
> > was an option that you had to make sure to say yes to.
>
> I remember when I installed 'buzz' on our (many) machines, I had to
> forcibly run lilo after installing the base to get the machines to
> successfuly boot past "LI". When I rebuilt the machine recently with
> the disks in rex, this didn't happen. Perhaps this problem has gone
> away. Input anyone?
The debian (rex/unstable) machines I built last week couldn't boot off the
hard disk initially - i had to boot from the floppy with "root=/dev/hda1"
and then run lilo.
I used the 960714 install disks.
> >The article also wrote "Also, the modules do not load into the kernel."
>
> I recall having problems with modules, but probably because I like to
> use kerneld (and had to 'depmod -a' first, of course)
I think the article is referring to the modules which fail to load due
to symbol table incompatibilities - e.g. nfs module. I haven't read the
article so i can't be sure of that.
> > Also, the article mentioned that building a kernel the "Debian way"
> > is very confusing,
>
> Well, using the most recent kernel-package package, I found both
> methods to be nearly identical. To make one the debian way, I
>
> make xconfig
> make-kpkg --revision 3.1 kernel_image
>
> and let 'er rip, yielding an image .deb file to install on all my
> machines. Haven't had a problem yet.
i suppose it's a matter of personal preference. I used to use my own
makelinux script to build a new kernel image and automatically add it
to lilo.conf - now i use the debian method. My scripts were a little
more flexible but being able to use dpkg to install and remove kernel
versions is great.
I'm still using "./debian.rules kernel_image" - i tried make-kpkg when
it was first released, couldn't get it to do anything useful, and went
back to running debian.rules by hand.
i still use my patchlinux script (which is not much more than a wrapper
around "zcat ~ftp/pub/mirrors/linux/kernel/v$1/patch$2.gz | patch -p0").
One of these days i'll get it to automatically patch from current source
version to the latest available patch in one go. (LATER: I did it. See
below if interested)
> > Overall, the article was very positive to debian, even though it
> > listed it as mostly a Hobbyist/Enthusiast's distribution.
>
> Personally, I'd label Debian as 'the best distribution to use with
> a large number of centrally managed machines'. Slackware was near
> impossible. I have yet to see a RedHat ypbind that really works well.
> And although I have my share of dpkg problems (/usr/local stuff
> mostly), Debian gives me good flexibility and a fairly reliable
> system.
yep, agreed.
I recently had to rebuild the web proxy machine at work. It had
originally been FreeBSD 2.1-STABLE (built by someone else), then got
upgraded to 2.1.5. It was a 128MB P100 with lots of disk space. It
wasn't very stable though. The squid process died and auto restarted, on
average, every 3 hours. The whole machine crashed every week or so. Not
the sort of 'stability' which I expect from a unix box.
anyway, last week it crashed badly and totally trashed it's filesystems.
I could have rebuilt it as a BSD box again, but I chose to make it
debian. I had it up and running in about 3 or 4 hours, including
configuration of squid. It's still running now. Hasn't crashed once, and
the SAME squid process is still running...hasn't died once. That proves
to me that debian linux is rock-solid stable even under heavy load
(squid gets about 11000 hits/hour).
best of all, to minimise downtime while i was rebuilding the proxy
server i used linux' ip_alias module to make my workstation act as a
temporary squid box. From our customer's point of view downtime was
under 10 minutes from the time i learnt of the problem.
Craig
--- cut here --- /usr/local/sbin/autopatchlinux --- cut here ---
#! /bin/sh
# NOTE: alpha experimental script. ** USE AT YOUR OWN RISK **
# autopatchlinux.
# Craig Sanders 961023.
# This script is militantly public domain. Do what thou wilt with the
# whole of the source.
#
# automatically patches kernel source code up to latest available version.
# requires: a) linux src dir, b) up-to-date mirror of patches
#
# terminates patching if it finds a .rej file. There are probably lots of
# ways of making the error detection smarter.
SRCDIR="/usr/src"
LINUXDIR="$SRCDIR/linux"
MAKEFILE="$LINUXDIR/Makefile"
PATCHDIR="/home/ftp/pub/mirrors/kernel/"
DATE=`/bin/date +%y%m%d`
PATCHLOG="/usr/src/linux/patchlog.$DATE"
FINDTMP=/tmp/patchfind.$$
function do_patch() {
# $1 Linux kernel series - e.g. 2.0
# $2 patchlevel - e.g. 23
#
# e.g. 'do_patch 2.0 23' applies the patch for Linux 2.0.22 to bring it up
# to v2.0.23
zcat $PATCHDIR/v$1/patch-$1.$2.gz | patch -p0 >$PATCHLOG 2>&1
find $LINUXDIR/ -name "*.rej" > $FINDTMP
if [ -s $FINDTMP ] ; then
cat $FINDTMP
rm -f $FINDTMP
echo "patch failed - see $PATCHLOG for details"
exec false
fi
rm -f $FINDTMP
}
# extract current version number from linux Makefile.
current=`head -3 $MAKEFILE | sed -e 's/..*= //' | \
xargs echo | sed -e 's/ /./g'`
# now parse version, patchlevel, and sublevel using sed. Q&D, ugly and
# inefficient but it works.
v=`echo $current | sed -e 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)/\1/'`
p=`echo $current | sed -e 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)/\2/'`
s=`echo $current | sed -e 's/\([0-9]*\)\.\([0-9]*\)\.\([0-9]*\)/\3/'`
# generate a list of available sublevel patches.
avail=`ls -alrt1 $PATCHDIR/v$v.$p/patch* | \
sed -e 's/\(..*\.\)\([0-9]*\)\(.gz\)/\2/'`
pushd $SRCDIR
for i in $avail ; do
[ $i -gt $s ] && do_patch $v.$p $i
done
popd
--- cut here --- /usr/local/sbin/autopatchlinux --- cut here ---
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com
Reply to: