SCIENTIFIC-LINUX-USERS Archives

December 2013

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Konstantin Olchanski <[log in to unmask]>
Reply To:
Konstantin Olchanski <[log in to unmask]>
Date:
Mon, 9 Dec 2013 12:24:48 -0800
Content-Type:
text/plain
Parts/Attachments:
text/plain (100 lines)
On Mon, Dec 09, 2013 at 03:11:22PM -0500, John Lauro wrote:
> If you want deterministic assignments, and things do not always start in the same order, you just need to setup rules.
> 
> http://www.reactivated.net/writing_udev_rules.html
> 
> and then you can use /dev/sda1, etc... in fstab.
> 


You posted a link to instructions from 2008. (today is 2013, tomorrow 2014).

I have to maintain udev rules for "chmod a+wr /dev/ttyUSB*".

In SL4, the above command in /etc/rc.local was sufficient (5 minutes of work)
In Sl5, I had to write udev rules and I read the udev documentation
and I found it useless, internet examples useless, finaly by groping around
I cobbled some rules that worked (2 days of work).
In SL6, those rules stopped working (2 days of work to figure out new rules)
In SL7, I full expect udev to be replaced with vdev, wdev, xdev, with equally useless documentation.

So thanks, but no thanks.

For disks, the solution is to use UUID and labels.

(For /dev/ttyUSB* the solution is to write application code that gropes around
inside /proc/ and /sys/ to figure out which /dev/ttyUSB node is which hardware
devices - we use them in multiples).

(For network devices the solution is "persistent network names" which makes
your machine unusable if you replace the network card, the mobo, or move
the disks to a spare machine - it binds eth0 to a specific MAC and records
this binding in a secret place. If MAC changes, eth0 becomes eth2 and ifcfg-eth0
no longer works. Clearly, this was well throught through).


K.O.



> 
> 
> ----- Original Message -----
> > From: "Konstantin Olchanski" <[log in to unmask]>
> > To: "ToddAndMargo" <[log in to unmask]>
> > Cc: "Scientific Linux Users" <[log in to unmask]>
> > Sent: Monday, December 9, 2013 2:58:27 PM
> > Subject: Re: Finally figured out what is causing bug 836696
> > 
> > On Mon, Dec 09, 2013 at 11:35:03AM -0800, ToddAndMargo wrote:
> > > 
> > > Bug 836696 has been driving me nuts for years.  This is
> > > where you drop to fsck on boot for the backup drive,
> > > but you can't do anything with the drive when you get
> > > to maintenance mode.
> > > 
> > > And, I finally figured out what is causing this.  My
> > > OS and my backup drive's devices are randomly reversing
> > > themselves at boot.  For details, see comment #37:
> > > 
> > >     https://bugzilla.redhat.com/show_bug.cgi?id=836696#c37
> > > 
> > > Hope no one else has to figure this one out the hard way,
> > > as I did.
> > > 
> > 
> > Doh! This linux "feature" bites rookie and wizard all the same.
> > 
> > Linux assigns the sdN names in the order that devices are discovered
> > and this order is not deterministic - SCSI, SATA and USB may all be
> > scanned
> > at the same time mixing up all the names each time. Mr. Torvalds
> > cares
> > about this not one bit, he has only a single drive inside his mac air
> > and no usb ports to accidentally confuse things by leaving a usb
> > drive
> > connected during reboot.
> > 
> > Therefore, on linux, you cannot put "/dev/sda1" & co into /etc/fstab.
> > You have to mount filesystems by UUID or by label. This was true and
> > worked quite well for ages now. (Even with IDE disks, the /dev/hda,
> > /dev/hdb, etc
> > assignement was not super fixed - it depended on the order that IDE
> > host adapters were initialized and this order has been known to
> > change
> > between different linux releases).
> > 
> > --
> > Konstantin Olchanski
> > Data Acquisition Systems: The Bytes Must Flow!
> > Email: olchansk-at-triumf-dot-ca
> > Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3,
> > Canada
> > 

-- 
Konstantin Olchanski
Data Acquisition Systems: The Bytes Must Flow!
Email: olchansk-at-triumf-dot-ca
Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada

ATOM RSS1 RSS2