I suspect a few people will eventually run into this problem, and while it's easy to get around for the more experienced users (the ones that *should* be running -current), we all know that everyone isn't in that group :-)

http://rlworkman.net/howtos/libata-switchover

I'm not sure this is needed, but to play it safe (even tho the release notes didn't mention it), before I did the upgrade was to delete the file:

/etc/udev/rules.d/70-persistent-cd.rules

Then did the upgrade, my reboot, and the rule gets recreated.

Again, I'm not sure if that's needed but I really didn't want to have cdrom/dvdrom drive issues.

As you can see below, the ID_PATH changes, from -ide to -scsi

FWIW, I diff'd the files and they do indeed show a difference:

-sanitized

I'm not sure if I should send this off to Mr. V or not (tho he may read this dunno.

Offtopic: wow preempt kernel, tickless timer too now in new kernel, very nice, I don't have to rebuild it anymore It's working great on acer aspire one netbook (now has thermal info (acerhdf) woohoo! and my asus desktop.

-Fogie

1 members found this post helpful.

Yes, good catch re the persistent optical device rules file - that will need to be killed before the reboot.
I just cleaned up the howto quite a bit (thanks to mrgoblin) and added a tip about using an initrd (thanks to goblin again).

Hello Robby,

I upgraded my -current machine using your HOW-TO. Thank you.

I don't know if this is self-evident but I went through an issue to identify how my /dev/hdd2 Slackware partition would be renamed. At first, I thought I just needed to rename /dev/hdd2 into /dev/sdd2 but it didn't work because my hardware is organized like this:

With new kernel, the renaming was:

I assume /dev/sd* only list hard disks.

Maybe a mention on this topic might be useful in the notes of next Slackware version and in your HOW-TO.

Thanks; I added a note about this to the howto.

Robby I'm confused. If you don't run /sbin/lilo at step 2 to update its map file, then how is the bootloader going to load the the new kernel at step 5 when you reboot? Won't it just load the old kernel (assuming the sectors on disk haven't been overwritten in the meantime), but then, if it uses the old kernel, won't it also use the old names too, leaving you in the same situation as you were?

I can see how this process would work if you were rebooting using an install cd with the new kernel on it and specifying root= to get at your rootfs in order to run /sbin/lilo under the new kernel version but the howto doesn't mention anything about booting from cd. Am I missing something here?

PS. This is just for the purpose of my understanding. My system already uses sd* names so I don't have to go through this process in anger.

I may have got into such a situation. After the first reboot (lilo was not run), the system hanged at the step before "BIOS Check Successful" message appears (i.e. the dots appeared and then nothing). I used a CD -current from July (i.e. pre-13.0) to boot and tinker with the various settings (lilo.conf, fstab, initrd.gz).

At one point, I ran lilo and on the next reboot, I went farther (i.e after "BIOS Check Successful") until I tripped again (on my initrd.gz image). Finally I found my issue (ie. /dev/hdd2 being renamed into /dev/sdc2).

You're exactly right. Fixed.
I knew what I meant, but I didn't at all *write* what I meant. I was intending that to mean "don't try to run lilo with the s/hda/sda/ changes" yet.

Much better.

Robby, would it be possible for you to write a similar HOWTO for those using GRUB (Legacy)?. I tried to figure this out myself but there are a few differences such as how drives are numbered and I am not sure.

Thanks,

Bill.

I've never used grub, believe it or not, so it would be better if someone else wrote that up. I'll be more than happy to include a link to it.

I've got debian lenny and slack --current on one box together. Debian's grub controls the boot loader. For their grub all I had to do was change the hda to sda, fwiw. As far as slackware's grub I don't use it on --current, so I've got no pointers to mention.

@rworkman

Back to your HOWTO. I think that lilo (step 2) should be run as a last step just before reboot (step 4) because if one uses initrd.gz image a rerun of lilo is necessary.

Thanks! Was wondering my other drive wouldn't mount. I had both sda and hda used previously. I used dmesg and also guessed at the naming convention, as you suggested, and settled on the naming in fstab from hda2 to sdb2. Works now.

Wow.

I am tinkering with a HD recovery tool, and am having enough trouble already with treating different devices correctly. Identifying the unit as an IDE drive and using the correct control method on the device, (not treating it as a scsi), will be even more difficult to do in a safe manner if the device name and major/minor numbers get obfuscated just because of pedantery in naming the drives. An IDE disk is an IDE disk, and a SCSI-disk is a SCSI disk, even for the SATAs.
Low level I/O in Linux has become very much to complicated as it is already, without introducing any confusing renaming of devices.

Thing is, if the device is a SCSI disk, firewire disk, USB, SATA or alike, then the device will be an "SD" anyhow. Why not letting the IDE interface be left as it is, since it is currently working, and is at the end of its life cycle? If one wants an "SD" entry for an IDE device, this has been possible for a long time now in Linux.

Is this yet another example of people meddling with things they shouldn't touch, with no other obvious reason than to feed the "symmetry devil"? Or am i missing something important? Is there a particularly good reason to start naming the old ide devices as scsi?