LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Post 13.0 switch from hd* --> sd* in -current with 2.6.32+ (http://www.linuxquestions.org/questions/slackware-14/post-13-0-switch-from-hd%2A-sd%2A-in-current-with-2-6-32-a-780448/)

rworkman 01-06-2010 11:36 PM

Post 13.0 switch from hd* --> sd* in -current with 2.6.32+
 
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

Old_Fogie 01-07-2010 01:22 AM

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

Quote:

-# PLEXTOR_DVDR_PX-XXXX (pci-0000:00:09.0-ide-1:0)
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="cdrom0", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="cdr0", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="cdr", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="cdwriter0", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="cdwriter", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="cdrw0", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="writer", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="dvd0", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="dvd", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="dvdrw0", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="dvdwriter0", ENV{GENERATED}="1"
-ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-ide-1:0", SYMLINK+="dvdwriter", ENV{GENERATED}="1"
+# DVDR_PX-XXXX (pci-0000:00:09.0-scsi-1:0:0:0)
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="cdrom0", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="cdrom", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="cdr0", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="cdr", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="cdwriter0", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="cdwriter", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="cdrw0", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="cdrw", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="writer", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="dvd0", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="dvd", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="dvdrw0", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="dvdrw", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="dvdwriter0", ENV{GENERATED}="1"
+ENV{ID_CDROM}=="?*", ENV{ID_PATH}=="pci-0000:00:09.0-scsi-1:0:0:0", SYMLINK+="dvdwriter", ENV{GENERATED}="1"
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

rworkman 01-07-2010 01:36 AM

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).

gegechris99 01-08-2010 07:13 AM

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:

Quote:

/dev/hda: Hard disk
/dev/hdb: Hard disk
/dev/hdc: DVD driver
/dev/hdd: Hard disk (with Slackware)
With new kernel, the renaming was:

Quote:

/dev/sda: Hard disk => /dev/sda
/dev/hdb: Hard disk => /dev/sdb
/dev/hdc: DVD driver => /dev/sr0
/dev/hdd: Hard disk (with Slackware) => /dev/sdc
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.

rworkman 01-08-2010 08:11 AM

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

GazL 01-08-2010 08:43 AM

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.

gegechris99 01-08-2010 09:20 AM

Quote:

Originally Posted by GazL (Post 3818857)
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 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).

rworkman 01-08-2010 09:33 AM

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.

GazL 01-08-2010 09:52 AM

Quote:

Originally Posted by rworkman (Post 3818924)
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. :)

Toods 01-08-2010 11:37 AM

Quote:

Originally Posted by rworkman (Post 3817086)
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

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.

rworkman 01-08-2010 03:27 PM

Quote:

Originally Posted by Toods (Post 3819054)
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.

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.

Old_Fogie 01-09-2010 03:31 AM

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.

gegechris99 01-09-2010 05:43 AM

@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.

smoooth103 01-09-2010 07:25 AM

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.

wroom 01-09-2010 09:18 AM

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?


All times are GMT -5. The time now is 05:50 PM.