Re: which kernel and initrd for rescue boot purposes?

[Dan]

On Mon, 15 Jan 2007 15:43:13 +0100
adrian15 <address@hidden> wrote:

> Hello,
> 
> I need some help of you if you do not mind.

hi, I signed up on this list to get help with pxegrub but the help
never came.  I never actually asked for it because this list's mail
volume is quite low.  In fact, this is the first message from the list
I've gotten since I signed up a while ago.  I guess it remains to be
seen whether any experts read the list.  For the time being, I
will do the best I can with my limited knowledge.

> Do you remember ever having boot your system like this:
> 
> boot: knoppix root=/dev/hda2
> 
> or
> 
> boot: linux root=/dev/hda2 ro
> 
> from a knoppix or a redhat installation cd?
sure, or from a gentoo, or I think debian, or just about any bootable
linux CD.  That's the isolinux prompt, I believe.  
> I want to add a kernel and an initrd so that I can add a similar
> feature to Super Grub Disk ( http://supergrub.forjamari.linex.org )
> and I am bit lost so I will ask you some questions.
> 
> 1) Can an initrd be used with various kernels or does the initrd have
> to be compulsory of the same version as the kernel?
As long as the ramdisk code in the various kernels is the same in its
dealings with the ramdisk (such as, if they were the same kernel
version), the same initrd should be able to be shared.  However, if the
kernels are different, they may well need different things in their
initrd.  

> 2) When the root fs differs from ext3, such as reiserfs you need
> another initrd, isn't ? you need another initrd that has reiserfs
> support builtin? Am I right?  
Kind of.  You need support for the root filesystem type in the kernel
before the root filesystem is mounted.  If it's reiserfs, you need the
reiserfs module; if it's xfs, you need the xfs module -- and so on.  An
alternative is building the driver for these filesystems into the
kernel, so that it is available immediately upon boot.  

> 3) Which is the kernel/initrd/distro that you have used the most and
> it is known to be least problematic?
Vanilla kernels are probably the most likely to work, although frankly
I doubt you'll have a problem with any kernel sources.  I myself use
Gentoo pretty much exclusively and also use the gentoo kernel sources
(lightly modified vanilla sources) and recommend Gentoo only for the
patient.  It is quite problematic for users who aren't comfortable at
the command line.  On the other hand, it's probably one of the easiest
distros to warp to fit your needs.  Gentoo should really be called a
meta-distribution, to be accurate.  Its structure makes it ideal for
the building of a distribution, compiling that distribution's packages
from sources, and even producing .bz2 files from the binaries for easy
distribution.  More appropriate to your case, gentoo offers complete
control over the system building process, and is quite flexible.  Other
distributions are much less flexible; my next favorite is debian
because ... it's neat.  I currently don't have it installed anywhere ;-)

> 4) If I have a patched a kernel for being able to boot nvidia and my 
> xorg.conf is configured with nvidia drivers (I am talking about
> nvidia propietary drivers) would I be able to boot with a normal
> kernel from a cd or does it have be it also compulsory patched with
> some kind of link to nvidia drivers?
The proprietary nvidia drivers cannot be compiled into the kernel.
They may only be obtained as kernel modules -- like dynamic link
libraries in Windoze.  They are loaded at runtime.  My guess is
the same module probably works with any kernel of the correct version
(regardless of how it's configured, that is, besides dependancies of
nvidia itself.  ) and on the right architecture.  

> And if it is patched? Is it non-gpl the kernel itself?
patches, at least the ones distributed for use with the patch program
(evidently written by larry wall, creator of perl), modifies the source
of the kernel to patch it before it is compiled.  Therefore, although
these patches don't necessarily only include GPL'd code, they certainly
don't include closed source code, as they're being distributed in
sources, and so won't 'taint' the kernel like the nvidia driver does.  
 
> Thank you for all your responses.
> adrian15
 I just hope it helps a little.  Best of luck with your recovery cd
thingy!  

  --dan