[SOLVED] system upgrade caused kernel upgrade and now system doesnt boot
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.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
system upgrade caused kernel upgrade and now system doesnt boot
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.
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
@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
Last edited by nitecrawler; 08-06-2015 at 08:15 AM.
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:
Quote:
Originally Posted by nitecrawler
will proceed with a mkinitrd after a chroot...
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.
Last edited by bassmadrigal; 08-06-2015 at 08:19 AM.
Reason: Added edit
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...
Last edited by nitecrawler; 08-06-2015 at 10:28 AM.
didn't find the "in a pinch" mode though but for another time....
See this image, right above the first boot (just above the halfway mark on the screenshot). More for future reference than anything...
Quote:
Originally Posted by nitecrawler
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
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.
Quote:
Originally Posted by nitecrawler
is it common in a kernel upgrade? But my files have the settings still....I just can't see them as is...
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.
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...
Per the CHANGES_AND_HINTS.TXT file, Pat recommends using the generic kernel, which requires an initrd.
Quote:
Use one of the provided generic kernels for daily use. Do not report
bugs until/unless you have reproduced them using one of the stock
generic kernels. You will need to create an initrd in order to boot
the generic kernels - see /boot/README.initrd for instructions.
The huge kernels are primarily intended as "installer" and "emergency"
kernels in case you forget to make 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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.