[SOLVED] Slackware kernel panics when spare hard drives are hooked up

gda · 07-22-2016, 01:31 AM

Finally you did it!

Concerning the warning it can be fixed just adding in lilo.conf the line :

Code:

lba32

right below the boot line.

Moreover you need to run lilo without the option -t (to be used only for testing - it does not install lilo just check the syntax of your lilo.conf)

bassmadrigal · 07-22-2016, 01:57 AM

Yes, as gda mentioned, that warning is not an issue and can be safely ignored. However, if you're like me and don't like seeing warnings, again, as gda mentioned, you can remove the warning by simply adding lba32 in the top section of your /etc/lilo.conf (I typically at it at the bottom of that first section -- you can see my example lilo.conf in my linked post if you're not sure where to put it).

Finally, as gda mentioned, the -t was only to test your conf file and hasn't actually made any changes. That won't happen until you run lilo by itself to install the MBR. Once you've run lilo you can then reboot and see if everything worked. If that works, try playing around with your harddrives (while the computer is off, obviously), then try and boot again. If it continues to boot, then congratulations, you're good to go

However, all that being said, I do have one minor concern. It only shows it's adding Slack-UUID, but makes no mention of any other boot entries. I would highly recommend you include a default, fall-back option to allow you to boot in case something doesn't work with your Slack-UUID (see below). I would have this one set up with your original entry, so replace root = /dev/sda2 with whatever your default device is (not the UUID). This allows you to boot your original configuration if the UUID stuff doesn't work (although, if you followed my instructions, it should work without issue). Basically, until I know that a new configuration is going to work (after testing it), I always leave my previous kernel intact in my lilo.conf.

Code:

image = /boot/vmlinuz
  root = /dev/sda2
  label = Linux
  read-only

However, if you don't add another entry and things don't boot, you can still recover with a Slackware install disc/usb drive by just follow the prompt at the beginning for rescuing a system.

bulletfreak · 07-22-2016, 04:32 AM

Well guys this is interesting. So I tried to do what bassmadrigal told me to do then everything went to hell. I updated my lilo.conf, updated lilo then rebooted. However I was given this glorious screen on what should've been the Lilo boot screen http://i.imgur.com/kcThOuC.jpg

So I chrooted into my install and tried to fix my lilo.conf. But when I tried to run lilo under chroot it gave me some weird error. So my only option at that point was to do a fresh install, which I did. I switched around my SATA cables so the drive I want Slack on was set as first, so Lilo would install to the right disk. Well that worked and the install went without a problem, then i rebooted. For whatever reason it gave me that same exact the error screen like i had before. http://i.imgur.com/Rzipwu5.jpg

It doesn't make any sense at all. I had them both plugged in throughout the install without a problem then I get that. What's the issue? Do i just need to format them for whatever reason? I don't get it. The issue I had the first time was because one of my spare drives was set as /dev/sda. But now it's not, so what even?

bassmadrigal · 07-22-2016, 06:33 AM

Can you post the files and commands I requested earlier?

As for your issue with the chroot, you need to bind mount /proc/, /sys/, and /dev/ for things to work properly. (The following is assuming you did your chroot under /mnt/. If you did it somewhere else, you'd change the location to match.)

Code:

mount -o bind /dev /mnt/dev
mount -o bind /proc /mnt/proc
mount -o bind /sys /mnt/sys

gda · 07-22-2016, 07:09 AM

Quote:

Originally Posted by bulletfreak

I switched around my SATA cables so the drive I want Slack on was set as first...

Once again: According to my understanding, the name assigned to the devices may not necessarily match the corresponding SATA or RAID channel numbers. The hard disks are named sda sdb sdc ... according to the order under which they get detected during the boot. Therefore, in principle, the disk names may change between startups especially if you have different controllers (probe delay or similar things).

So I suggest to go back in this thread and read again (carefully!) what both bassmadrigal and me recommended to do. Finally as also bassmadrigal mentioned, it would be useful to look at your actual configuration files and at output of the commands we both asked to see. Without that it is really difficult to figure out what is going on at your side!

bulletfreak · 07-22-2016, 07:09 PM

Okay I updated my lilo.conf again (and this time I actually updated it correctly, so no boot screen of 99s) but do I need to change my fstab to all UUIDs?

bulletfreak · 07-22-2016, 07:11 PM

Also here's my lilo.conf:

Code:

# LILO configuration file
# generated by 'liloconfig'
#
# Start LILO global section
# Append any additional kernel parameters:
append=" "
boot = /dev/disk/by-id/ata-WDC_WD10EZEX-21M2NA0_WCC3F6DU8YP4
lba32
#compact        # faster, but won't work on all systems.

# Boot BMP Image.
# Bitmap in BMP format: 640x480x8
  bitmap = /boot/slack.bmp
# Menu colors (foreground, background, shadow, highlighted
# foreground, highlighted background, highlighted shadow):
  bmp-colors = 255,0,255,0,255,0
# Location of the option table: location x, location y, number of
# columns, lines per column (max 15), "spill" (this is how many
# entries must be in the first column before the next begins to
# be used.  We don't specify it here, as there's just one column.
  bmp-table = 60,6,1,16
# Timer location x, timer location y, foreground color,
# background color, shadow color.
  bmp-timer = 65,27,0,255

# Standard menu.
# Or, you can comment out the bitmap menu above and 
# use a boot message with the standard menu:
#message = /boot/boot_message.txt

# Wait until the timeout to boot (if commented out, boot the
# first entry immediately):
prompt
# Timeout before the first entry boots.
# This is given in tenths of a second, so 600 for every minute:
timeout = 1200
# Override dangerous defaults that rewrite the partition table:
change-rules
  reset
# Normal VGA console
vga = normal
# Ask for video mode at boot (time out to normal in 30s)
#vga = ask
# VESA framebuffer console @ 1024x768x64k
#vga=791
# VESA framebuffer console @ 1024x768x32k
#vga=790
# VESA framebuffer console @ 1024x768x256
#vga=773
# VESA framebuffer console @ 800x600x64k
#vga=788
# VESA framebuffer console @ 800x600x32k
#vga=787
# VESA framebuffer console @ 800x600x256
#vga=771
# VESA framebuffer console @ 640x480x64k
#vga=785
# VESA framebuffer console @ 640x480x32k
#vga=784
# VESA framebuffer console @ 640x480x256
#vga=769
# End LILO global section
# Linux bootable partition config begins
image = /boot/vmlinuz-generic-4.4.15
  initrd = /boot/initrd.gz
  root = "UUID=741b0cbc-df54-421e-b4e2-019718c00361"
  label = Slack-UUID
  read-only
##image = /boot/vmlinuz
##  root = /dev/sda2
##  label = Linux
##  read-only
# Linux bootable partition config ends

bulletfreak · 07-22-2016, 08:25 PM

Welp it finally worked guys. Thanks a lot to all you.

bassmadrigal · 07-22-2016, 11:34 PM

Quote:

Originally Posted by bulletfreak

Okay I updated my lilo.conf again (and this time I actually updated it correctly, so no boot screen of 99s) but do I need to change my fstab to all UUIDs?

Glad you got it working! To answer this, if there's any chance of the drives changing, you would need UUIDs in your fstab. Otherwise, if you have /dev/sda listed in your fstab, but your other drive becomes /dev/sda, then your system can't finish booting.

bulletfreak · 07-23-2016, 10:02 PM

Quote:

Originally Posted by bassmadrigal

Glad you got it working! To answer this, if there's any chance of the drives changing, you would need UUIDs in your fstab. Otherwise, if you have /dev/sda listed in your fstab, but your other drive becomes /dev/sda, then your system can't finish booting.

I added the UUIDs to my fstab anyways.

enorbet · 07-24-2016, 01:23 PM

Now that this thread is marked "Solved" I'd like to ask a question as well as make a point.

Point - In some instances it is easier and possibly safer, since it can have actual meaning to the owner of the boxen, to use LABEL instead of UUID.

Question - Unless I missed something I didn't see that OP was using FS encryption so why the insistence on initrd? AFAIK encryption is the only situation in which initrd is required with no other working option. Some people prefer to provide specific support (as in ext4) in a custom kernel rather than mess with generic and initrd. If one plans on "rolling his own" anyway, a simple checkbox or 3 is less complicated than adding in a "handoff" step. I do understand that OP would likely find it easier to use an initrd with generic than building a custom kernel but it would be easier still to just use "huge" at only rare and small penalty in most cases.

bassmadrigal · 07-24-2016, 03:01 PM

An initrd is required when using UUID to actually provide the UUIDs since it isn't handled by the kernel alone (maybe it's provided by busybox... I'm not sure, or maybe it needs the environment provided by the initrd to make the UUIDs available to mount). It was verified that an initrd was still needed (and not a relic of the past) in a thread here a few weeks ago.

elcore · 07-25-2016, 01:11 AM

The label or /dev/sdx is much simpler and easier to remember, so if there's root=/dev/sdc4 in my grub.cfg I'm sure it's the right partition at first sight, no way I'd remember the uuid.
Ramdisk I don't use, it's not that something is wrong with slackware initrd, but I've had bad experience with some other distros that pack udev rules and KMS inside ramdisk by default.
They sometimes automatically do that even if the configuration is incorrect or incomplete, causing a mismatch by packing up generic configuration from /lib rather than the one from /etc.
So in these automated ramdisks one can find basically anything, I've seen intel microcode on amd cpu, built in modesetting for integrated chip which conflicts with PCI chip, and more.
It's kinda useless if all the required drivers are compiled into kernel like ARM builds usually do, luckily it's still optional in kernel config.

bassmadrigal · 07-25-2016, 01:19 AM

Quote:

Originally Posted by elcore

The label or /dev/sdx is much simpler and easier to remember, so if there's root=/dev/sdc4 in my grub.cfg I'm sure it's the right partition at first sight, no way I'd remember the uuid.

The problem with referring to /dev/sdc4, is if you plug in another drive or add a USB device and all your devices change. Some motherboards have this happen. UUIDs won't change without formatting your partition (and there's even ways around that). You just have to find the UUIDs once, and once you have your lilo.conf and fstab converted, you have no need to reference them again, since the system handles it for you.

Yes, labels can be used in place of UUIDs, but labels can accidentally be the same if you aren't paying attention. It is true that, mathematically, UUIDs are able to be the same, however, the actual likelihood of it ever occurring makes it relatively impossible.

Quote:

They sometimes automatically do that even if the configuration is incorrect or incomplete, causing a mismatch by packing up generic configuration from /lib rather than the one from /etc.
So in these automated ramdisks one can find basically anything, I've seen intel microcode on amd cpu, built in modesetting for integrated chip which conflicts with PCI chip, and more.

In normal Slackware fashion, the initrd doesn't do all of that. Slackware doesn't try to guess for you. It is your job to ensure the initrd is as it should be. That is why the default kernel is a huge kernel with all your needed modules compiled in. If you want microcode, you need to add it.

There is a script that will try to find the required modules, based on your current setup, that you should add to your initrd and outputs a commandline to run, but that is the closest Slackware will come to "guess" your configuration.

elcore · 07-25-2016, 02:16 AM

Quote:

Originally Posted by bassmadrigal

The problem with referring to /dev/sdc4, is if you plug in another drive or add a USB device and all your devices change. Some motherboards have this happen. UUIDs won't change without formatting your partition (and there's even ways around that). You just have to find the UUIDs once, and once you have your lilo.conf and fstab converted, you have no need to reference them again, since the system handles it for you.

Well the label can be static or dynamic depending on the requirements just like uuid, but doesn't require udev or initrd to handle it, and is much easier to remember.

Quote:

Originally Posted by bassmadrigal

Yes, labels can be used in place of UUIDs, but labels can accidentally be the same if you aren't paying attention. It is true that, mathematically, UUIDs are able to be the same, however, the actual likelihood of it ever occurring makes it relatively impossible.

This is non issue if you're the only one changing the labels.

Quote:

Originally Posted by bassmadrigal

In normal Slackware fashion, the initrd doesn't do all of that. Slackware doesn't try to guess for you. It is your job to ensure the initrd is as it should be. That is why the default kernel is a huge kernel with all your needed modules compiled in.

The huge.smp, I have used it to boot and make localmodconfig, very useful because it supports a lot of hardware, but..
It is tuned for intel and what I got is K8. If I want it tuned for K8 I must rebuild.
So I'll simply include ext and jfs in kernel image at build time, so it can boot without ramdisk. By that point the generated ramdisk would be empty anyway because there are no modules to load.