Re: [Fwd: using Lilo for different kernel-images boot options.]
Lilo already has the ability to select between a myriad of available
kernels during boot. You just have to add the appropriate config
info for each in /etc/lilo.conf and rerun lilo. For example, from
my workstation's /etc/lilo.conf...
# LILO global section
install=menu # bootloader [text|menu|bmp]
menu-title=" Debian GNU/Linux Rocks! " # custom boot menu title
timeout = 100 # for keyboard input
...<snip>...
# Linux bootable partition config
image = /boot/vmlinuz-2.4.18-grsec-1.9.4 # kernel image
root = /dev/md0
label = linux
read-only
append = "ide=reverse"
image = /boot/vmlinuz-2.4.18-grsec-1.9.4.old # backup kernel image
root = /dev/md0
label = linux.old
read-only
append = "ide=reverse"
You can add as many alternate kernel images as you like. :-)
And by compiling your NIC drivers as modules, you can just load
whatever nic driver module you want once you have booted.
Also, it sound like what you would really like is UML (User Mode
Linux -- http://user-mode-linux.sourceforge.net/). It will let
you run multiple Linux kernel instances in user space on a running
Linux system. Check it out. You'd never even really have to reboot
by using UML. :-) Also, there are deb packages for it. Just
install them and have fun.
Sounds like everything you want is already available (in at
least one way), you just need to build all your own glue to make
it work for your needs. :-)
-- Kyle
Thus Spake Jams [Sat, 07 Jun 2003 14:28:34 -0400]
> Dudest Kyle,
>
> I forgot that you are my favorite (kernel) hack of all, and
> as such an interwined need to cc you on such dribblings....
>
>
> James
>
> -------- Original Message --------
> Subject: using Lilo for different kernel-images boot options.
> Resent-Date: Sat, 07 Jun 2003 11:10:39 -0500 (CDT)
> Resent-From: debian-arm@lists.debian.org
> Date: Sat, 07 Jun 2003 11:56:00 -0400
> From: Jams <wireless@tampabay.rr.com>
> To: Philip Blundell <pb@nexus.co.uk>
> CC: debian-arm@lists.debian.org
> References:
> <ddc739e84b.stefan@coawu01.mail.uni-tuebingen.de><20030424115901.A1745@kei.n
> etwinder.org><27b03ee84b.stefan@coawu01.mail.uni-tuebingen.de><2003042412262
> 3.A1831@kei.netwinder.org><[🔎] 3EE1966C.9070502@charter.net><2a48b7fe4b.peter@ch
> ocky.org><[🔎] 3EE1B50B.1000609@charter.net><20030607105802.3f0cb9a5.jmpbox@etsin
> .upm.es><[🔎] 274dcffe4b.peter@chocky.org><1054990469.548.7.camel@kc.cam.armlinux
> .org>
>
> Hello everyone,
>
> Maybe a tool exists, or it's so simple, that I have missed it, but,
> why does Lilo not 'sense' multiple boot images, and serve them
> up as options, just like it does with different Operating systems?
>
> That would make it much easier to build/download, test and
> auto-discover different kernels with only a reboot cycle, in a
> semi-auto-managed tool? Integrating in a gui/web approach to
> kernel building and maintaining, including sources would be
> necessary.
>
> Does this exist already?
>
> The Laptop installation options on Linux now give multiple
> (ethernet) setup options during the boot sequence. Maybe a
> 'matrix' of kernels and ethernet options could be combined,
> and managed via LILO, for both the environment (ethernet) and
> the kernel image choices, during the boot sequence?
>
> Where I really see this being nice, is for those persons with
> multiple 'generic' and other forms of kernels testing
> and maintaining a variety of processors in a singular or
> multiple microprocessor family, such as Arm, x86, ppc, etc.
> Pushing the images and the builds via tftp(manually) or
> something like CFengine(automated) would afford hobbiest, with
> limited chronological resources, the resources to collect
> and deploy all sorts of embedded linux boards for experimentation,
> hopefully with a wider community. The really sharp folks could
> introduces hack(that could be readily compiled and tested) or
> kernels (for newbies to download and test) in a very easy
> fashion. Developers could have ready labs to test and veryfy
> code, modules, kernels, security vulnerabilities etc etc.
>
> This approach would also help those who aspire to know more
> about the internal kernel workings, to begin to learn how to
> distinguish those sources (files and modules) that are essential,
> versus those sources (files and modules) that creat enhancements
> to the minimum kernel (RTOS) of a given embedded board.
>
> It would also allow for statistical gathering of kernel performance
> data, so the developers could distinguish between platform(environment)
> issues, pure kernel-code issues, application issues and hybrid issues.
>
> Any ideas on how to shape and influence such a scheme, are most
> welcome. My guess is something already exist, that i'm
> unaware of.
>
>
> James
>
>
--
Kyle Amon email: amonk@gnutec.com
url: http://www.gnutec.com/~amonk
KeyID 1024D/4EB96E44
Fingerprint = E9EC 0046 8487 23D7 C91C D757 7B2A 8AE9 4EB9 6E44
"Only wimps use tape backup: real men just upload their important stuff on
FTP, and let the rest of the world mirror it."
-- Linus Torvalds (about his failing hard drive)
This email Copyright 2002 by Kyle Amon, Inc., a Florida corporation,
6002 Palm Shadow Way, Suite 1218, Tampa, FL 33647: (813) 979-1311
amonk@gnutec.com http://www.gnutec.com/~amonk. All rights reserved.
Reply to: