Greetings: The original Mint setup was two 1.4 TB drives set up as /dev/sda and /dev/sdb at the time of install of the stand alone (no dual booting) Mint OS. The only things on the former /dev/sdb was what ever Mint put on it at the time of Install last year. It was in the machine because I had it, and it seamed a safer place to keep it in the computer than in a drawer in my desk.

The system you see is a new 931 gb drive with the new system loaded with mint, the 1.4 TB drive WAS the /dev/sda drive that is still good. The bad drive is out of the system entirely.
I think I mentined in the OP that I had removed both original drives, installed 1 new drive, set up Mint on that, and then put the still viable former /dev/sda back in as /dev/sdb that I wish to use.

You originally were asking how to access and rescue data from the drive which was going bad. Your last post indicates that you installed a new Mint OS on a new drive and have the older working drive attached and you no longer have the old failing drive attached. I'm not sure what the question/problem is now?

1 members found this post helpful.

i can only refer back to my previous post #9.
on a hunch, i don't think the data is lost at all, op just doesn't know how to access it.

1 members found this post helpful.

Greetings yancek: Please read the OP in full. I was not asking for ANY help with the BAD drive. I was asking for help recovering the stuff from the good drive which failed to boot after the bad one was removed. I installed a new copy of Mint from my original dvd on a seperate drive, then put the GOOD drive back in as a second to the new drive.
I can see the folders but have not found a way to access the actual information.

In response to post #9

^ what i thought, the files are all root owned.
you have, however, read permissions, so you can copy them to somewhere else.
if you want to modify them in place, you'll need elevated privileges (su, sudo etc.).

1 members found this post helpful.

Your output in post #20 shows what appears to be a separate boot partition. Don't know why you would want to save that. From the post #12 output, your largest partition (1.3TB) is sdb3 which I expect is your /home or data partition and would contain the files you want. Try mounting sdb3 from your new Mint and take a look to see if the files are there. Generally, you need root privileges to copy TO a partition but not FROM that partition.

If you have problems accessing, post any commands you run and their output.

1 members found this post helpful.

I'm a bit late to this topic. I would like to focus on what you wrote above.

1. Do you mount /dev/sdb with read/write privileges?
2. Inspect, at random, some files on /dev/sdb to examine the owner and privileges. You many need to issue a recursive chown command to match your user id and group to that on the new /dev/sda.
3. Have you inspected /dev/sdb (unmounted) with gparted to verify that there is no bootable partition?
4. Do you only have user data files on /dev/sdb. No system files and no system directories?

1 members found this post helpful.

Greetings Steve R.: While I have been on this board for a long time most of that time has been lurking. I finally got serious about switching over from the Dark Side (Windows) about a year ago, and because Mint seamed to be working so well for me I am coming to understand how out of touch I am with the inner workings of Linux.
To you questions

#1 Not sure how to go there.

#2 You Lost me at the Bakery!

#3 What I have seen is a partition that is marked as boot on a drive that will not boot on its own.

#4 The Quote from my post I think answers that "I put the former /dev/sda in the machine as /dev/sdb." Yes I am confident there are some system files and directory's on that drive.

I also alluded to the fact that I have been making my living working on Mechanical devices and therefor computers, Operating systems, etc, have been an on again / off again diversion for me.
I truly admire people who can maneuver around with a long list of Command line stuff on the top of their heads, I'm just not there yet.

Thanks..
Michael

it really isn't that hard, i suggest you get going and acquire just a little bit of command line fu.

it seems to me that you have a really simple problem, a misunderstanding even, about where your files are and how to get to them, that could be solved with the simplest commands.

my suggestion would be to leave the GUI for this one, and do everything via terminal.
once you rescued your files, we'll find a solution to use that internal hard drive "normally".

1 members found this post helpful.

Lets look at another approach based on the /dev/sda disk being fully functional, but missing some of you user data files.

1. How much free space is on your /dev/sda disk?
2. How much space is used by your user data files on the /dev/sdb disk?
3. If you add the free space on the /dev/sda disk to the space used by your data files on /dev/sdb disk, would there still be free space available on your /dev/sda disk? Should adding these amounts exceed the capacity of the /dev/sda disk, this proposed approach will not work.
4. Are all your user data files on the /dev/sdb disk under one directory? (They don't have to be, but it would be a lot easier.)

The reason for asking these questions is that there is a potential that you could copy all your data files to the /dev/sda disk. If that is the case, all your user files (NOT any system files) can be copied and your /dev/sdb disk would become redundant and could be eventually re-formatted at a later date. Obviously do not do anything to the /dev/sdb disk until you are satisfied that the /dev/sda disk is fully operational.

Assuming that you can copy all the user data files to /dev/sda disk, you may still need to use the recursive chown command. That can be discussed later, if needed.

1 members found this post helpful.

The above output from your post #6 shows what is your former sda drive which is now shown as sdb. If that is the drive from which you want to copy data FROM, you should be able to access any of the partitions from the new Mint by simply navigating to that directory. Although sdb3 is by far the largest partition, it and sdb1 have very little data on them as you can see (sdb1=38M; sdb3=37M). sdb1 appears to be a boot partition and sdb2 has 3.5GB of data on it. Navigate to "/media/michael/148c0eb9-e311-4904-bf25-842de0343b6a" in your file manager and you should be able to see the files you want.

Since the partition is accessible at that location, you should not need to mount again nor need write permissions as you simply want to copy data FROM that partition.

I'm not sure if that is all you want, are you hoping to be able to boot what is currently sdb since it appears to have the former OS on it, at least it has a boot partition. I see you tried running sudo update-grub earlier to try to get sdb included in the boot menu. Try running: sudo update-grub again from the newly installed Mint with sdb attached and watch the output.

The above quote is from your initial post. How are you trying to access these file and what happens when you try to copy them from that location.

1 members found this post helpful.

Is this issue still alive ?. If so, let's see the following output (use [code] tags, not [quote])
Have you done anything since creating this new system that you want to keep ?. Like bookmarks, passwords, new photos, that sort of thing ?. I'm thinking that large XFS filesystem on the old disk is going to be your old /home, and will have all your old data intact. We could just mount that, and carry on.
One proviso - did you create the same user when you built the latest system ?.Then again, maybe not - just noticed the usage. Try this command as well

1 members found this post helpful.

Greetings All: Thanks for all of the input! I found a way to copy what I want from the 1.5 t drive to the 1 t drive that is now my /dev/sda. In other words Problem solved!