kernel-2.6.9-1.6_FC2 boot failure where kernel-2.6.9-1.3_FC2 works

Aleksandar Milivojevic amilivojevic at pbl.ca
Fri Nov 26 17:18:33 UTC 2004


John Summerfield wrote:
> Let me see.
> 
> I plug in USB camera. Shos up at /dev/sda.
> I add USB drive. Shows up at /dev/sdb.
> 
> Tomorrow
> I plug in USB drive. Shows up at /dev/sda
> I plug in USB camera. Shows up at /dev/sdb.
> 
> What if I have _two_ USB drives (I do - one for carrying stuff, one for 
> backups)?.
> 
> A filesystem label would help overcome the confusion.
> 
> Didn't I read somewhere that sata drives are hdx with 2.4 kernels, sdx with 
> 2.6?.

This is correct.  SATA drives are sd* in 2.6.  And yeah, sd* devices 
change names when you connect/disconnect/replace them.  Something I 
always considered Linuxs' weak point.

Anyhow, as I already wrote couple of times, all this confusion could 
have been avoided if Linux by any chance implemented uniq device names 
based on hardware properties.  Either the way Solaris does it (not 
ideal, but light years better than current Linux mess), or using 
something smarter.

This way, your /boot partition would be something like /dev/dsk/c0t0d0s0 
(I won't go into describing Solaris /devices directory hierarchy, 
something most users dread cd-ing into, only the symbolic links in /dev 
directory).  Transleated this device name is:

  - s0: first partition
  - d0: on first LUN (if it is multi-lun SCSI device, always zero for 
preatty much everything else)
  - t0: on disk with ID 0 (SCSI ID for SCSI, 0 for master IDE drive, 1 
for slave IDE drive, WWN for fibre channel, or something else that is 
uniq for other bus types)
  - c0: on controller number zero (system remembers what controllers you 
had, so numbers do not change when you add/remove controllers).

Now let say you had SCSI controller in the box, and it was assigned 
controller ID 1 (c1).  If you remove it from the system, your USB 
devices will still be c2, and your SATA controller would still be c0. 
If you connect new controller (SCSI, SATA, old ATA, USB, whatever), it 
will be assigned as c3 (not now unused c1).  If you reconnect your SCSI 
controller back, it will reappear as c1 (so all devices connected to it 
will reuse their old device names).

Try that on Linux.  Each time you connect or disconnect something, all 
your /dev/sd* devices will shift.  On Solaris, nothing shifts.  All 
device names stay the same as if their names were carved in the rock.

Your USB camera would than be /dev/dsk/c2tXXXXd0sY, where c2 is your USB 
controller, and XXXX is some uniq ID stored in your camera hardware. 
Your USB drive would have different uniq ID.  No matter in which order 
you connect them, they are always assigned same device names.  You don't 
need labels on them.  I don't know much about USB internals, but I guess 
there's probably something in each USB devices to make more or less uniq 
device name.

If you have shell access to Solaris box (either sparc or intel), check 
out file /etc/path_to_inst (yeah, the one that begins with comment 
"Caution! This file contains critical kernel state").  It is the file 
where Solaris keeps record of all devices that were ever connected to 
the system, so that if they get reconnected they get their original 
device name.  It is kind of your system's hardware past and present 
(well, Solaris isn't smart enough to guess the future, but that part 
might be added to Linux implementation ;-) ).  If you connect new device 
(while old one is not connected), it will get new name (old one is still 
reserved if you decide to reconnect old device).

Actually, on Solaris, if you move controller from one PCI slot to 
another, system will detect that and treat it as new controller (new 
controller ID).  Sometimes this is neat, sometimes it is pain in the 
butt.  But nothing is ideal ;-)

Theoretically, something like this could be added from user space on 
Linux systems (basically, by expanding and developing on the current 
idea of linking /dev/cdrom and /dev/floppy to appropriate device names). 
  But it would be light years simpler and more stable if Linux kernel 
was changed to cooperate in this.

-- 
Aleksandar Milivojevic <amilivojevic at pbl.ca>    Pollard Banknote Limited
Systems Administrator                           1499 Buffalo Place
Tel: (204) 474-2323 ext 276                     Winnipeg, MB  R3T 1L7




More information about the fedora-list mailing list