Re: [tlug] Trouble with external USB hard disk

["Stephen J. Turnbull" <stephen@example.com>]

David Bernat writes:

 > root@example.com:~# mount
 > /dev/sda1 on / type ext3 (rw,relatime,errors=remount-ro)

Note that this *is* rw, not ro, so your internal hard drive (partition
1) mounted successfully.

All of the others are virtual file systems that present various system
facilities as if they were files, and are not directly relevant to
this situation.  Your external hard drive is nowhere in sight; I
suspect that if you look at dmesg (and/or /var/log/syslog,
/var/log/messages, /var/log/kern.log, or something along those lines)
you will see that failed mount recorded in the log.

 > > > and ls -l /etc; ls -l /root; Are they empty?

Given the information above, the output you present is not surprising
since /dev/sdb* haven't been mounted onto /etc and /root.

 > root@example.com:~# ls -l /root
 > total 4
 > -rw-r--r-- 1 root root 2970 2008-10-06 21:42 gparted_details.htm

This is where you (or somebody) looked up documentation for gparted a
couple of weeks ago.  Are you sure you've *never* played with
/etc/fstab yourself?  Not even back in the days of "Addled Arthropod"
or whatever it was?

 > > > You should type "man mount" for list of filesystems that mount supports.
 > > > Here we mount
 > > > mount -t vfat /dev/sdb1 /etc

Good grief, what *were* we thinking??  50 lashes with an udon noodle!

We do not want to mount something on /etc without checking to see if
/etc is already populated with the system configs!  No standard system
will try to do something like this because of the trouble it causes
with mount (cf the error messages about /etc/mtab and /etc/mtab~) and
user identification (cf the error messages from sudo).

 > root@example.com:~# mount -t vfat /dev/sdb1 /etc

*You* in particular don't want to do that.  What you *know* at this
point is that /etc (on /dev/sda1) is populated with lots and lots of
stuff (which looks pretty familiar to the experienced eye).  Mounting
something on to /etc will actually hide all that stuff.  (What "mount
... /etc" does is cause the kernel to believe that the entity at /etc
is *not* a directory, but rather a device that contains a file system,
and instead of the directory on disk, the kernel should look in the
root directory of the mounted file system for whatever it's after.
"mount" does not care if there's anything already there.[1])

 > can't link lock file /etc/mtab~: Operation not permitted (use -n flag to
 > override)

This is a confusing error, almost certainly due to the fact that
you've just mounted /dev/sdb1 in a place that will interfere with the
kernel finding /etc/mtab~ and /etc/mtab (into which it would like to
write the information about mounted filesystems, which it just
changed).  The mount was successful, but now you have a broken system,
because (as Ken B pointed out, IIRC) just about everything of interest
stores config and sometimes status information in /etc.

Once more, don't do that.

 > root@example.com:~# mount -t vfat /dev/sdb1 /etc -n
 > mount: /dev/sdb1 already mounted or /etc busy

See?  Already mounted.  I'm mildly surprised you didn't get a syntax
error for that trailing "-n", but whatever....

What you almost certainly want to do now is delete the lines

/root/sdb5 /root auto users,atime,noauto,rw,nodev,noexec,nosuid 0 0
/dev/sdc1 /home auto users,atime,auto,rw,nodev,noexec,nosuid 0 0
/dev/sdb1 /etc auto users,atime,auto,rw,nodev,noexec,nosuid 0 0

from /etc/fstab (you'll need to be root), and add

/dev/sdb1 $SOMEDIR auto users,atime,auto,rw,nodev,noexec,nosuid 0 0

where $SOMEDIR is an appropriate place to put the contents of your
external drive.  Possibly /home, if there's nothing in it right now.
If you find you are missing some data, it's probably in /dev/sdb5.
To find out, do

mkdir /tmp/foomnt
mount -t auto /dev/sdb5 /tmp/foomnt

and if that succeeds, you can do

ls /tmp/foomnt

to find out what's in the file system, if anything.  Then figure out
where to put it in the file system and add an appropriate line to
/etc/fstab to make it happen, then

umount /tmp/foomnt
rmdir /tmp/foomnt
mount /dev/sdb5

If it doesn't succeed, then you probably don't have a partition 5 on
the external hard drive.

 > Hardy had no trouble mounting the disk prior to the upgrade last week.
 > What broke in the upgrade? Anybody know?

I don't "know", but I have my suspicions.  Let me put it this way:

I recommend you should *not* report a bug against Hardy, unless a
search of the bug tracker shows that somebody else has reported a
similar experience, or you can be a lot more specific about how Hardy
led you down the garden path.

Footnotes: 
[1]  Mounting over a directory with non-null contents turns out to be
occasionally useful, and mounting file systems is something that is
rarely enough done that it's unlikely to cause confusion in a
well-configured system ... which yours isn't at this point.