On Mon, 09 Jun 2014 11:43:33 +1000, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
Hi Terry,
[snip]
I suspect that there must be a file or files, other than /etc/fstab, that have stuff relating to the old disc, and if this is the case is moving a volume group going to have the same problem?
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.
You still need to be able to boot, so wherever the boot files are, they need to be handled. You'll probably have a standard MBR type partition table too, no GPT to worry about.
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. It is all on a new MB, hence the new install to the SSD was GPT and the boot was all OK until I copied my old / across. /boot was on a separate partition so none of that was monkeyed with on the SSD. The reason I copied / across, after the new install, is that the updates to get to my current setup plus all the additional packages would be horrendous. I did update the kernel on the SSD first, that was necessary to see the wired network, and that booted OK.
Hope that helps somewhat at least ;-)
Don't think so :-( I'll keep searching for clues. The way Google seems to work these days one has to be quite enlightened to figure out the right search string to get an answer that helps. Thanks for your help. Cheers, -- Regards, Terry Duell