Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230
coolen wrote:I just want to know, before I go on, how the process differs from here if I'm using Lilo rather than Grub. Will it still add itself automatically? How would I add the initrd?
You can edit /etc/kernel-img.conf to automatically do a lot of stuff, including writing to lilo.
I use grub, but I think if you add the line,
do_bootloader = yes
the configuration file will write to lilo.
As long as it is also declared in the kpkg command, initrd can be automagically generated by adding a line like:
which will tell the script to generate initrd in order of preference using yaird, then initramfs if yaird is not available, then plain vanilla initrd, if neither yaird nor initramfs are available.
How do i start without a default kernel config? When I issue make menuinstall I noticed that almost everything has modules and really would like to start from scratch.
HXC wrote:How do i start without a default kernel config? When I issue make menuinstall I noticed that almost everything has modules and really would like to start from scratch.
pelopidas:/usr/src# dpkg -i kernel-image-2.6.19_10.00.Custom_i386.deb
Selecting previously deselected package kernel-image-2.6.19.
(Reading database ... 97395 files and directories currently installed.)
Unpacking kernel-image-2.6.19 (from kernel-image-2.6.19_10.00.Custom_i3 86.deb) ...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "el_GR:el:en_GB:en",
LC_ALL = (unset),
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
Setting up kernel-image-2.6.19 (10.00.Custom) ...
perl: warning: Setting locale failed.
perl: warning: Please check that your locale settings:
LANGUAGE = "el_GR:el:en_GB:en",
LC_ALL = (unset),
LANG = "en_US"
are supported and installed on your system.
perl: warning: Falling back to the standard locale ("C").
A new kernel image has been installed, and usually that means
that some action has to be taken to make sure that the new
kernel image is used next time the machine boots. Usually,
this entails running a ``bootloader'' like SILO, loadlin, LILO,
ELILO, QUIK, VMELILO, ZIPL, or booting from a floppy. (Some
boot loader, like grub, for example, do not need to be run on
each new image install, so please ignore this if you are using
such a boot loader).
A new kernel image has been installed at /boot/vmlinuz-2.6.19
(Size: 1170kB)
Symbolic links, unless otherwise specified, can be found in /
LILO sets up your system to boot Linux directly from your hard
disk, without the need for booting from a boot floppy.
WARNING
If you are keeping another operating system or another version
of Linux on a separate disk partition, you should not have LILO
install a boot block now. Wait until you read the LILO documentation.
That is because installing a boot block now might make the other
system un-bootable. If you only want to run this version of Linux,
go ahead and install the boot block here. If it does not work, you
can still boot this system from a boot floppy.
You already have a LILO configuration in /etc/lilo.conf
Install a boot block using the existing /etc/lilo.conf? [Yes] yes
Testing lilo.conf ...
An error occurred while running lilo in test mode, a log is
available in /var/log/lilo_log.28601. Please edit /etc/lilo.conf
manually and re-run lilo, or make other arrangements to boot
your machine.
Please hit return to continue
pelopidas:/usr/src# nano /var/log/lilo_log.28601
Warning: '/proc/partitions' does not match '/dev' directory structure.
Name change: '/dev/ide/host0/bus0/target1/lun0/disc' -> '/dev/hdb'
Fatal: open /initrd.img: No such file or directory
This is possibly the very worst way to upgrade your system.
I seriously doubt you'll be able to boot sarge using the latest kernel, because too many things have changed.
Scan the forum for a thread on upgrading from sarge to etch, as in this example, or post on that thread for additional help, or start a new thread in that section.
In the past it was common to build kernels in /usr/src but this is not recommended any longer and it isn't necessary (and hasn't been necessary for some time).
A quote from the 2.6.19 README :
"Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header files.
They should match the library, and not get messed up by whatever the kernel-du-jour happens to be.
mzilikazi wrote:In the past it was common to build kernels in /usr/src but this is not recommended any longer and it isn't necessary (and hasn't been necessary for some time).
A quote from the 2.6.19 README :
"Do NOT use the /usr/src/linux area! This area has a (usually incomplete) set of kernel headers that are used by the library header files.
They should match the library, and not get messed up by whatever the kernel-du-jour happens to be.
You should instead use your ~ for example.
What exactly does that mean? I unpack kernels to /usr/src, and symlink them to /usr/src/linux, so how is /usr/src/linux incomplete? Could you please elaborate
Eagles may soar, but weasels don't get sucked into jet engines...
I don't understand. /usr/src/ is initially empty on a Debian system so what's the difference in using it or using a different place? Does not make sense... I think...
Lavene wrote:I don't understand. /usr/src/ is initially empty on a Debian system so what's the difference in using it or using a different place? Does not make sense... I think...
:?
Tina
Initially empty yes but it doesn't stay that way.
If you build as user then it can be done in ~ Keep in mind that I always build w/ source from kernel.org and never the debian sources.
Why? Well I like the latest greatest. :)
Personally is have a dir that is used just for kernels called (suprisingly enough)
~/Downloads/KERNEL
Now when I installed the kernel source for my custom kernel (dpkg -i linux-source-2.6.19-rt1-k8) the symlink is made automatically:
So it isn't even necessary to make the symlink yourself.
Please note that I have not heard of any kittens dying because someone compiled a kernel in /usr/src. Also, I did not write the README for the 2.6.19 kernel, that comes from the kernel devs. Don't shot the messenger! :)
Thanks for this very helpful thread! Here's a question not answered here or anyplace else that I can find:
Using grub, when is it necessary to create an initrd with yaird? Is this a function of the hardware -- drive controllers? Something else?
I've created a custom 2.6.19.1 kernel (with RAID1 compiled in) in a new sarge install, and it boots the machine on the single disk just fine without an initrd. However, I'm also trying to set up RAID1 (mostly following this: http://www.debian-administration.org/us ... e/weblog/4) on this new machine, and when I try to boot into the new array, I get a kernel panic. If I boot into the pre-raid kernel, I can see that the md devices are created (/proc/mdstat and mount) but I can't add in the initial disk partitions to the arrays (via mdadm) because the first disk is "busy".
This is on a new Dell (SC440) and it's possible that there is something funky with the SATA drive controllers (Intel IHC7), though it seems as if this should work.
So: is an initrd necessary to boot a RAID1 system when the same kernel on the same hardware boots fine to a single disk? If not, I'll take this conundrum to a RAID thread.
bubbert wrote:
So: is an initrd necessary to boot a RAID1 system when the same kernel on the same hardware boots fine to a single disk? If not, I'll take this conundrum to a RAID thread.
To answer my own post, it turns out that an initrd is necessary, at least on this box running a 2.6.19.1 kernel. The various kernel panics and other problems encountered when trying to boot into the RAID1 array went away by creating an initrd image and including it in the grub menu.lst. What worked with this kernel and Sarge was mkinitramfs, and the initrd image needed to be rebuilt after synching the two drives into the RAID1 array.
Lavene wrote:
Compile and install the new kernel
Now you should see a lot of text flickering by on your screen. This is the compile in progress. Please note that compiling the kernel takes quite some time depending on your system (approx 30-60 minutes give or take) so be patient. And if everything goes well you are rewarded with a nice .deb file in your /usr/src/
I compiled and installed a 2.6.19.2 kernel from kernel.org on my PII machine clocking at 350mHz. Has anyone had experience in doing so on an old machine similar to mine? It certainly took much longer to compile than the 60 minutes. In fact, it took something like 3 to 4 hours (I didn't check the time) to compile alone, mind you I had to go through the long configuration checklist, a lot of the stuffs left untouched must have resulted in a lot of modules being compiled. Maybe the next time after I get a better understanding of some of these modules I might be able to tweak the kernel further.
Anyway, the 2.6.19.2 kernel worked flawless.
Maurice Green on Usain Bolt's 9.58: "The Earth stopped for a second, and he went to Mars."
garrincha wrote:
I compiled and installed a 2.6.19.2 kernel from kernel.org on my PII machine clocking at 350mHz. Has anyone had experience in doing so on an old machine similar to mine? It certainly took much longer to compile than the 60 minutes. In fact, it took something like 3 to 4 hours (I didn't check the time) to compile alone, mind you I had to go through the long configuration checklist, a lot of the stuffs left untouched must have resulted in a lot of modules being compiled. Maybe the next time after I get a better understanding of some of these modules I might be able to tweak the kernel further.
Anyway, the 2.6.19.2 kernel worked flawless.
That's normal. Building a kernel is very taxing on system resources. If you have a faster machine there is no reason you cannot build a kernel for your 350 on the fast machine, then just move your debs to the 350 and dpkg -i as per usual.
The best way to understand the multitude of options in your .config is to just read through it all. Rebuild a few times, each time removing more modules etc. that you feel are unnecessary. Be prepared for the compilation to break or for a kernel that will not boot. Of course you will always have your old kernel ready to boot if a new one fails.
mzilikazi wrote:
That's normal. Building a kernel is very taxing on system resources. If you have a faster machine there is no reason you cannot build a kernel for your 350 on the fast machine, then just move your debs to the 350 and dpkg -i as per usual.
The best way to understand the multitude of options in your .config is to just read through it all. Rebuild a few times, each time removing more modules etc. that you feel are unnecessary. Be prepared for the compilation to break or for a kernel that will not boot. Of course you will always have your old kernel ready to boot if a new one fails.
If you are successful in building a slim & trim kernel make sure to keep a copy of your .config someplace safe.
Yeah, I just belatedly realised that the processor on my PII machine will be too slow for thing like kernel compilation. Should have thought of it before - I did a little programming back in the early 1990s, so I understand that compiling took a lot of PC system resources.
Maurice Green on Usain Bolt's 9.58: "The Earth stopped for a second, and he went to Mars."
I just recompiled a kernel, and I have two questions.
My Debian install came with the 2.6.18-3-686 Kernel, so I was able to just install ipw3945 support from the repos. How do I do something like that with a new kernel? I know this is kind of off-topic, but I have to be able to access the internet from that kernel eventually.
Also, if I'm unable to do that, how can I remove a compiled kernel (Completely, not just edit menu.lst) so that I can recompile another one with ipw3945 support?
my first time updating the kernel and it worked first time! 
