Hi all,

I finally got around to installing the new hard drive in my laptop and installing Slackware 12 on it. So far, I've got just two questions.

First, did I change kernels correctly? -- I've read here, and in the readmes the recommendation to use the generic SMP kernel for day-to-day operations. I did a full installation and the default kernel is the huge smp kernel. So, I went to the boot directory and changed the System.map, bzImage, and config symbolic links to link to the corresponding generic SMP files. The laptop boots correctly and everything seems to work, but is there anything else I need to do?

Second, why would I need to make an initrd? The ANNOUNCE.12_0 file states:

But I'm using the generic kernel and haven't made an initrd yet. Why is it necessary? Aren't modules loaded with rc.M?

Thanks,

-Drew

You can't load modules from rc.M until you can mount the root filesystem and read what's in rc.M and /lib/modules. That's what initrd is for. It allows you to load the basic modules for mounting the root filesystem at boot time, like the module for the filesystem you are using for root and the hard drive controller for the hard drive containing your root filesystem. It's basically to get around the catch-22 of you need the modules stored in root to mount root.

So if I can boot without the initrd, then I can assume that the root file system is mounting just fine without it?

I've got my hard drive in four partitions with one formatted as swap and the other three as JFS. I think the JFS support is in the kernel, so I shouldn't need the initrd if I'm understanding things correctly.

Of course, I could be confused...

-Drew

No, you don't need initrd if you have fs support in the kernel.

If you are using the generic kernel and everything is booting OK, then obviously everything you need to mount your root filesystem is compiled directly into that kernel as opposed to being compiled as loadable modules. It really just depends on how the slackware developers compiled that kernel. If you get a kernel panic, then you need an initrd with JFS support and possibly other modules.

What file system are you running? Have you redone lilo? I would be very suspicious that you are actually still running the huge kernel. I am pretty sure that Pat's generic kernel will not run ext3 without an initrd.

This is indeed the case. Lufbery is using JFS, which also requires an initrd when using the generic kernel (since it is built as a module), so I'm having the same suspicions as you about he/she still running the huge kernel.

Hi folks,

I'm a guy, by the way.

As Nylex said, I'm using JFS, and I'm pretty sure I'm using the generic SMP kernel. But, I'm not sure.

So, I changed the links for to point to the generic SMP kernel. I reran the Lilo configuration, but I'm not sure I did it properly. I think I need to do a little more reading on Lilo.

Otherwise, I'll need to make the initrd. Do I do that first and then switch Lilo to it?

Regards,

-Drew

Are you sure you don't mean "vmlinuz" when you said "bzImage"? This is my LILO config (the important bit) for my system running the generic SMP kernel:

Note that I did not change the /boot/vmlinuz symlink to point to /boot/vmlinuz-generic-smp-2.6.21.5-smp, hence why my image line is not just "image = /boot/vmlinuz". Edit: I also manually edited my config file.

Show us what yours looks like.

I guess that there is a command which tells you what kernel you are running; I don't know what it is :-)

You need to be careful not to burn your bridges. When you try a different kernel it makes sense to leave the option of booting the old kernel. So rather than change symlinks I prefer to add a new option in lilo.conf to give the choice of the old and new kernel. If all goes well you can delete the old option.

Nylex,

You're right, I meant vmlinuz.

Arubin,

That's great advice! I'll be back to post my lilo.conf tomorrow. I really like the idea of leaving the option to boot to the huge kernel.

Regards, and thanks for the help.

-Drew

If you want to know what kernel you are running then open a console and run:

$ uname -a

And I agree with the others; I specifically remember having to make an initrd when using reiserfs for my root partition and the 2.6 kernel in slack 11. I had to include both reiserfs and the module for my sata controller in that initrd. Given this specific warning:

it doesn't look like much has changed.

I don't think "uname -a" helps much (which is probably why it hasn't been suggested before). For example, on my system, with the generic SMP kernel, I get

Linux rigel 2.6.21.5-smp #1 SMP Tue Jun 19 14:52:25 CDT 2007 i686 Mobile Intel(R) Celeron(R) CPU 2.20GHz GenuineIntel GNU/Linux,

which doesn't tell me whether I'm using the huge or the generic kernel, only that it's SMP. I'm not sure what the output would be like for the huge kernel!

uname -v ?