-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
lee wrote:
> On Tue, Nov 18, 2008 at 01:22:21AM +0200, Andrei Popescu wrote:
>> On Sat,15.Nov.08, 13:41:15, lee wrote:
>>
>>> It might work on the first
>>> and second and fifth reboot and suddenly stop working, leaving him
>>> with an unbootable system and no clue what might have gone wrong.
>> AFAICT recent versions of the installer uses UUID for fstab.
>
> That would be much better. I'm probably going to run into trouble once
> I get the cable to connect my SCSI disks since there is no way to tell
> in which order disks will be detected :(
>
> What do you do with entries like this in /dev/disk/by-uuid/:
>
>
> lrwxrwxrwx 1 root root 9 2008-11-25 10:13
> 3c8489c2-b7c8-413c-aa3d-5940a7e9ec00 -> ../../md0
> lrwxrwxrwx 1 root root 10 2008-11-25 10:13
> 450494c6-3adc-4180-8365-60b6bfe57ca3 -> ../../hda8
> lrwxrwxrwx 1 root root 9 2008-11-25 10:13
> 562ca497-de85-4724-ae7d-9896ba42d753 -> ../../md1
>
>
> Put the long number into /etc/fstab instead of /dev/md1? And what
> happens when a disk is repartitioned?
>
> And why don't all of the disks show up? md1 is made from partitions on
> two SATA disks, /dev/sda2 and /dev/sdb2, but neither the disks
> (/dev/sda, /dev/sdb), nor their partitions (three on each) show
> up. Once I connect the SCSI disks, there will be three more
> /dev/sdX--- are they going to show up? How do I prevent the system
> from messing up the disks?
You can get udev to name things (pretty much) the way you'd like. I
wrote a 10-local.rules udev ruleset (with lots of notes to myself for
next time):
> # These rules are very specific to a system containing a single SCSI system
> disk and a pair of SATAs in a RAID
> # for data, like the servers at slsware.com. They are intended to be used
> in the initrd as the system boots.
> # The only thing hardware specific is the "DRIVERS" key. It must match a
> DRIVERS line in
> # 'udevinfo -a -p /sys/block/sd<n> | egrep DRIVERS'. It must be there,
> though -- it's how we tell the difference
> # between SCSI and SATA drives.
> # They force the SCSI to be sda, with SYMLINK sysDisk, always, and the SATAs
> to be sdr and sds, with SYMLINKS
> # dataDiskA & B, depending on the order they show up at udev.
> # There must be rules for all of them because, as this is being written,
> SATAs show up before SCSIs, and they
> # tend to get sda. This is not good because the Debian installer uses the
> /dev name in fstab.
> # Check these out with 'udevadm test /block/sd<n>'. When you're sure they
> work, 'update-initramfs -u' and reboot.
>
> # we are only interested in add and change actions
> ACTION!="add|change", GOTO="slsware_rules_end"
> KERNEL!="sd*", GOTO="slsware_rules_end"
>
> SUBSYSTEM=="block", ENV{SLSWARE_DISK_TYPE}="UNDEFINED"
> SUBSYSTEM=="block", DRIVERS=="aic79xx", ENV{SLSWARE_DISK_TYPE}="SCSI"
> SUBSYSTEM=="block", DRIVERS=="ata_piix", ENV{SLSWARE_DISK_TYPE}="SATA"
> SUBSYSTEM=="block", DRIVERS=="usb", ENV{SLSWARE_DISK_TYPE}="USB"
>
> # the SCSI systemDisk
> ENV{SLSWARE_DISK_TYPE}=="SCSI", TEST!="sda%n", NAME="sda%n",
> SYMLINK+="sysDisk%n"
> # the (identical) RAID data disks -- they have the same number of partitions,
> so this will work
> # (if the first one had 3 and the other had 4, the other's #4 would be
> called sdb4 instead of sdc4...)
> ENV{SLSWARE_DISK_TYPE}=="SATA", TEST!="/dev/sdr%n", NAME="sdr%n",
> SYMLINK+="raidDiskA%n", OPTIONS+="last_rule"
> ENV{SLSWARE_DISK_TYPE}=="SATA", TEST=="/dev/sdr%n", NAME="sds%n",
> SYMLINK+="raidDiskB%n", OPTIONS+="last_rule"
>
> # if USB rules aren't here, and one is connected at boot, udev and the kernel
> render the system un-bootable
> # the (current) USB stick
> ENV{SLSWARE_DISK_TYPE}=="USB", ATTRS{model}=="IntelligentStick",
> NAME="sdusbStick%n"
> # Anything else USB
> ENV{SLSWARE_DISK_TYPE}=="USB", NAME="sdusb%k%n", OPTIONS="last_rule"
>
> # end of processing
> LABEL="slsware_rules_end"
This sucks, but it works, and things are at least somewhat stable and
predictable. There's a way to get the serial numbers, to be able to tell
the SATAs apart, but I couldn't get it to work. mdadm builds its arrays
using UUIDs, I think, so it doesn't matter much, at least for my 2
element RAID1...
I install with only the SCSI in the machine, activate a SATA and get the
DRIVERS key from udevinfo, edit the rules, rebuild initramfs, reboot,
and build the RAID array.
And many of the 'legacy' CL programs don't use the names udev creates
(mdadm is one). And some do.
- --
Glenn English
[EMAIL PROTECTED]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkkuHxQACgkQ04yQfZbbTLbdLQCgjxZ6qWK3UmyZdWg+rXVTQBEq
xbgAn1atOZKmc9kZZ60YP5ttP/ZgtZIJ
=vfXf
-----END PGP SIGNATURE-----
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
