-   Slackware (
-   -   custom kernel not boot after current lastest update (

zhoun 03-02-2010 09:18 PM

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?

damgar 03-02-2010 09:23 PM

Is there possibly a problem with the initrd? It sounds like it doesn't have support for the ext4 filesystem.

koenigdavidmj 03-02-2010 09:23 PM

Have you ensured that ext2, ext3, and ext4 are built in the kernel? Only ext3 is default, if I recall.

zhoun 03-02-2010 10:26 PM

thanks for your help!

Yes, i ensured that ext2, ext3, and ext4 are built in the kernel,
and i build most things into kernel and so not use initrd.

The ext4 paritation and custom kernel worked fine before upgrade.
Some changes in this update caused this, devicemapper?...

damgar 03-02-2010 10:35 PM

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.

brianL 03-03-2010 06:32 AM

Maybe you should have put your custom kernel in /etc/slackpkg/blacklist.

damgar 03-03-2010 08:44 PM

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:
# xfree86-devel
# 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
# below

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.

3-2-1 reboot!

rworkman 03-03-2010 09:20 PM

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.

zhoun 03-03-2010 09:51 PM

thanks for all your help.

The huge smp kernel worked fine, but generic kernel can't boot.
the error is "can't mount root filesystem".

just like 792973

huge smp can't work with kms and i915.

I am not complain, just want some clues to fix it.
The more guys help test the current, the more stable, right?

damgar 03-03-2010 09:57 PM

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.

T3slider 03-03-2010 10:08 PM

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/ 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.

damgar 03-03-2010 10:28 PM

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.

zhoun 03-04-2010 09:18 AM

I know initrd and i had compiled everything needed into custom kernel.
so just like huge smp kernel to not depend on initrd.

I used this custom kernel config for almost 3 years.

I not realized that this CHANGED after recent update.

The generic kernel and initrd.gz worked fine.
So i merged my custom config with generic config and generate the initrd.gz,
all worked fine.

thanks all.

zhoun 03-06-2010 10:33 PM

finally found the original cause:


Udev will not work with the CONFIG_SYSFS_DEPRECATED* option

thanks drmozes!

All times are GMT -5. The time now is 06:11 AM.