[plug] Statically Mounting USB Drives

Gavin Chester gavin.chester at gmail.com
Wed May 28 12:57:43 WST 2008

On Wed, 2008-05-28 at 14:02 +1000, Daniel Pittman wrote:
> Gavin Chester <gavin.chester at gmail.com> writes:
> > On Wed, 2008-05-28 at 11:50 +1000, Daniel Pittman wrote:
> >
> >> Using a persistent name rather than a hardware name makes your system
> >> independent of that renumbering, and makes you happier in the long
> >> run.
> >
> > Not always :-(
> >
> > Initially ignorant of the new schema of persistent names, I had issues
> > with swapping drives and scsi controller cards earlier this year where
> > the whole system was unbootable because grub + fstab no longer saw _all_
> > and _exactly_ the same named drives that the system originally ran. 
> Sorry, I don't quite follow.  The way I read that is:
> You changed the order of drives and controllers, so changed the
> non-persistent (/dev/sd*) names.

In effect, yes ... I think. Going from a memory I tried to expunge ;-) I
had issues with scsi controller cards and drives so I was changing
things on an otherwise booting system. See below for more.

> You then had problems because grub and your fstab configuration didn't
> match what was expected, resulting in a non-booting system.


> > I decided that persistent naming was more trouble than worth, for me.
> You then decided that the problem that the persistent naming tools were
> intended to solve was more trouble than benefit.

For me, yes.

> > Now I have to remember to force non-persistent naming in my fstab
> > setup since opensuse has adopted it as default.
> So, now you carefully ensure that the same problem will occur again next
> time you change the order of detection.

No, as I understand it persistent names need the _same_ drive to allow
successful booting - and its purpose is just to overcome the order of it
all. I regularly setup systems with /home on a separate drive. Say, when
I swap the /home drive for another some time later, my understanding of
persistent names is that I believe this will mean failure to boot since
fstab entries refer to the drive name/code rather than its boot order.
But, I said I have nearly forgotten what my particular experience was
when dealing with this as a problem, so I may be wrong, in part ;-) 

> Clearly, my reading is wrong somewhere, because that interpretation
> really doesn't make much sense.  Can you clarify?

Hopefully the above will clarify.

> Oh, and it would be nice to know what the actual problem that caused the
> system to be unbootable was -- was it grub or the fstab related boot
> process that failed?  How, and why?  What did you need to do to recover
> that?

Well, grub only refers to what's in your fstab, so one follows the
other. If your fstab is locked into named drives (or in my case, the
serial number thingy of each drive as allocated by opensuse) then it
only works with those drives and nothing else. In my case (and for many
others I read online), the solution was to boot with a live distro and
edit my fstab and grub menu.lst to point to sda1, sdb1, etc instead of
each drive's unique name. That restored the booting. I've since done
fresh installs of other systems and have to manually override the use of
persistent names when configuring the fstab entries during partitioning
since opensuse uses it as default. 

> Given the description at hand I can't really comment one way or the
> other -- without any detail this is nothing but an assertion, and an
> unarguable one, because I don't doubt you had problems, but I don't know
> they had anything to do with the persistent device names.

Are you the maintainer of the udev/persistent name package/system,
because you seem terribly formal about me having bad experiences with it
persistent names? ;-) But, _yes_ my problem had _everything_ to do with
persistent naming since eliminating it manually (editing them out of
fstab) was the widely recommended solution to rescue my system. I hope
that provides all the answers you seek. It's jsut a case of an
'imposition' of a system management concept not being suited to everyone
and every case.   


More information about the plug mailing list