[SOLVED] kernel boot switches from proper internal sata to external SCSI drive with resulting panic
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.
Greetings,
I did the procedure given, with the slight modifications to the names, and it appears to work! I first tested it with no external SCSI devices powered on, and that booted fine. I then powered on my external SCSI disk drive and rebooted. That boot ran to completion with no KPs. The only change is that the Root drive was sda without the external SCSI drive and was sdb with the external SCSI drive, which had become sda. However, the UUID was still pointing to the proper Root drive. Just as it should work. A small price to pay to allow a SCSI device to be plugged in at boot time, or hot-plugged later.
I did use @bassmadrigal's suggestion of using the UUID path rather than the legacy device name. That is about the only major change I made to the procedure.
So, in summary, it does indeed look like initrd is required for UUID to work properly. That is not very intuitive and the manpages do not even hint at it. Maybe we need a UUID HOWTO. Remember them?
Thanks to all who helped me resolve this problem.
I will keep this thread open for a little while, but I feel it is successful.
Girvin
I am still a little puzzled as to why the alternate root specification methods fail, not least because I have used them all in times past, or at least thought that I had... I will investigate that further as time permits - I need a lilo internals review anyway!
Make a few notes and keep for future reference too. UUIDs easily resolve most boot device conflicts. I always use lilo as bootloader and configure with initrd and UUIDs first thing after a new install anyway, so it has kept me isolated from boot problems to the point that I don't even think much about it any more.
Keep us posted if there any new developments, and good luck!
There are a few workarounds, BTW.
You could roll your own kernel and build SATA driver in <*>, and Adaptec driver as module <M>. This way the module is even not accessible before root is mounted - and SATA is going to be sda for sure.
Or you could blacklist Adaptec module (blacklisted modules will not be loaded automatically) and load it using a startup script. Same result again - SATA is going to be sda.
Or you could build kernel command line into kernel, I just did out of curiosity. The commandline I built in is
image=/boot/bzImage
label=gentoo # Name we give to this section
read-only # Start with a read-only root. Do not alter!
Now I have a kernel that boots with this hard drive only!
Also out of curiosity a few month ago I did go a step further and embedded an initrd in the kernel (an EFI stub in that case as this was to boot in UEFI mode), see http://slint.fr/testing/slint64-current_efi-stub/. This was just out of curiosity as of course this precludes modifying the command line at boot time and having several boot entries, unless you use a boot manager on top of that
Ref.: post #28 in this thread.
Last edited by Didier Spaier; 06-22-2016 at 06:12 PM.
Interesting. The desktop I'm writing this on has EFI stub kernel, no initrd at all. Such a plain setup is not very flexible, no choice to boot backup kernel. In case my freshly built kernel fails I'd have no choice but use UEFI shell or boot with SystemRescueCD (which I always have on USB stick) and set efivars. So I installed rEFInd - and I really like it over Grub2!
Hmh, Gentoo has it in portage. Next time I feel adventorous I'll give it a try!
Code:
~ $ eix elilo
* sys-boot/elilo
Available versions: *3.6_p20060314 (~)3.10 (~)3.12 (~)3.16
Homepage: http://elilo.sourceforge.net/
Description: Linux boot loader for EFI-based systems such as IA-64
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.