Thread: [Clonezilla-live] UEFI/GPT systems?
A partition and disk imaging/cloning program
Brought to you by:
steven_shiau
From: Les M. <les...@gm...> - 2013-06-12 21:57:22
|
I used clonezilla-live 2.1.1-25 to clone a CentOS6.4 installation on IBM x3550M4s. The resulting copy won't boot but appears to be correct when booted from an install DVD in rescue mode. I'm not very familiar with either UEFI systems or GPT partitioning. Is there some quick-fix to reinstall grub from the rescue disk (the obvious 'grub-install /dev/sda' went through the motions but didn't fix it), or a way to have it work with clonezilla? -- Les Mikesell les...@gm... |
From: Steven S. <st...@nc...> - 2013-06-16 11:49:45
|
What was the error messages when grub failed to boot? BTW, did you try to use CentoS 6.4 installation CD to do grub-install? Steven. On 06/13/2013 05:57 AM, Les Mikesell wrote: > I used clonezilla-live 2.1.1-25 to clone a CentOS6.4 installation on > IBM x3550M4s. The resulting copy won't boot but appears to be correct > when booted from an install DVD in rescue mode. I'm not very > familiar with either UEFI systems or GPT partitioning. Is there some > quick-fix to reinstall grub from the rescue disk (the obvious > 'grub-install /dev/sda' went through the motions but didn't fix it), > or a way to have it work with clonezilla? > > -- > Les Mikesell > les...@gm... > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by Windows: > > Build for Windows Store. > > http://p.sf.net/sfu/windows-dev2dev > _______________________________________________ > Clonezilla-live mailing list > Clo...@li... > https://lists.sourceforge.net/lists/listinfo/clonezilla-live > -- Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org> National Center for High-performance Computing, Taiwan. http://www.nchc.org.tw Public Key Server PGP Key ID: 4096R/47CF935C Fingerprint: 0240 1FEB 695D 7112 62F0 8796 11C1 12DA 47CF 935C |
From: Ersek, L. <la...@ca...> - 2013-06-16 13:56:52
|
On Sun, 16 Jun 2013, Steven Shiau wrote: > What was the error messages when grub failed to boot? > BTW, did you try to use CentoS 6.4 installation CD to do grub-install? > > Steven. > > On 06/13/2013 05:57 AM, Les Mikesell wrote: >> I used clonezilla-live 2.1.1-25 to clone a CentOS6.4 installation on >> IBM x3550M4s. The resulting copy won't boot but appears to be correct >> when booted from an install DVD in rescue mode. I'm not very >> familiar with either UEFI systems or GPT partitioning. Is there some >> quick-fix to reinstall grub from the rescue disk (the obvious >> 'grub-install /dev/sda' went through the motions but didn't fix it), >> or a way to have it work with clonezilla? The disk contents was probably restored just fine, but, in order to automatically boot from fixed (ie. non-removable) media, you must add a Boot#### non-volatile UEFI variable (= a boot option) and reference it in the BootOrder variable. See "3.1.1 Boot Manager Programming" in the UEFI 2.3.1+errC specification. These variables are stored in system flash, and all UEFI OS installers (eg. Anaconda for RHEL, Fedora, CentOS) must set them. I assume clonezilla doesn't save them in the backup image. Laszlo |
From: Les M. <les...@gm...> - 2013-06-17 16:28:54
|
On Sun, Jun 16, 2013 at 6:49 AM, Steven Shiau <st...@nc...> wrote: > What was the error messages when grub failed to boot? > BTW, did you try to use CentoS 6.4 installation CD to do grub-install? Initially it was 'no boot device'. I did boot a Centos 6.4 install disk into rescue mode and ran grub-install. After that it would boot to a 'grub >' prompt but not find a kernel. These machines are very frustrating to boot manually because they have a large amount of ram, many NICs, and a raid controller that take a long time to initialize and you have to hit F12 at just the right time to keep them from trying PXE on all the NICs. I did a different install where I specified partitioning with only one traditional /boot partition and that seems to work in legacy mode - and produced an image that would clone, so I gave up on trying to fix the initial attempt. The original /etc/grub.conf was a symlink to /boot/efi/EFI/redhat/grub.conf and had this: #boot=/dev/sda1 device (hd0) HD(1,800,64000,0557c1a7-7538-4ba1-b81e-74c4328b8b8d) default=0 timeout=5 splashimage=(hd0,1)/grub/splash.xpm.gz hiddenmenu title CentOS (2.6.32-358.6.2.el6.x86_64) root (hd0,1) kernel /vmlinuz-2.6.32-358.6.2.el6.x86_64 ro root=/dev/mapper/vg_trepdevl01-lv_root rd_NO_LUKS LANG=en_US.UTF-8 rd_NO_MD SYSFONT=latarcyrheb-sun16 rd_NO_DM rd_LVM_LV=vg_trepdevl01/lv_swap KEYBOARDTYPE=pc KEYTABLE=us rd_LVM_LV=vg_trepdevl01/lv_root rhgb quiet crashkernel=auto initrd /initramfs-2.6.32-358.6.2.el6.x86_64.img The clone probably had an identical copy, but was missing whatever it took to start the UEFI boot. And that long string in the device line could have a GUID that needs to be adjusted for the target copy. -- Les Mikesell les...@gm... |
From: Steven S. <st...@nc...> - 2013-06-16 12:22:11
|
Hi Laszlo, On 06/16/2013 08:15 PM, Ersek, Laszlo wrote: > On Sun, 16 Jun 2013, Steven Shiau wrote: > >> What was the error messages when grub failed to boot? >> BTW, did you try to use CentoS 6.4 installation CD to do grub-install? >> >> Steven. >> >> On 06/13/2013 05:57 AM, Les Mikesell wrote: >>> I used clonezilla-live 2.1.1-25 to clone a CentOS6.4 installation on >>> IBM x3550M4s. The resulting copy won't boot but appears to be correct >>> when booted from an install DVD in rescue mode. I'm not very >>> familiar with either UEFI systems or GPT partitioning. Is there some >>> quick-fix to reinstall grub from the rescue disk (the obvious >>> 'grub-install /dev/sda' went through the motions but didn't fix it), >>> or a way to have it work with clonezilla? > > The disk contents was probably restored just fine, but, in order to > automatically boot from fixed (ie. non-removable) media, you must add a > Boot#### non-volatile UEFI variable (= a boot option) and reference it > in the BootOrder variable. See "3.1.1 Boot Manager Programming" in the > UEFI 2.3.1+errC specification. > > These variables are stored in system flash, and all UEFI OS installers > (eg. Anaconda for RHEL, Fedora, CentOS) must set them. I assume > clonezilla doesn't save them in the backup image. Thanks. Yes, you are right, we have to add this. Could you please provide more info about how UEFI OS installers does this? Such as the tools to set that... Thanks. Steven. > > Laszlo -- Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org> National Center for High-performance Computing, Taiwan. http://www.nchc.org.tw Public Key Server PGP Key ID: 4096R/47CF935C Fingerprint: 0240 1FEB 695D 7112 62F0 8796 11C1 12DA 47CF 935C |
From: Ersek, L. <la...@ca...> - 2013-06-16 12:35:36
|
On Sun, 16 Jun 2013, Steven Shiau wrote: > On 06/16/2013 08:15 PM, Ersek, Laszlo wrote: >> >> The disk contents was probably restored just fine, but, in order to >> automatically boot from fixed (ie. non-removable) media, you must add a >> Boot#### non-volatile UEFI variable (= a boot option) and reference it >> in the BootOrder variable. See "3.1.1 Boot Manager Programming" in the >> UEFI 2.3.1+errC specification. >> >> These variables are stored in system flash, and all UEFI OS installers >> (eg. Anaconda for RHEL, Fedora, CentOS) must set them. I assume >> clonezilla doesn't save them in the backup image. > Thanks. Yes, you are right, we have to add this. > Could you please provide more info about how UEFI OS installers does > this? Such as the tools to set that... On a lower level, you would call the SetVariable() UEFI runtime service. For the command line, I think efibootmgr / rEFIt / rEFInd are the usual choices. http://freecode.com/projects/efibootmgr http://freecode.com/projects/refit http://www.rodsbooks.com/refind/ Laszlo |
From: Steven S. <st...@nc...> - 2013-06-16 13:17:47
|
On 06/16/2013 08:35 PM, Ersek, Laszlo wrote: > On Sun, 16 Jun 2013, Steven Shiau wrote: > >> On 06/16/2013 08:15 PM, Ersek, Laszlo wrote: >>> >>> The disk contents was probably restored just fine, but, in order to >>> automatically boot from fixed (ie. non-removable) media, you must add a >>> Boot#### non-volatile UEFI variable (= a boot option) and reference it >>> in the BootOrder variable. See "3.1.1 Boot Manager Programming" in the >>> UEFI 2.3.1+errC specification. BTW, when you mentioned "in order to automatically boot from fixed (ie. non-removable) media", did you mean when Clonezilla live finishes the restoring, you want the next boot from fixed media instead of live CD? Otherwise for the BootOrder, if the first one fails, uEFI should try the next boot media, isn't it? Sorry, I did not get the point. Or it would be easier that you can tell us how you use "efibootmgr -o xxx,yyy,zzz" to solve this issue? Thanks. Steven. -- Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org> National Center for High-performance Computing, Taiwan. http://www.nchc.org.tw Public Key Server PGP Key ID: 4096R/47CF935C Fingerprint: 0240 1FEB 695D 7112 62F0 8796 11C1 12DA 47CF 935C |
From: Steven S. <st...@nc...> - 2013-07-23 14:17:43
|
Hi Laszlo, On 06/16/2013 08:35 PM, Ersek, Laszlo wrote: > On Sun, 16 Jun 2013, Steven Shiau wrote: > >> On 06/16/2013 08:15 PM, Ersek, Laszlo wrote: >>> >>> The disk contents was probably restored just fine, but, in order to >>> automatically boot from fixed (ie. non-removable) media, you must add a >>> Boot#### non-volatile UEFI variable (= a boot option) and reference it >>> in the BootOrder variable. See "3.1.1 Boot Manager Programming" in the >>> UEFI 2.3.1+errC specification. >>> >>> These variables are stored in system flash, and all UEFI OS installers >>> (eg. Anaconda for RHEL, Fedora, CentOS) must set them. I assume >>> clonezilla doesn't save them in the backup image. > >> Thanks. Yes, you are right, we have to add this. >> Could you please provide more info about how UEFI OS installers does >> this? Such as the tools to set that... > > On a lower level, you would call the SetVariable() UEFI runtime service. > > For the command line, I think efibootmgr / rEFIt / rEFInd are the > usual choices. > > http://freecode.com/projects/efibootmgr > http://freecode.com/projects/refit > http://www.rodsbooks.com/refind/ > > Laszlo Thanks for providing this info. We have implemented a mechanism to address this issue. You can find that in clonezilla-live-2.1.2-24-amd64 and clonezilla-live-20130723-raring-amd64. By default Clonezilla will update the boot entries in EFI NVRAM, and if you want to skip this action, you can enter expert mode, and choose "-iefi" option. Please test it and let us know the results. Thanks. Steven. -- Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org> National Center for High-performance Computing, Taiwan. http://www.nchc.org.tw Public Key Server PGP Key ID: 4096R/47CF935C Fingerprint: 0240 1FEB 695D 7112 62F0 8796 11C1 12DA 47CF 935C |
From: Ersek, L. <la...@ca...> - 2013-07-24 14:02:16
|
Hi Steven, On Tue, 23 Jul 2013, Steven Shiau wrote: > Hi Laszlo, > On 06/16/2013 08:35 PM, Ersek, Laszlo wrote: >> On Sun, 16 Jun 2013, Steven Shiau wrote: >> >>> On 06/16/2013 08:15 PM, Ersek, Laszlo wrote: >>>> >>>> The disk contents was probably restored just fine, but, in order to >>>> automatically boot from fixed (ie. non-removable) media, you must add a >>>> Boot#### non-volatile UEFI variable (= a boot option) and reference it >>>> in the BootOrder variable. See "3.1.1 Boot Manager Programming" in the >>>> UEFI 2.3.1+errC specification. >>>> >>>> These variables are stored in system flash, and all UEFI OS installers >>>> (eg. Anaconda for RHEL, Fedora, CentOS) must set them. I assume >>>> clonezilla doesn't save them in the backup image. >> >>> Thanks. Yes, you are right, we have to add this. >>> Could you please provide more info about how UEFI OS installers does >>> this? Such as the tools to set that... >> >> On a lower level, you would call the SetVariable() UEFI runtime service. >> >> For the command line, I think efibootmgr / rEFIt / rEFInd are the >> usual choices. >> >> http://freecode.com/projects/efibootmgr >> http://freecode.com/projects/refit >> http://www.rodsbooks.com/refind/ >> >> Laszlo > Thanks for providing this info. > We have implemented a mechanism to address this issue. You can find that > in clonezilla-live-2.1.2-24-amd64 and > clonezilla-live-20130723-raring-amd64. By default Clonezilla will update > the boot entries in EFI NVRAM, and if you want to skip this action, you > can enter expert mode, and choose "-iefi" option. > Please test it and let us know the results. > Thanks. I'm very sorry -- although I had asked some questions about clonezilla on the list, I never ended up using it, and it's unlikely I could test this for you. I kept my list subscription because the list is low traffic and sometimes interesting even for a non-user. Since part of my day job is related to UEFI, this thread has caught my eye; but that's all I could do, unfortunately. Maybe the OP of this thread, Les Mikesell, could help with testing? Thanks, Laszlo |
From: Steven S. <st...@nc...> - 2013-07-24 12:59:11
|
Hi Laszlo, On 07/24/2013 08:52 PM, Ersek, Laszlo wrote: > Hi Steven, > > On Tue, 23 Jul 2013, Steven Shiau wrote: > >> Hi Laszlo, >> On 06/16/2013 08:35 PM, Ersek, Laszlo wrote: >>> On Sun, 16 Jun 2013, Steven Shiau wrote: >>> >>>> On 06/16/2013 08:15 PM, Ersek, Laszlo wrote: >>>>> >>>>> The disk contents was probably restored just fine, but, in order to >>>>> automatically boot from fixed (ie. non-removable) media, you must >>>>> add a >>>>> Boot#### non-volatile UEFI variable (= a boot option) and >>>>> reference it >>>>> in the BootOrder variable. See "3.1.1 Boot Manager Programming" in >>>>> the >>>>> UEFI 2.3.1+errC specification. >>>>> >>>>> These variables are stored in system flash, and all UEFI OS >>>>> installers >>>>> (eg. Anaconda for RHEL, Fedora, CentOS) must set them. I assume >>>>> clonezilla doesn't save them in the backup image. >>> >>>> Thanks. Yes, you are right, we have to add this. >>>> Could you please provide more info about how UEFI OS installers does >>>> this? Such as the tools to set that... >>> >>> On a lower level, you would call the SetVariable() UEFI runtime >>> service. >>> >>> For the command line, I think efibootmgr / rEFIt / rEFInd are the >>> usual choices. >>> >>> http://freecode.com/projects/efibootmgr >>> http://freecode.com/projects/refit >>> http://www.rodsbooks.com/refind/ >>> >>> Laszlo >> Thanks for providing this info. >> We have implemented a mechanism to address this issue. You can find that >> in clonezilla-live-2.1.2-24-amd64 and >> clonezilla-live-20130723-raring-amd64. By default Clonezilla will update >> the boot entries in EFI NVRAM, and if you want to skip this action, you >> can enter expert mode, and choose "-iefi" option. >> Please test it and let us know the results. >> Thanks. > > I'm very sorry -- although I had asked some questions about clonezilla > on the list, I never ended up using it, and it's unlikely I could test > this for you. > > I kept my list subscription because the list is low traffic and > sometimes interesting even for a non-user. Since part of my day job is > related to UEFI, this thread has caught my eye; but that's all I could > do, unfortunately. > > Maybe the OP of this thread, Les Mikesell, could help with testing? > > Thanks, > Laszlo Got it. No problem. It's nice to know even you are not a Clonezilla user, but you still subscribe to this mailing list. Thanks for all the help. Steven. -- Steven Shiau <steven _at_ nchc org tw> <steven _at_ stevenshiau org> National Center for High-performance Computing, Taiwan. http://www.nchc.org.tw Public Key Server PGP Key ID: 4096R/47CF935C Fingerprint: 0240 1FEB 695D 7112 62F0 8796 11C1 12DA 47CF 935C |
From: Les M. <les...@gm...> - 2013-07-24 14:55:23
|
On Wed, Jul 24, 2013 at 7:52 AM, Ersek, Laszlo <la...@ca...> wrote: > > I kept my list subscription because the list is low traffic and sometimes > interesting even for a non-user. Since part of my day job is related to > UEFI, this thread has caught my eye; but that's all I could do, > unfortunately. > > Maybe the OP of this thread, Les Mikesell, could help with testing? Unfortunately the set of machines where I encountered the problem have already been rolled into production. It turned out that particular model would work in legacy mode and I was able to rebuild my master image without the UEFI boot partion and then it cloned successfully. But I appreciate the quick response to the issue I brought up. -- Les Mikesell les...@gm... |