Re: Re. CD writer
Actually the instructions that I followed to build the
kernel came from "Custom Kernel Compiling in Debian
2.2" by Jeepsta. I am reasonably sure that I did this
correctly because when I do dpkg -l, I find
kernel-image-2 Custom.2, my second build.
When you speak of updating the block image in the
kernel, I assume that you mean changing lilo.conf
followed by the command lilo. I have done this.
If I understand you correctly, you have no further
suggestions that involve working with lilo. Instead
you recommend switching to grub, a program that I have
not used, but am willing to try.
What concerns me is that in the past, I have had
trouble getting rid of lilo in the MBR. I was able to
get rid of it when it was installed by older versions
of Mandrake by using the Windows recovery console.
However this did not work with the version of lilo
installed by Mandrake 8.0.It also caused troubles with
other partitions. Ultimately, I found a program that
wiped by computer clean and went through the laborious
and lengthy process of restoring my computer. Although
I had backed up most things, I could not back up
programs that insisted on residing on the C drive (I
have separate data and program drives for Windows to
protect myself from the inevitable Windows crashes.)
>From that time on, I refuse to have anything to do
with Mandrake, which insists on installing its version
of lilo.It does not allow the usual skip lilo followed
by creation of a boot floppy.
All this leads to the question, will lilo -q
completely clean out the MBR and allow me to try grub
without risking my past troubles? The grub package is
not now installed on my computer, but if it is on the
installation disks I know how to install it.
Am I correct that /boot/grub/menu.1st plays the same
role as lilo.conf? And that there is a command
equivalent to lilo, maybe grub? Can grub be erased
easily if things go wrong? I do not want to mess up my
entire computer in an effort to gain CD writing.
sidney
--- Derrick 'dman' Hudson <dman@dman13.dyndns.org>
wrote:
> 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/
>
> ATTACHMENT part 2 application/pgp-signature
__________________________________
Do you Yahoo!?
The New Yahoo! Shopping - with improved product search
http://shopping.yahoo.com
Reply to: