thanks for your answers
I explain better .....
recently I started
with Linux and, as a beginner, I
made many mistakes that forced me to reinstall many
times, both fedora
that all the SW already installed.
That
is the way
I decided to
“invest some
time” with clonezilla in order to prevent
the possibility that these problems occurs
again.
Actually I made a clone with the image of the HD where is installed fedora and now I am doing some tests in order to know very well how much this clone is reliable and which are the possibilities that I can use it for recovering my system ...
I took the image of the all HD (I used a new HD witjh 1 TB capacity).
I know (for trying it) that with the clone I can perform good
recovery when I use it on the same disk from which the image was
taken.
However trying to restore on a different (new and virgin)
Hard Disk, the operation fails.
When I I restore on a virgin HD the computer (after the grub message to choose the OS), loads fedora only in recovery mode ....
Having no experience, I can not be sure that the
recovery from a clone can be made on a new
virgin HD .. and this is the reason why I
posted this question .
I can say that when I connected (on the computer) the virgin HD with the same cables that was connected the old HD it was detected with different values:
/dev/sda if the original
/dev/sdc if the HD is the new (the virgin one)
Could this be, perhaps, be the cause of the problem ... ????
It is possible to restore the clone on any (different) HD or it is possible restore it only on the one HD from where the image was toke?
if the restore can be done to any HD, ...how I can manage the change of symbol attributed to HD?
On Wed, Jan 21, 2015 at 2:15 PM, Rick Stevens <ricks@xxxxxxxxxxxxxx> wrote:
> We do need more info other than "the clone operation failed". I have
> cloned a large number of machines using Clonezilla using virgin drives
> (CentOS, Fedora, Ubuntu, Winblows). Many had the target drives larger
> than the original. I will say that they all used fdisk-style partition
> tables, though (no GPT tables).
Yeah and it's a minor problem for the backup GPT to be in the wrong
location, that alone wouldn't cause boot to fail unless the primary
GPT were hosed somehow. The primary header points to the LBA of the
backup header, which would still be valid if you had used something
like dd or ddrescue. The problem is that if the primary header is
hosed (missing, totally corrupt or checksum fails), a tool will assume
the backup is at the end of the drive but won't find it there.
Unless that tool is the kernel. Funny enough, the kernel itself right
now doesn't fallback to the backup GPT if the primary one is corrupt.
Instead boot fails. Not cool! [1]
[1]
mishandled corruption of primary GPT table, failure to boot
https://bugzilla.kernel.org/show_bug.cgi?id=63591
--
Chris Murphy
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
