Using Fedora 7: Trouble Mounting a USB Attached Fedora 7 Drive

SysConWatch · 11-12-2007, 11:43 AM

Situation:
-I have two Fedora 7 machines.
-One of them has run out of hard drive space and will not boot.
-I want to retrieve some files from the full hard drive.
-I have attached the drive from which I would like to recover data via USB to my perfectly healthy Fedora 7 machine.
-Fedora 7 auto mounts just fine however only the "/boot" partition.
-I have made numerous attempts at manually mounting the slaved drive's root file system to no avail.
-I need to get to the "/var/lib/vmware/Virtual Machines" directory on the slaved drive.
-The device labels for the slaved drive are sdd, sdd1, and sdd2.
-The only really successful mount command that I've tried is:

# mount -t ext3 /dev/sdd1 /mnt

-This is exactly what the auto mount function in Fedora 7 does except it mounts under "/media".
-What I want is to mount the entire file structure on the slaved drive or at least the desired directory.

Question:
Is mount the way to go?
If so what is the string I am looking for?
Should I instead make some sort of addition to "/etc/fstab"?
Any help would be greatly appreciated.

SysConWatch · 11-12-2007, 12:42 PM

I've been looking at this wrong. Instead of trying to mount the device I should be trying to mount the slaved drive's VolGroup. The problem with that is both the system drive I'm running off of and the system drive I'm attempting data recovery from are both going to have the same VG name "VolGroup00". I'm slowly putting this together, and now I need to know:

1. How do I change the VG label of the drive I'm attempting data recovery from?
2. How do I make Fedora 7 aware of the USB attached VG?
3. With 1 and 2 answered and executed will the following command work?

# mount -t ext3 /dev/VolGroup01/LogVol00 /mnt

tredegar · 11-12-2007, 01:40 PM

I feel sorry for you. But welcome to LQ anyway

Things like "Virtual Machines" and "Volume Groups" scare the pants off me - I like to keep it all SIMPLE, and rather old-fashioned. Then when things go wrong, it's easy to fix, without all the layers of abstraction and virtuality. Maybe I'm just a linux-coward.

I wouldn't be posting this except you have already answered your own thread yourself (so it is no longer "zero-replies"), so I now view it as a free-for-all rather than "wait for someone who knows what they are talking about" to post the first answer. 'nuff said

If you are in a mess and a muddle, the best thing to do is boot from a "Live CD" distro. Knoppix is famous for this, and kubuntu does very well too, but there are others. Maybe even your own distro's disk will do this (I am not familiar with FC).

Boot and run from that live CD. Do not install. (It'll be a little slow to start applications, as you haven't installed it to a HDD, but no matter, we are desperate). Mount your problematic disk. Sort it out.
Unmount the disk. Reboot (without the CD).

Alternatively, you may be able to boot from the (nearly full - but some emergency spare space is always reserved for the root user, just in case this happens) HDD by choosing "Recovery Mode" from grub's (or lilo's) menu - this'll boot to a text terminal with root priviledges. You get no GUI, but you can fix things up from the terminal (I hope you know how to use a terminal editor like vi or even nano, and are familiar with bash basics).

You might be able to do something simple (eg rm -rF /usr/src/linux*) to free up enough space for you to be able to boot normally. You can always restore /usr/src/linux* (If you have made a note of what was there before you deleted it!) when you have migrated to a bigger disk, and you won't be needing it meanwhile, as you will not be installing any new software until this is fixed.

Oh and your mount command may break something unless you first create a mountpoint:

Code:

mkdir /mnt/mountpoint
mount -t ext3 /dev/VolGroup01/LogVol00 /mnt/mountpoint

But then I know nothing about VolGroups
Hope this helps.

SysConWatch · 11-12-2007, 03:03 PM

I wouldn't be playing with virtualization either, but I am new-ish to Linux (very limited experience over the past 3 years or so). I have been using IPCOP in that time for my gateway/firewall at home, and so I've become familiar to a point with the bash and using vi to edit config files and such.

I've been wanting for sometime to migrate to Linux completely and break my addiction to Microsuck, but unfortunately I can't afford the major loss in productivity that would result from going cold turkey.

I could just as easily have done a dual boot system, but I didn't like the idea of having to reboot every time I wanted to switch between the two. Not to mention that one of these machines is located at my place of employment which is itself a Microsuck addict as well.

As for the subject of the thread I did go ahead with a reinstall of the full drive and booted to the FC7 Rescue CD. From there my bash session went like this:

Code:

# lvm vgscan
Reading all physical volumes.  This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
# lvm lvscan
inactive           '/dev/VolGroup00/LogVol00'  [35.19GB] inherit
inactive           '/dev/VolGroup00/LogVol01'  [1.94GB] inherit
# lvm vgchange -an
0 logical volume(s) in volume group "VolGroup00" now active
# lvm vgrename VolGroup00 VolGroup01
Volume group "VolGroup00" successfully renamed to "VolGroup01"

NOTE: I told the recovery console NOT to mount the drive prior to entering the command line...I'm not sure why, but this was probably important since I was following instructions from http://www.linuxquestions.org/questi...-to-do-375928/.

Now I will take the HDD back to my home PC, hopefully mount it and recover my Virtual Machine named "VIRTWINXPPRO". I will be sure to post how that goes.

SysConWatch · 11-12-2007, 04:35 PM

I reconnected the full HDD via USB to my home PC. I made sure that the drive was connected and powered on prior to booting FC7 so that the attached drive's VG would be registered by FC7 the first time, and it was. Sure enough there it was in "/dev/mapper". I then went to the command prompt and experienced the following:

Code:

[root@FEDORA7BOX ~]# mount -t ext3 /dev/mapper/VolGroup01-LogVol00 /mnt/FULLHDD/root
mount: wrong fs type, bad option, bad superblock on /dev/mapper/VolGroup01-LogVol00,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so

[root@FEDORA7BOX ~]# dmesg|tail
usb 3-5: reset high speed USB device using ehci_hcd and address 4
usb 3-5: reset high speed USB device using ehci_hcd and address 4
usb 3-5: reset high speed USB device using ehci_hcd and address 4
usb 3-5: reset high speed USB device using ehci_hcd and address 4
usb 3-5: reset high speed USB device using ehci_hcd and address 4
sd 4:0:0:0: [sdd] Result: hostbyte=DID_ABORT driverbyte=DRIVER_OK,SUGGEST_OK
end_request: I/O error, dev sdd, sector 228085
JBD: Failed to read block at offset 300
JBD: recovery failed
EXT3-fs: error loading journal.

So who wants to confirm for me what I already expect? I'm thinking the drive is too full and cannot be read without additional data recovery utils. If this is the case I'm just going to burn it down and rebuild it. I was just trying to save myself the trouble of rebuilding the Virtual Machine stored on it and had expected to put a new more paired down image of FC7 on it anyway so as to not have this problem again.

A better solution would be to go with a bigger drive in round 2, but for those who are wondering, my boss already told me I can't upgrade the machine. =( So much for forward thinking.

tredegar · 11-12-2007, 05:11 PM

Woah!
You posted a problem. OK
You then answered your own thread within 60 mins. Hmmmm OK.
I tried to help you by giving you some suggestions within an hour of your last post.
Meanwhile, you have apparently gone ahead and reinstalled:

Quote:

As for the subject of the thread I did go ahead with a reinstall of the full drive and booted to the FC7 Rescue CD

If you keep jumping around and changing major things (a reinstall) this fast, I don't think anyone here can keep up with, or help you

I appreciate that it is very annoying when you can't get things to work but ... .. .
Maybe just slow down, and relax a bit?

One step at a time perhaps?

I suspect that you are perfectly capable of solving this issue yourself. If not, then when you have finished banging your head against the wall, and perhaps waited a day for the headache to subside, come back, someone will have sensible advice for you

SysConWatch · 11-12-2007, 06:15 PM

Sorry I should'ved said physically reinstalled the drive. I didn't perform a reimage. All the data was still intact when I changed the vg of the "full drive" (un-bootable drive), and yes you are right I do need to slow down. Believe it or not I make a living as an IT Field Service Technician.

I should know better than to get ahead of those who are providing support, but I get excited when I learn new things.

Maybe I was able to solve this on my own, but I think it took typing my thoughts out to get them organized enough to think it through. I do have to give you (tredegar) credit for suggesting the rescue/live CD boot and encouragement for sure. I also did use your suggestion of creating a mount point so as not to break anything.

Also maybe I should've mentioned this is my first time posting to any forum, and I do apologize if I'm frustrating anyone trying to help me. For instance I tried that mount command once, and it ran for 5 minutes or more before failing. I viewed the log of the attempt and drew conclusions. Now only a few minutes ago I gave it another try for good measure with the -v option and it completed immediately. I'm sure the -v was NOT the key but the mount worked and I don't know why.

Code:

[root@FEDORA7BOX ~]# mount -v -t ext3 /dev/mapper/VolGroup01-LogVol00/mnt/FULLHDD/root
/dev/mapper/VolGroup01-LogVol00 on /mnt/FULLHDD/root type ext3 (rw)

With that mountain scaled...I am now teaching myself proper use of the cp command in order to copy the files I'm after. This should be good