when i did a full system upgrade what i missed was i didnt blacklist my kernel 3.10.17 and now system fails to boot with the new kernel 3.18.11 in the current repository...

i was using a generic kernel...

do i just follow the steps to compile a generic kernel again?

i havent tried using the huge kernel as yet in lilo....it was pretty late and i had to shutdown...

here is the error i had which is very similar to my booting issue i had earlier...

Mount: mounting /Dev/sda2 on /mnt failed:no such device
Error: no /sbin/init found on rootdev(or not mounted)

i did a chroot and tried changing my /etc/lilo.conf of /boot/vmlinuz to /boot/vmlinuz-generic-kernel-version but it didnt restart succesfully...didnt debug then....was really really late like i said....

was there a new conf file there? i dont know yet...like say /etc/lilo.conf.new???

missed checking that....

so my question now is will compiling the new generic kernel do for me?

or ***** THE TIME TIRING *****is it slackware reinstall for me?

Maybe you can try to boot you box via the installation disk (if you have any at your hands). Instruction to do so are in the welcome screen. After booting you can install the huge kernel or reinstall the 3.8.11 serie.

Bye

If you don't have anything critical on there, I would just reinstall. It takes only a couple minutes (i.e. 15 on a first gen i3) and saves the hassle.

Unless the upgrade was botched, there is certainly no reason to reinstall.

If you're sticking with the generic kernel, you need to recreate your initrd for the 3.18 kernel instead of the 3.10 you currently have. Easiest way is to use the installation disk to boot your Slackware and then run the mkinitrd_command_generator.sh

Or you could just link to the huge kernel in lilo.conf and then run lilo and reboot.

@VicFer: to reinstall means to compile the kernel again? i can access the underlying system using chroot...
$oltechaa: thanks..thats the last resort but i would just love to go through these ordeals so i know i can relax when it happens the next time round or maybe say i'd be a little more info equipped to avoid it altogether...

@bassmadrigal: i was looking for something of that sort....like compiling my generic kernel with mkinitrd as the configuration of initrd.gz is currently for the old kernel...let me try that...looks more hopeful

You were running the generic kernel. After the upgrade did you create a new initrd and then run lilo?
If not, this details the recovery technique. http://docs.slackware.com/howtos:sla...oot_from_media

@allend: thanks for the link..i have it and also the compiling generic kernel link marked..i had gone through a similar boot issue the last time my system didnt boot when i had compiled my first generic kernel....i forgot to run /sbin/lilo and so i was stuck on boot then...

this time i didnt create a new initrd file and run lilo, when my linux kernel got upgraded...
thanks for the tips folks...
will proceed with a mkinitrd after a chroot...


*will revert once i get back home and check on it

Reinstalling Slackware doesn't compile anything. When you install Slackware, you're taking pre-compiled binaries that are compressed (like zip files, but much better compression) and just extracting those to various places on the system. This includes the kernel. So reinstalling won't recompile your kernel.

You're definitely able to recompile your kernel if you want, but it certainly isn't necessary for most users (although, it is sometimes beneficial -- but we won't worry about that right now). You have at least two kernels sitting in your /boot folder, the huge (vmlinuz-huge-3.18.11) and the generic (vmlinuz-generic-3.18.11), both should be 3.18.11. To go into more detail, you have two options. The first is to just use the huge kernel, as that doesn't require making a new initrd. Just use the Slackware disc to boot into Slackware and make sure you have a line in your lilo.conf similar to the following (you might need to adjust the root drive if yours isn't /dev/sda2). After you do, run lilo and reboot (you might want to run lilo -t to make sure you typed everything right).

The second option is to use the generic and recreating your initrd. Again, boot off the Slackware disc and use it to start Slackware (follow the instructions on the startup screen to start your system "In a pinch"). Once you're back into Slackware, run:

Then run the command that it spits out and then make sure /etc/lilo.conf is pointing to the correct initrd and vmlinuz-generic-3.18.11... probably similar to the following:

Once that is done, run lilo and if there's no errors, reboot.

EDIT:
You certainly can do this after chroot'ing, but you don't need to if you just follow the "In a pinch" section on the installation disc's startup screen (the one you usually just hit enter to). This will allow you to use the kernel on the disc to boot into your Slackware. It's a great thing, because this will allow you full access to everything (including being able to start X), and I think it's a lot easier than doing chroot.

1 members found this post helpful.

So my system boots up almost fine with the new generic kernel..didn't find the "in a pinch" mode though but for another time....

I have a few issues though....

When I run chromium it doesn't start and error is:

Error while loading shared libraries:libcrypt.so.11:cannot open shared object file: no such file or directory


Lost my styles in fluxbox too and it's on the login shell not the normal shell prompt....so I have to get back to customising a lot now....is it common in a kernel upgrade? But my files have the settings still....I just can't see them as is...

See this image, right above the first boot (just above the halfway mark on the screenshot). More for future reference than anything...

You'll need to get a chromium package that works with your libraries. If you compiled it yourself, you'll need to recompile it. If you got it from Eric (Alien Bob), you'll need to grab his -current package instead of his 14.1.

These issues have nothing to do with upgrading the kernel (your original issues did), but these types of problems are normal when you are upgrading releases (or following -current). Libraries and config files can change frequently during the development process. Many times, programs will need to be recompiled to use newer libraries, and config files may need to be updated to deal with changes in the newer versions of the programs. Due to the sometimes rapid development of -current, most users are not recommended to use it for their systems. They should stick with the latest stable and then upgrade when the newest stable is released (following UPGRADE.TXT and CHANGES_AND_HINTS.TXT for the new release). Anything that is not stock Slackware may need to be recompiled (or grabbing a package from someone else who recompiled it) due to library changes (like your libcrypt.so.11 issue).

Just a comment about initrd and simplicity. AFAIK unless you encrypt your filesystems, there is no compelling reason to add the extra complexity of initrd. As long as you compile your kernel with kernel level support for your root filesystem you are good to go. The main thing is to not to disable your working kernel, IMHO. There is very little to go wrong with using a kernel only a few versions older that worked, unless this has somehow drastically changed recently. Commonly in a system upgrade I will use the hugesmp.s (or huge.s on ancient hardware) and upon first boot compile a new kernel using makeoldconfig to keep my base template in effect while offering any advantageous new options. I don't encrypt nor have need of any other advantage from initrd and I fairly often appreciate the simplicity with it unneeded.

The generic kernel which the op was using requires an initrd to work, you would be right if the op was compiling his own kernel, but that is not necessary to use slackware and more work than just remaking the initrd for the generic kernel.

Per the CHANGES_AND_HINTS.TXT file, Pat recommends using the generic kernel, which requires an initrd.

If limiting complexity is key, then an initrd should be preferred over compiling a kernel. With the mkinitrd_command_generator.sh script and some minor editing of lilo.conf, things are relatively simple compared to the complex task of compiling a kernel.

But if someone is going through the trouble of compiling a kernel, it is probably a good idea to include certain modules.

EDIT: orbea beat me to it

1 members found this post helpful.

@bassmadrigal:thanks...

It's the recompiling issue only....Most softwares work like Lynx, libreoffice, mplayer, skype etc except chromium....


How is that some work across kernels and some don't?