You are not logged in.
Pages: 1
I have just attempted to convert devfs to udev on my dual AMD Opteron with two SCSI drives running fully up-to-date Arch Linux. The result of following the standard udev procedure (which has worked on three other IDE machines without a hitch) was that of the four mountable SCSI disk partititions, only swap and / were mounted properly
/dev/discs/disc0/part1 / reiserfs defaults 0 0
dev/discs/disc0/part2 swap swap defaults 0 0
while the /home and /data partitions were not recognized and mounted:
/dev/discs/disc0/part3 /home reiserfs defaults 0 0
/dev/discs/disc1/part1 /data reiserfs defaults 0 0
I was able to revert the machine back to its original devfs so the machine does work properly in its original configuration.
I noticed a bash script in the /etc/udev directory that seemed to be used to identify the SCSI devices present. Is it possible that this is not working correctly? Does anyone have any idea of how the SCSI configuration could have gone awry?
Thanks.
Some details about the machine:
arch version: Arch Linux 0.7 (Wombat)
kernel version: 2.6.7
two processors: AMD Athlon(tm) MP 2600+
two SCSI_storage_controllers: Adaptec AIC-7899P U160/m (rev 1).
Offline
On my scsi computer, after instaling udev and rebooting, I had errors on all scsi drives. So I changed fstab, to use standard udev syntax.
Transform
/dev/discs/disc0/part3 /home reiserfs defaults 0 0
/dev/discs/disc1/part1 /data reiserfs defaults 0 0
to
/dev/sda3 /home reiserfs defaults 0 0
/dev/sdb1 /data reiserfs defaults 0 0
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
Hi Pink Chick.
Thanks for the speedly and helpful response. Your suggestion worked.
BTW: My initial analysis of which partitions were being mounted was incorrect. They ALL were not being mounted. I had not paid proper attention to the fact that although the kernel was being loaded (I have a standard devfs specification in grub's menu.lst), I had only watched the boot sequence without checking /etc/mtab (for example). On closer inspection, ALL SCSI partitions were unmounted. So I made changes in /etc/fstab for every SCSI drive partition description -- as apparently you did -- and udev worked without a hitch.
Thanks again for the timely and appropriate solution!
Regards,
Win
Offline
Once again, I installed archlinux on an scsi machine, and have been cought in the boot-scsi-device-fails-udev-trap. This time, I had a bit of time. Instead of editing the fstab entries, I decided to find out why ide devices are handled well, and scsi devices are not.
Have a look at udev.rules. You will find an entry for ide block deviced there, that creates devfs symlinks:
# ide block devices
BUS="ide", KERNEL="hd*", PROGRAM="/etc/udev/ide-devfs.sh %k %b %n", NAME="%k", SYMLINK="%c{1} %c{2}"
You will notice also there are no similar entries for scsi block devices. Therefore, their nodes will not fit devfs scheme. Now, let's have a look at /etc/udev/. You will find scsi-devfs.sh there. This script will create devfs-like nodes for scsi blocks. Now the problem is clear, isn't it. Add the following lines to udev.rules:
# scsi block devices
BUS="scsi", KERNEL="sd*", PROGRAM="/etc/udev/scsi-devfs.sh sd %b %n", NAME="%c{1}", SYMLINK="%c{2} %k %c{3} %c{4}"
BUS="scsi", KERNEL="sr*", PROGRAM="/etc/udev/scsi-devfs.sh sr %b %n", NAME="%c{1}", SYMLINK="%c{2} %k %c{3} %c{4}"
BUS="scsi", KERNEL="st*", PROGRAM="/etc/udev/scsi-devfs.sh st %b %n", NAME="%c{1}", SYMLINK="%c{2} %k %c{3} %c{4}"
BUS="scsi", KERNEL="sg*", PROGRAM="/etc/udev/scsi-devfs.sh sg %b %n", NAME="%c{1}", SYMLINK="%c{2} %k %c{3} %c{4}"
Now the devfs naming scheme should be used for scsi devices, too. Surprisingly, it isn't. Any hints are welcome.
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
Out of curiosity: doesn't this interfere somehow with the SATA drive settings... my partitions on the SATA drive are named sda*...
:: / my web presence
Offline
Out of curiosity: doesn't this interfere somehow with the SATA drive settings... my partitions on the SATA drive are named sda*...
Don't know. SCSI hds are normally named /dev/sda, /dev/sdb, /dev/sdc, ...
Sata was designed as a kind of cheap scsi fork, wasn't?
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
IceRAM wrote:Out of curiosity: doesn't this interfere somehow with the SATA drive settings... my partitions on the SATA drive are named sda*...
Don't know. SCSI hds are normally named /dev/sda, /dev/sdb, /dev/sdc, ...
Sata was designed as a kind of cheap scsi fork, wasn't?
I don't know about this... but all I can tell is that SATA drives work and they are named /dev/sda, /dev/sdb etc., without any change in the udev schemes.
:: / my web presence
Offline
Sata was designed as a kind of cheap scsi fork, wasn't?
No SATA was the first leap from parallel transfer to serial...
Here's more information than you need:
with normal drives, data transfer is parallel, meaning 8bits are transfered along 8 wires, 16bits over 16 wires, etc... this is why traditional drives have the big fat ribbon cable. Now, technically parallel is the fastest way to transfer data, however, increasing demands have made it so that with all the parallel wires and the transfer speed, there is too much electronic noise (static, basically) between the wires to allow anything beyond what we already have. With serial transfers (transfers over one or two wires, where each bit is sent in a times period... 1bit,1bit,1bit,1bit,etc) the speed is much slower (using parallel speeds for both, the serial transfer would take 8X as long as an 8bit parallel transfer) however there is no possibility for noise from adjoining wires. With this way, one can increase the transfter speed well over the parallel speed without interferance and produce better performance.
SATA is the first incarnation of serial transfers for discs, as the clock speeds for data transfer just made it viable, performance-wise.
Offline
... does not solve our problem ....
Frumpus ♥ addict
[mu'.krum.pus], [frum.pus]
Offline
Any update on this? It's causing me trouble too.
Offline
Pages: 1