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 ... ???? Now I have two questions: - 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 11:35 PM, Chris Murphy <li...@colorremedies.com> wrote: > On Wed, Jan 21, 2015 at 2:15 PM, Rick Stevens <ri...@alldigital.com> > 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@lists.fedoraproject.org > 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@lists.fedoraproject.org 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