Kernel recompile doesn't boot, could not mount root

shubb · 09-30-2008, 07:07 PM

I have a standard installation of Slackware 12.1 using the hugesmp kernel. Unfortunately that kernel only supports 4GB of memory, but if you actually have 4GB of memory it only sees 2 for some reason. I'm trying to recompile the kernel with 64GB of memory support.

I used the config file from the hugesmp directory off the CD as a base, and then modified only the memory from 4GB to 64GB of memory. When I compile and boot, I get the following errors on boot.

Code:

List of all partitions:
0340     4194302 hdb driver: ide-cdom
0800    293036104 sda driver: sd
  0001      56196 sda1
  0002    1959930 sda2
  0003          1 sda3
  0005     907866 sda5
  0006   14659201 sda6
  0007   14659201 sda7
  0008  260710621 sda8
No filesystem could mount root, tried: romfs
Kernel panic - not syncing VFS: Unable to mount root fs on unknown-block(0,6)

So then I tried to compile the kernel with the default config and no modifications to see if that would boot. I would expect this to net me the exact same kernel as the system was booting with, but when I do this, the kernel size that gets created is NOT the same size as one that works.

Code:

root@vm1:/usr/src/linux# ls arch/x86/boot/bzImage
-rw-r--r-- 1 root root 4369848 2008-09-30 15:52 arch/x86/boot/bzImage

root@vm1:/usr/src/linux# ls /boot/vmlinuz-huge-smp-2.6.24.5-smp
-rw-r--r-- 1 root root 4369880 2008-04-30 11:42 /boot/vmlinuz-huge-smp-2.6.24.5-smp

Also, the new kernel that should be the same as the working kernel does not boot either. What am I missing?

Jeebizz · 09-30-2008, 07:26 PM

Did you make sure to compile into your kernel the root filesystem? If you compiled it as a module, then you would have had to make an initial ramdisk, or you would have received the same message. Since you are using the original kernel, go back and make sure you have compiled the filesystem you are using for your root partition INTO the kernel, and not as a module, or you will have to make an initrd.

shubb · 09-30-2008, 07:32 PM

I used the config file for the same kernel that I am booting. I would think that this kernel would have all the same things that the hugesmp kernel would have, right?

I double-checked, and my filesystem, ext3, is configured as built-in, and not a module.

Jeebizz · 09-30-2008, 07:52 PM

Hrmm, ok so it isn't that, although I would assumed it was since usually thats the most common reason for this. Ok, I admit now I am a bit stumped as well. Do'h

forum1793 · 09-30-2008, 07:56 PM

I hope this is not too silly of a question but did you copy the bzimage file over to the /boot area and with the same ...huge... file name?

Did you also do lilo or fix for grub to use?

Seems odd that only romfs is tried.

shubb · 09-30-2008, 08:14 PM

I did copy the new kernel into /boot.

Code:

root@vm1:~# ls /boot/vmlinuz*
lrwxrwxrwx 1 root root      29 2008-09-28 09:11 /boot/vmlinuz -> vmlinuz-huge-smp-2.6.24.5-smp
-rw-r--r-- 1 root root 2055544 2008-04-30 12:02 /boot/vmlinuz-generic-2.6.24.5
-rw-r--r-- 1 root root 2167384 2008-04-30 11:19 /boot/vmlinuz-generic-smp-2.6.24.5-smp
-rw-r--r-- 1 root root 4205208 2008-04-30 12:15 /boot/vmlinuz-huge-2.6.24.5
-rw-r--r-- 1 root root 2175000 2008-09-30 13:17 /boot/vmlinuz-huge-2.6.24.5_64G
-rw-r--r-- 1 root root 4369880 2008-04-30 11:42 /boot/vmlinuz-huge-smp-2.6.24.5-smp
-rw-r--r-- 1 root root 4369848 2008-09-30 16:26 /boot/vmlinuz-huge-smp-2.6.24.5-smp_2
lrwxrwxrwx 1 root root      31 2008-09-30 13:35 /boot/vmlinuz2 -> vmlinuz-huge-smp-2.6.24.5-smp_2

And I did edit /etc/lilo.conf and added a new line for the new kernel and re-ran Lilo. I can still boot the original one, but if I select the new kernel from Lilo, it does not boot.

Code:

# Linux bootable partition config begins
image = /boot/vmlinuz
  root = /dev/sda6
  label = Linux
  read-only
image = /boot/vmlinuz2
  root = /dev/sda6
  label = Linux_2
  read-only
# Linux bootable partition config ends

forum1793 · 10-01-2008, 08:39 PM

I don't use lilo and so may not be able to help. One question: what does

Code:

  label = Linux_2

do?

Jeebizz · 10-01-2008, 10:24 PM

Quote:

Originally Posted by forum1793

I don't use lilo and so may not be able to help. One question: what does
Code:

label = Linux_2

do?

'label' Just shows the name of said os if there is a menu. This is useful for dualboot systems, so you can know what you are booting into. It is also useful when you are compiling a new kernel and keep your original kernel just in case something like this happens, and your new kernel doesn't work correctly, you can boot into your original config.

keefaz · 10-02-2008, 04:00 AM

Quote:

Unable to mount root fs on unknown-block(0,6)

Weird, it should be unknown-block(8,6) if I refer to <kernel source dir>/Documentation/devices.txt

Are you sure you're using the same config as your working kernel ?
The best way is to use /proc/config.gz imho
You can do a quick check, take the config of the kernel you compiled and check the difference with the working kernel:

# get config from working kernel
zcat /proc/config.gz > old_config

# get config from the kernel you compiled
cp <kernel source dir>/.config new_config

# see the difference
diff old_config new_config

forum1793 · 10-02-2008, 06:55 AM

Why 8,6? Lilo must be goofy. Grub starts with 0,0. So sda6 would be 0,5.

But since they are telling system root is at sda6, lilo must be choosing 0,6.

Just out of curiosity, why install root at sda6 and not sda1? I've used sda1, sda2, sda3, and sda4. I don't think I've yet installed on extended portion. Suppose it should work.

keefaz · 10-02-2008, 07:12 AM

Quote:

Originally Posted by forum1793

Why 8,6? Lilo must be goofy. Grub starts with 0,0. So sda6 would be 0,5.
But since they are telling system root is at sda6, lilo must be choosing 0,6.

Here we are in VFS context, so first number is major block number, and second number is minor block number
For SCSI devices (sd*) major block number is 8

shubb · 10-02-2008, 01:08 PM

FYI, I got it working. I just ended up making an initrd. I should not have had to do that, since I had ext3 compiled into the kernel, and not as a module, but after making the initrd, it works. However, my ethernet card does not come up, but that's for another thread.

Thanks for the help.

Jeebizz · 10-02-2008, 05:54 PM

It is still strange that you would need to make an initrd just to get / to mount, even IF the FS is compiled into the kernel itself. Now I can't help wondering if you are using a newly downloaded kernel and this might be a bug, since I doubt it would be a stock kernel since I have never run into this problem when recompiling the kernel that comes with Slackware.

Hrmm...

forum1793 · 10-02-2008, 09:09 PM

Quote:

Originally Posted by keefaz

Here we are in VFS context, so first number is major block number, and second number is minor block number
For SCSI devices (sd*) major block number is 8

So all sata is major block 8? Does the first 8 below result from that?

Code:

0800    293036104 sda driver: sd

gmorris · 10-05-2008, 06:18 PM

I wish it were that easy for me. Over the years, I've installed and run different versions of Linux, but for some reason I cannot get Slack to boot from the HD. I tried the initrd route, and I still get the kernel panic message every time. I even tried to mount the HD from the command line that the ramdisk comes up with, but it still wouldn't work. Booting from the floppy to the CD and THEN to the HD is no problem, I just cannot get the thing to boot like it should. Right now, I'm in the midst of recompiling a kernel, hoping that I can compile the options that this machine needs. It is an OLD machine, probably dating back to the late '90s, a Pentium (the original), but I have used versions of Linux before on it. This is such a bizarre problem and it doesn't make any sense. Defies all logic! People tell me that there is no reason why it should not boot and I agree. I tried 3 different bootloaders just in case, but no go. Maybe there is a bug somewhere, or maybe it just isn't going to work and I should get a life?