[SOLVED] Kernel Panic with generic kernel on Dell poweredge 2850 Slackware 14.1
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Kernel Panic with generic kernel on Dell poweredge 2850 Slackware 14.1
After installing slackware 14.1 with LVM and making an initrd.gz for the generic kernel on my dell poweredge 2850 I had a kernel panic. Searched around for similar errors and checked LQ with no luck. Reinstalled without LVM and same error.
Huge boots fine with no issues, I don't know if maybe something is missing from the mkinitrd_command_generator.sh output or the generic kernel?
The system is installed on a raid 1 array with multiple partitions for boot, swap, / , tmp, var, and home.
You have a separate partition for /boot and the initrd is installed there. But /boot being not yet mounted at time of unpacking the initrd, that contains the ext4 module needed to mount /, you can't mount /, thus you don't have access to /mnt.
Long story short: don't make a separate /boot partition or don't put the initrd there.
Also IMHO there are very few use cases that actually need to have separate partitions for /boot, /var, /tmp and /home, but dedicated hard disks.
Last edited by Didier Spaier; 08-17-2014 at 12:07 PM.
You have a separate partition for /boot and the initrd is installed there. But /boot being not yet mounted at time of unpacking the initrd, that contains the ext4 module needed to mount /, you can't mount /, thus you don't have access to /mnt.
His /boot partition is ext2, not ext4, according to his fstab. I'm using a similar setup, without any problems.
His /boot partition is ext2, not ext4, according to his fstab. I'm using a similar setup, without any problems.
I didn't mean that /boot couldn't be mounted without the initrd, but possibly was not mounted soon enough so that the initrd be available, that contains the ext4 module needed to mount /, thus making not possible to access /mnt.
But I certainly admit that this is pure speculation on my part.
As long as the OP's issue will be sorted out one way or another and that I'll have learned something in the process, I'll be happy. If I've to be proved wrong to get that result, so be it
Last edited by Didier Spaier; 08-17-2014 at 03:36 PM.
Which partitioning layout did you configure this time? (EDIT: sorry I didn't see your second post). Did you change anything else?
PS If not already done I'd suggest that you put two lilo stanzas in your /etc/lilo.conf: one with the -generic kernel and one with the -huge one. This way you'll be able to get into your system and attach to your next post the relevant part of /var/log messages, i.e. all messages from booting with the -generic kernel till the kernel panic.
Just to make sure: of course you included the line locating the initrd in /etc/lilo.conf?
Last edited by Didier Spaier; 08-17-2014 at 05:33 PM.
Reason: PS added.
Which partitioning layout did you configure this time? (EDIT: sorry I didn't see your second post). Did you change anything else?
PS If not already done I'd suggest that you put two lilo stanzas in your /etc/lilo.conf: one with the -generic kernel and one with the -huge one. This way you'll be able to get into your system and attach to your next post the relevant part of /var/log messages, i.e. all messages from booting with the -generic kernel till the kernel panic.
Just to make sure: of course you included the line locating the initrd in /etc/lilo.conf?
If the boot process under generic cannot mount "/", it won't be able to mount /var/log either. There won't be any messages there from the attempt to boot the generic kernel.
Maybe problem is with megaraid module, not ext4, I see that the hid_generic and uhci-hcd seem to have been loaded with the initrd (if I refer to the picture) so logically the initrd has been loaded as well
With the system running with working kernel, what dmesg says about the raid?
I suggest that when the system tells you that it is in RESCUE mode, type the command cat /proc/partitions to find out what partitions it sees at the moment. If that doesn't provide enough information on the problem (or provides no output) then do the following:
Use the installation DVD to boot and mount/chroot into your installed system. Assuming that you create a new directory /mnt/rescue to mount your system from the installation DVD, run the following commands:
the mount command that mounts your root partition to /mnt/rescue
mount --bind /proc /mnt/rescue/proc
mount --bind /sys /mnt/rescue/sys
mount --bind /run /mnt/rescue/run
chroot /mnt/rescue
As root, re-run /usr/share/mkinitrd/mkinitrd_command_generator.sh with the same command line arguments as before.
Run the command returned by /usr/share/mkinitrd/mkinitrd_command_generator.sh appending the additional arguments of -w 10 which will delay the boot 10 seconds after the modules are loaded. That should give you time to read the results of the module loading and/or take a picture of that output.
Please tell us what the module loading tells you.
If that doesn't suggest a solution, I would use the installation DVD to re-mount the system using the above mount --bind commands and then edit the file /boot/init-tree/init to add
Code:
cat /proc/partitions
on line 159 and then run the command mkinitrd to re-generate initrd.gz. Reboot and see what partitions are available after the modules load.
OK, so the problem is that loading the module is not sufficient to have the drive show up.
When you are in rescue mode, please type dmesg to see what the kernel may have complained about while starting. If you can't read it all, try dmesg | more.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.