On Thu, Oct 16, 2003 at 06:37:44AM -0700, Sidney Brooks wrote: | In typical linux fashion the instructions don't work. | The problem is in the following instructions: | cd /etc/rc.d | chmod 755 init.d/* | cd rc3.d | ln -s ../init.d/modules.init 05modules.init | | The third line is obviously suspicious. I tried with | cd /rc3.d and was told that it didn't exist. I then | tried /etc/rc3.d , but it did not work either. I | suspect because of the leading .. .
RedHat uses a funky (un-)organization of /etc. Debian's init system
is simpler. The instructions you read were for RedHat. If you
understand the init system you can translate those details to yours,
but really, you don't need to mess with the init subsystem (at least
on a debian system) to update the kernel. As is common, the random
instructions you find on the web are geared for RedHat and thus
contain some overly complicated and mystic steps without sufficient
explanation of their purpose or effect.
| I am beginning to wonder how anybody ever got CD
| writing to work.
By following the directions :-). (see below for more)
| I had to upgrade my kernel in order to get my usb printer to work.
| Therefore going back to the kernel supplied with the official
| distribution is not an option. I must have printing; I can do most
| of my CD burning with Windows if I must.
One suggestion, to help with your sanity : try a prepackaged kernel
just to get cd writing to work without printing. The benefit of doing
this is the elation and motivation of seeing it work and knowing that
it can be done on your system.
I recommend starting the process over. Clear the slate and throw away
the RedHat-oriented instructions for manually building a kernel.
Install the 'kernel-package' package and read the instructions it
includes. It is _much_ simpler (one command), and produces a .deb of
your kernel. It also makes it easy to tag the package name and
version with a custom string so you can tell each kernel apart and
know which one(s) you have installed and are using.
Install the 'kernel-package' package, the 'fakeroot' package and a
kernel source package, eg kernel-source-2.4.22. Then do the folowing
(make sure you understand what the commands do and why!) :
$ cd /usr/src
$ tar -jxf kernel-source-2.4.22.tar.bz2
$ cd kernel-source-2.4.22
$ VER=1 # increment this each time you rebuild a kernel
$ fakeroot make-kpkg \
--config=xconfig \
--append-to-version=-custom.${VER} \
--revision=custom.${VER} \
kernel_image \
modules_image
$ cd ..
$ su
# dpkg -i kernel-image-2.4.22-custom.${VER}_custom.${VER}_i386.deb
The only remaining detail after this is to update your boot loader
configuration to boot the new kernel. *** I think this is where
you're running into problems. *** I haven't actually used lilo in
years, and when I did it was always off a floppy (at the time lilo
wouldn't boot from my harddisk with my bios). I use grub instead and
find it much simpler to deal with, especially in a multi-OS scenario
like you have.
The boot sequence works basically like this :
POST (Power On, Self Test)
BIOS starts executing
Memory test
BIOS searches for boot loader
[this next sequence is often configurable]
BIOS looks at floppy, no disk present
BIOS looks at cdrom, no disk present,
BIOS looks at hard drive,
loads MBR (first block or two) into the start of memory
BIOS executes a "Jump" instruction so that the CPU continues
execution with whatever the boot loader is
At this point the scenario varies depending on what boot loader you
use and how you have it configured. I recall that lilo (at least in
the past) stored the block list of the kernel image in the MBR so that
it would know where on disk to read blocks from and put them in memory
so that it can pass execution on to the kernel.
If you have not updated that block list in the MBR, and if the blocks
on disk still contain the kernel image that was there when the MBR was
written, then lilo will load that old kernel image, not the new one
you have created elsewhere.
I *think* it would be possible to reconfigure your "main" lilo (on the
MBR) to chainload the lilo you put on a different partition, but I am
not entirely certain.
I would prefer to remove the 'lilo' package and in place of it install
grub (on your production, not testing installation). Install grub on
the MBR and then you're done. All that remains is to ensure that
/boot/grub/menu.lst contains the OS/kernel entries you want. There
are two main reasons I prefer grub over lilo:
1) if you screw up the menu.lst file you can still enter all boot
parameters interactively so that the system boots and you can
correct the menu.lst file for next time
2) installing a kernel or changing parameters means *only*
editing the menu.lst file. You do not reinstall (recreate,
actually) the MBR with the updated parameters.
These are because grub reads the menu.lst from disk as it boots. Any
changes are noticed immediately. Grub also reads the kernel image
directly from disk. Unlike lilo, which reads raw blocks, grub
actually interprets the file system and doesn't care what the
low-level block structure is as long as you supply the correct path.
This should get you going, or close to it, and includes a few two
cents of mine as well.
-D
--
Bugs come in through open windows. Keep Windows shut!
http://dman13.dyndns.org/~dman/
pgp00000.pgp
Description: PGP signature
