Hello Andrew, On Mon, 09 Jun 2014 13:06:26 +1000, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
Hi Terry,
On 9/06/2014 12:00 PM, Terry Duell wrote:
On Mon, 09 Jun 2014 11:43:33 +1000, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
How about doing this:
blkid -c /dev/null
That will list all the partitions, then change the /etc/fstab with UUID entries, then it won't matter which disk the partitions are on.
The /etc/fstab has UUID entries.
So the UUIDs match properly? Whenever you create a file system, it will get a new UUID value generated.
Yes. The UUIDs in the SSD /etc/fstab were generated during the fresh Fedora install and match those returned by blkid, so I don't think there is an issue there.
I think it boots, as I don't think I would get to the login prompt, but it keeps returning to the prompt. I have checked user:group stuff (/etc/group) and that is the same for both discs.
Strange about the login situation.
When you copied / .... how did you do that exactly? I'm thinking that there are permission issues with files if the copy wasn't done correctly. /etc/shadow for instance needs specific permissions (640 owned by root:shadow).
I was booted into my old disk, and the SSD was mounted as (something like) "/run/media/terry/xxxx...", and I used rsync as follows; "sudo rsync -av I was booted into the SSD and had my old / partition mounted, can't remember exactly but something like "/run/media/xxx...", and I think I used rsync as follows; "sudo rsync -av /run/media/xxx/ /"
If the user id number(s) have changed, then you might have issues with incorrect owner for the homedirs.
Do you mean the numbers for user:group that are in /etc/group? Both systems have me (user terry) as 1000:1000. I think it is a permission issue, I have just found (on the SSD, the one which keeps returning to login) that "~/xsession-errors" says "Failed to run command: Permission denied", and that's all, no clue as where that permission error is. Cheers, -- Regards, Terry Duell