Upgraded Kernel, Kernel Panic, Can't read root file system.
 

I found out that this means I need to use mkinitrd to make a initrd.gz, but I can't access the partition. I tried booting the gparted live cd, chrooted into my partition (/dev/sda3) and used but it gave an error saying it couldn't find /proc/partitions, which makes sense since I need to boot into the file system for there to be anything in the proc file system.
Any help would be appreciated. I might be on the wrong track alltogether.

boot into your partition using your slackware install cd.
there's a command listed to do so above the bootprompt

I feel like I'm typing this very frequently as of late, but here goes. As janhe said, you should be able to boot into your system using the kernel on the Slackware 12.0 install CD/DVD. Enter "hugesmp.s root=/dev/sda3 rdinit= ro" at the "boot:" prompt and you should be good to go.

Ok, thanks, I can get into my PC now. I used mkinitrd, but now I get a new error-
I'm going to recompile the kernel, I'm currently trying to run 2.6.25

Hello everyone. I'm experiencing the same problem.
I can't make a valid initrd.gz for slackware's new 2.6.24.4 kernel.
But the original 2.6.21.5 kernel works fine with an initrd.gz made by the same command(except for the kernel version):
This is generate by Alien's script I try to look into the problem by adding some print function to busybox's mount.c . It shows that the errno is set to ENXIO by mount(2) function.
I'v no idea what's problem.I need help.
Thank you very much.

Romanus81, since you compiled a custom kernel anyway, it's probably best just to compile the filesystem of your root partition into the kernel instead of as a module. Aside from that, are you sure your mkinitrd command is correct? Does a /lib/modules/2.6.25 directory exist?

unamed_user, your mkinitrd command is incorrect. It should be
or something like that. The "2.6.21.5" value means that the modules should be loaded from /lib/modules/2.6.21.5. However, since you're trying to run a 2.6.24.4 kernel, there's a mismatch between the kernel version and the module versions. A value of "2.6.24.4" tries to load modules from /lib/modules/2.6.24.4 (which hopefully exists). If /lib/modules/2.6.24.4 doesn't exist, you installed your kernel incorrectly -- OR -- you're trying to use an SMP kernel and it should be 2.6.24.4-smp instead (THAT directory [/lib/modules/2.6.24.4-smp] should therefore exist). If you use the smp kernel, make sure you're pointing to /lib/modules/2.6.24.4-smp (or whatever it's called in the 2.6.24.4 kernel) and not the non-smp kernel (and vice versa).

[edit]I think Alien Bob's script would produce the correct command if you instead booted into the huge-smp-2.6.24.4-smp or huge-2.6.24.4 kernel and THEN ran the command, and then switched to the generic kernel, but you can just as easily correct it yourself[/edit]

I said initrd.gz is made by the same command(except for the kernel version):)

I meant that the kernel version number are different.
I'm sure the kernel modules are loaded correctly.
But I'm really use an smp kernel and I fogot to type the "smp" into the post above. Sorry for that.
I use the command to generate initrd.gz
Still thank you for the rely.

Sorry, I have trouble reading sometimes (no, not really, I just wasn't paying attention). It's even nicely hilighted in red too. I'm running on a few hours sleep after studying for an exam, so I'm not really awake...:(

Are you using the new mkinitrd package included in -current, or are you using the default Slackware 12.0 mkinitrd package?

I am new on Slack but I had the same problem and after weeks (made up of sporadic handful of free time hours) I managed to solve it. I admit that I had to look up on the Internet for hints and I still did not manage to understand why and how it works.

Basically I suspect that the new kernel is not detecting well your SATA hard disk. In my case I was lucky that I booting from GRUB from the RHEL partition. If you are booting from LILO, I cannot help much except that you might try to symlink /dev/sda to /dev/hda. Unlike GRUB, with LILO you need to run lilo after changes to /etc/lilo.conf.

In my case , I changed all references to /dev/sdax to /dev/hdax in GRUB.
I did the same in /etc/fstab, but be careful as if it does not work....

I can give more details if you think that this is helpful, but I am short of time.

Another hint would be to download the .config from the Slackware FTP server. Initrd was not need in my case. Also if things are really bad you might consider carrying out a fresh Slack installation. It takes less time than a Kernel compile :-).

Chris

It's OK.:)

Originally I use mkinitrd-1.1.2-i486-3 or make initrd.gz manually. Then I try the mkinitrd-1.3.2-i486-2. But the result is the same.
I think it is not the mkinitrd's problem. Although mkinitrd have some flaws(or bugs), I still can avoid the problem by making initrd.gz manually.
BTW, Do you know how to report those flaws?

ENXIO error code seems to indicate something. But I'm not very clear. I guess I missed some modules.
When I run in 2.6.21.5-smp, lsmod tells me that it use ata_generic for my SATA hard disk. But I did include this module in the initrd.gz for 2.6.24.4-smp. I'm confused.

If you report those mkinitrd flaws here, I am sure someone will listen.

Eric

I think T3slider makes a good point, why do you need to create initrd at all?
I mean, you know your hardware, you know what modules you need, and you always need them (or it's like "nah, I don't need any sound this time, let's boot without alsa"?), why not compile them all into kernel?

But then, if you have to create it, you can at least take look inside...
You'll see a contents of /dev folder on your initrd, there has to be something like this:
These are 'special files' - device nodes, which can be (and probably were) created by 'mknod' command. '8, X'==='major, minor device numbers'.
According to docs each sd* device have major==8 and it can have up to 16 minor numbers (one for each kernel-recognized partition), so /dev/sda has major==8 and minor==0..15, /dev/sdb: major==8 and minor==16..31, etc.
That basically means that /dev/sda9 got to have '8, 8' numbers. If they're exactly like that on initrd then I guess it's gotta be some kernel issue, so its FS module refuses to mount device with 8+ minor, giving you "The major number of the block device source is out of range." error.

unamed_user:
I've actually never seen an HDD with more than seven partitions: most have three primary partitions and the fourth is extended, hosting up to four logical partitions, never thought it's even possible (or reasonable) to have more :)
So I wonder how, and why did you ended up with 9+ partitions? Are you sure there is actually nine of them?

Romanus81:
You can check why your initrd cannot mount root (/dev/sda3). Check that device node exists in /dev on initrd (like shown above) and that the right kernel module actually there.
If they are, you can put some program like strace to initrd and edit init script there (you can easily locate it by looking into your grub/lilo conf - its probably passed thru 'init=X' variable to kernel) to replace 'mount $ROOT /mnt' with '/bin/strace <somepath?>/mount $ROOT /mnt' ($ROOT can be any var or plain '/dev/sda3' and '/bin/strace' is path where you've put strace on your initrd).

I'm very glad to report it here, But I want to solve the initrd problem first.

The author of the shell script mkinitrd assumes that it's running in an environment with GNU coreutils installed. But actually the installation environment only provides busybox's utils. Some of the command's options can't be recognised by the busybox's utils. For example option --parents in cp. Without an initrd.gz I can't boot into the normal system which has GNU coreutils. The $PATH contains installed system's /bin directory, but busybox's will be choosen to invoke first.

This flaw brings some of the initrd problems.
I think mkinitrd should be modified to be compatible with busybox.

That's all. Thanks.

FraGGod:
I use Slackware's precompiled kernel. And don't want to compile my own kernel this time, because options in "make xconfig" is difficult to determine.

My initrd is a "cpio-initrd" and sda* are all in /dev. But the script mkinitrd cp those sda* from the real root's /dev rather than mknod them. Is this the problem?

ENXIO means "The major number of the block device source is out of range." It is not minor number out of range. And minor number can be 0 to 15. I only got 10 partitions(Yes it is!), so minor number can't be out of range. And ENXIO is about major number.

Thanks

Indeed, it seems I have some trouble reading the plain facts, too.