Thank you Tim.
I just keep learning new stuff all the time. I love linux. There is so
much to it and it has so many possibilities. I have friends to whom I
mention linux and they just look at me funny. One person, when I
mentioned to him about the command line, he said, "You mean like DOS?"
and I said yes but much more powerful. He told me he loved DOS and
hated having to change over to the GUI but now that he's gotten used to
the GUI, he doesn't really want to go back. Oh well.
I don't envy you having lost a mobo. I've lost three since I have been
using linux and it's always interesting to rebuild my box(es). Haven't
lost a hd (fingers crossed) in years but this last time when my mobo
went out all there was available was 64 bit and while I knew I could use
it as a 32 bit I decided to jump in and figure out how to set up AMD64.
It's been fun and interesting. I know that Squeeze is out now and
assume it's 32 bit and am waiting for the new 64 bit AMD setup to come
out. I know they've made some big changes between 5 and 6 so it will be
interesting.
I'll let you go. Thanks again for your help. Much appreciated.
Whit
Tim Holloway wrote:
Hi Whit,
UUIDs are long, nasty, and non-intuitive. Their only saving grace is
their uniqueness. When it absolutely, postively MUST be exactly
such-and-so... well, a UUID won't guarantee that, since it's basically a
hash code. But it's a hash code with an astronomically high likelihood
of not being mistaken for anything else.
My main use of UUIDs has bee in cases where I'm attempting to recover a
hard drive from a failed system. Since I'm usually using LVM and the
Fedora/RedHat default volume group ID is Volgroup00, the LVM resource
manager can get confused and so can I. So I rename the incoming volume's
group ID by using its UUID.
LABEL= is best when you want something like your Home directory and you
don't care that it keeps moving around as you push it onto larger and
larger disks. The UUID would change, but the filesystem label wouldn't.
As to "what's with the [SPAM]" indicators, well, the motherboard of the
VM host that contains my mailserver had a catastrophic failure. I was in
a rush, so I built a whole new mail VM appliance from scratch, but the
spam filters are still getting trained!
cheers,
Tim
On Tue, 2011-02-08 at 18:58 -0500, Whit Hansell wrote:
Hey Tim and Dan,
Thanks for your replies. I had seen in my search that UUID's and
LABELS could be used but it made no sense to me at the time that it
would be any different from /dev/sdd2 which is what the device is called
originally. But when you mentioned it I thought what the heck and I had
also put the same post to Leaplist in Orlando and got basically the same
type of replies. So, am using the LABEL= lbakup for the device name and
rebooted and it held the mount point OK. So am staying w. that for
right now. I had read that the UUID is very unique and basically
impossible to have a duplicate of but it is so goofy looking and I'm the
only one playing w. this mess I figured the LABEL= situation would work
fine. Thanks a bunch for the replies.
You mentioned "hardwiring the USBdevice ID's" and I had been thinking
about how to possibly do that but then thought as you mentioned, how
would it react/how would things work out if I put in my various USB
storage devices to different USB ports. Nah! not going to mess with
it. I can work w. the sticks as I need them and where they end up.
Again, thanks a bunch for your help. I really appreciate it.
I do have a question tho'. What's w. this [SPAM] deal in the subject
line? Am I spam? Really? ;-)
Whit
Tim Holloway wrote:
Yep. Red Hat used to setup systems where "LABEL=/1" was the root mount
point. I think they've dropped the habit, now. I know I got into fights
with it trying to make an initrd on an LVM volume, although that wasn't
really the fault of the label.
It's a matter of taste which option to use. However, as a general rule:
UUID is when it absolutely, positively must be this, and only this
instance of the filesystem. As my old OLE book once said about their MS
relatives, GUIDs, "the chances of two items having the same GUID are
about the same as a bunch of atoms rushing together in space to form a
small walnut". :)
Labels are good when it's the semantics that count. If, for example when
you really truly /want/ a "/HOME" partition or the like. Labels are not
unique, however, and I'd have to RTFM on how conflicts are resolved.
Hardwiring USB device IDs is fairly simple, but problems can arise if
the devices are plugged in differently. You can tie IDs to specific
peripherals irrespective of the port the device is plugged into, since
the mechanism is quite flexible, including the ability to incorporate
user-defined scripts. However, unless the hardware itself has some
unique property, I wouldn't recommend it. This is for keeping track of
which device is /dev/dvdrw1 and /dev/dvdr2 and stuff like that.
On Tue, 2011-02-08 at 09:18 -0500, Dan Bidleman wrote:
if using ext fs, you can use e2label and in the fstab you put
LABEL="drive_name" as the device
To do UUID as mentioned below:
just check your blkid by querying the partition using blkid as root:
# blkid /dev/sda1
/dev/sda1: UUID="280cebd3-f655-df94-cb20-1669f728008a"
TYPE="linux_raid_member"
then in fstab use UUID="your_uuid_output" as the device
On 02/07/11 16:20, Tim Holloway wrote:
Yep. Mount on the filesystem's UUID instead of the device name.
On Mon, 2011-02-07 at 16:00 -0500, Whit Hansell wrote:
Hey guys. Picked up an external drive a few days ago and set it up just
fine. Using AMD64 Lenny on Assus board. External drive is a bakup
drive w usb connection and separate p/s.
Have two hd's on box plus this external drive. Use linux on one hd, XP
on a separate drive and reboot back and forth on occasion as needed.
Partitioned new external to reduce Windows partition and add Linux
partition. All works fine. No problemo' there. No problemo' w. other
situation either.
But where I am having problem is that when I come back into linux from
XP, a restart from XP, linux changes the mount point on my usb various
drives, externala and stick drives which are also attached.
Am using rsync in a script I wrote and so when I want to backup it's
easy, except now the mount point is different.
Is there any way to lock in the mount point on the external drives by
editing a file somewhere? I've googled all over and all I can find is
people having problems with the name being changed, not the mount
point. The name in fstab is the same (/dev/sdd2) and the drive info.
AMD64 automounts the drive and sticks an icon in the tray automatically
on bootup but, again, changes the mount point so when I try to run my
sccript, it's no longer looking at the correct usbport. I am not
moving the drives at all. The system is changing the usb port names on
reboot all by itself. Usb0, Usb1,Usb2, etc.
I assume someone has added an external usb drive and had the same
problem and am just wondering how you solved it. Thanking you in
advance for any help.
fstab entry:
/dev/sdd2 /media/usb0 ext3 user,noauto,rw 0 0
script lines:
#/bin/bash
rsync -vrlptg --delete /home/whit/ /media/usb0/home/whit
Again, this worked fine before my reboot, but now the drive /dev/sdd2
is on mountpoint /media/usb1, not /media/ usb0.
gracias amigos, por favor.
Whit
---------------------------------------------------------------------
Archive http://marc.info/?l=jaxlug-list&r=1&w=2
RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml
Unsubscribe [email protected]
---------------------------------------------------------------------
Archive http://marc.info/?l=jaxlug-list&r=1&w=2
RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml
Unsubscribe [email protected]
---------------------------------------------------------------------
Archive http://marc.info/?l=jaxlug-list&r=1&w=2
RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml
Unsubscribe [email protected]
---------------------------------------------------------------------
Archive http://marc.info/?l=jaxlug-list&r=1&w=2
RSS Feed http://www.mail-archive.com/[email protected]/maillist.xml
Unsubscribe [email protected]
