The new kernels exclusively use “libata”. The last bits of the old IDE/ATA subsystem have finally been removed.

This means, that your IDE disk will be recognized as a “SCSI disk”. The device name “/dev/hda” will change to “/dev/sda” when you boot the new kernel. As a result, your computer will refuse to boot because the bootloader (grub or lilo) can not find the root device.

Robby Workman has written a HOWTO for anyone who wants to do this upgrade. The article was published as http://rlworkman.net/howtos/libata-switchover. By following the HOWTO you will not have any issues in upgrading to the new kernel.

I will print Robby’s HOWTO in full below to give it some more coverage:

libata_switchover
20100110
rworkman

/*
Thanks to David Somero, Old_Fogie, gegechris99, and GazL for valuable
feedback and enhancements to this document.
*/

This is written to provide one of several ways to retain a working system after upgrading from Slackware 13.0′s kernel to the newer kernel in -current (which removes support for the “old” ide subsytem, thereby causing all /dev/hd* devices to have /dev/sd* names.

1. Upgrade the kernel and kernel-modules packages normally.

2. Edit /etc/fstab to reflect the change from hd* to sd*.

If you have multiple SATA devices, and especially if you have some of
both hd* and sd* devices present already, then you’re basically going
to be playing a guessing game right now, and you probably want to
consider using some of the persistent symlinks in /dev/disk/by-*/
instead of raw device nodes.

* If you are using one of the generic kernels (requiring an initrd),
then use the sd* name for the root device when creating the image
(edit /boot/initrd-tree/rootdev and then re-run “mkinitrd”).

* You will almost surely want to remove the udev rules file for cdrom
devices (it will be regenerated on the next boot with correct
information reflecting the new libata stuff):
# rm -f /etc/udev/rules.d/70-persistent-cd.rules

* Speaking of optical devices, if you have multiple disk drives and an
optical drive using the old ide subsystem, then be aware that the
optical drive will get a /dev/sr* name instead of /dev/sd* — this is
relevant because you might see something like this (if your optical
drive is currently /dev/hdb):

Old Name –> New Name
/dev/hda /dev/sda
/dev/hdb /dev/sr0
/dev/hdc /dev/sdb

3. Run lilo. Note that you have made no edits at all to it yet, unless
you needed to edit it for the new kernel. Specifically, do not make
any changes with respect to hd* –> sd*.

4. Reboot. At the lilo prompt, press <TAB> and add an append for the
real root device (which will no longer be /dev/hd*). For example, if
the old root device was /dev/hda1, and it will now be /dev/sda1, and
the name of your kernel image is “Linux” then you would type this:

Linux root=/dev/sda1

5. Once the system comes back up, then fix /etc/lilo.conf, run lilo, and
reboot again to be sure everything is correct.

Good luck! Eric

PS: I have refreshed the copy of Robby’s text so that it reflects the updates he made to the original after feedback from several people.

Although Slackware -current still has a 2.6.29.x kernel, I am sure that people are experimenting with 2.6.30 kernels. In some cases, and only on Slackware for the x86_64 architecture so far, this may lead to boot problems. There is a problem that manifests itself when you are using an initial ramdisk with your kernel. The error message that you may see (unless it scrolls off your screen too fast) is this:

“initramfs unpacking failed: junk in compressed archive“

As a result, your computer will fail to boot.

Now, what is happening here?

By default, LILO loads your initial ramdisk (/boot/initrd.img) into the first 15MB of memory. This circumvents a BIOS limitation for older systems (typically, computers produced before 2001).

However, the linux kernel has been growing in size, and there are combinations of kernel and initrd that will no longer fit into the first 15MB of memory. This leads to boot failure. Because of the fact that the kernel and initrd files are compressed archives, the rule of thumb is that these issues appear when the combined size of your kernel and initrd files is larger than 8 MB. The kernel will then overwrite part of the initrd in memory, leading to the above error message.

For computers with a x86_64 capable CPU, it is safe to assume that the computer has a BIOS without the 15MB limitation. In this case, you can add the following parameter to your “/etc/lilo.conf” file:

large-memory

This option instructs LILO to use a larger memory window when loading the initial ramdisk (do not forget to run the “lilo” command after making this change). It will cure the issue.

I think this should be added as a default option in the lilo.conf file generated by the liloconfig utility of slackware64.

Eric