Post by leePost by leeIt 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 :(
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
Post by lee# 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
***@slsware.com