[SOLVED] custom kernel not boot after current lastest update
SlackwareThis Forum is for the discussion of Slackware Linux.
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.
Distribution: slackware64 current & win7 64 on thinkpad X61
custom kernel not boot after current lastest update
After the bunch of updates with current, my custom kernel (2.6.33) can't boot.
The error is:
/sbin/e2fsck: No such file or directory while trying to open /dev/sda6
The superblock could not be read or does not describe a correct ext2
filesystem. If the device is valid and it really contains an ext2
filesystem (and not swap or ufs or something else), then the superblock
is corrupt, and you might try running e2fsck with an alternate
e2fsck -b 8193 <device>
The /dev/sda6 is ext4 and is ok since it can boot with official huge smp kernel 2.6.33.
My custom kernel can boot before this bunch of updates in current.
What i missing in kernel?
Are you sure you are using the custom kernel still? Slackpkg upgrade-all will remove kernel versions. Usually not a custom kernel, but it could depend on how that custom kernel was named. It's possible that what you are actually booting is actually the new generic kernel.
Slackpkg usually won't replace a custom kernel, but the slack forum is full of people that might have wanted to read this from /etc/slackpkg/blacklist:
# This is a blacklist file. Any packages listed here won't be
# upgraded, removed, or installed by slackpkg.
# The correct syntax is:
# To blacklist the package xfree86-devel-4.3.0-i386-1 the line will be:
# DON'T put any blank line(s) or any space(s) before or after the package name.
# If you do this, the blacklist will NOT work.
# Automated upgrade of kernel packages aren't a good idea (and you need to
# run "lilo" after upgrade). If you think the same, uncomment the lines
Having said that, I just used this file and my kernel-firmware package got upgraded and I was told to rerun lilo which I've done. What I haven't done is reboot. If this post gets edited then you know I'm in the same boat.
1) if the stock kernel works, then failure of your custom kernel is not a bug. Consider looking at the differences in the two kernel configurations (see ./scripts/diffconfig in the kernel source).
2) The slackpkg blacklist is irrelevant for someone following -current. In fact, it should be cleared out completely for a -current system.
3) Slackware -current is NOT intended for people who want the latest and greatest and expect it to "just work" and to get support for every little thing that goes wrong. -current is the development tree, and quite frankly, it's *expected* to break from time to time, and if you can't handle that (or more importantly, figure out the little stuff yourself), then quite frankly, you should stick to the latest -stable release.
Have you tried to create a new initrd yet? I upgraded to current MINUS the kernel (I like to run the release candidates when available and since I've had a 2.6.33 kernel for a month now, I'm waiting for a maintenance release to bother) and it boots fine, however I don't need the initrd.
It just sounds like your initrd isn't working properly or is missing. Also I've seen one report of the new mkinitrd script not working for someone, but they reported the original worked for them. I have no way to confirm that.
The generic kernel requires an initrd (initial ramdisk) since the filesystems are compiled as modules -- and therefore it cannot mount your root filesystem without an initial ramdisk that loads the right module(s) for your system. There should be a script in /usr/share/mkinitrd/mkinitrd_command_generator.sh that can generate the proper command for you. This is unchanged between stable and -current, and there should be tons of threads explaining this and /boot/README.initrd contains the relevant information. Honestly, if you didn't know about the initrd (which has been required for the generic kernel since 12.0 as far as I remember) then you probably should be running stable (13.0) instead of -current.
As to 'The more guys help test the current, the more stable, right?' -- that's true to an extent, but if it becomes necessary to try to distinguish user error from real problems, it makes it much more frustrating for the developers who may not have the time to deal with these non-issues. -current really should be reserved for those that know what they're doing, and though that may be you some day, right now I would really advise sticking with stable.
I would suggest doing this to make sure your kernel is what you think it is:
ls -alt /path/toyour/customkernelsource
check the dates. The most likely explanation is that the upgrade replaced your kernel and if that looks right then check /etc/lilo.conf to make sure that your boot options are pointing where you think they are. If all this checks out then run the generator script and run mkinitrd accordingly.