What does it take to make a disk bootable on a system with UEFI and a GPT on the boot disk? I used a default disk layout in the initial install on a 600Gb drive (on a box that also contained a larger raid). and it used a GPT.
ReaR won't work to back up/restore this system, complaining about the UEFI. I cloned the drive to a different server with clonezilla-live which completed without errors but it won't boot. I booted an install disk in rescue mode, did a chroot to /mnt/sysimage and everything looked OK. A 'grub-install /dev/sda' did not give any errors and I can now get it to boot to the grub> prompt. What's the right way to fix the grub install here?
-- Les Mikesell lesmikesell@gmail.com
On Wednesday 12 June 2013, Les Mikesell lesmikesell@gmail.com wrote:
ReaR won't work to back up/restore this system, complaining about the UEFI. I cloned the drive to a different server with clonezilla-live which completed without errors but it won't boot. I booted an install disk in rescue mode, did a chroot to /mnt/sysimage and everything looked OK. A 'grub-install /dev/sda' did not give any errors and I can now get it to boot to the grub> prompt. What's the right way to fix the grub install here?
Is the /boot/grub/grub.conf file correct?
On Wed, Jun 12, 2013 at 5:28 PM, Yves Bellefeuille yan@storm.ca wrote:
On Wednesday 12 June 2013, Les Mikesell lesmikesell@gmail.com wrote:
ReaR won't work to back up/restore this system, complaining about the UEFI. I cloned the drive to a different server with clonezilla-live which completed without errors but it won't boot. I booted an install disk in rescue mode, did a chroot to /mnt/sysimage and everything looked OK. A 'grub-install /dev/sda' did not give any errors and I can now get it to boot to the grub> prompt. What's the right way to fix the grub install here?
Is the /boot/grub/grub.conf file correct?
I'm not sure what 'correct' is. On this system there is a small FAT partition in addition to the traditional /boot that is mounted as /boot/efi and /etc/grub.conf is a symlink to /boot/efi/EFI/redhat/grub.conf. It is the first install I've seen that looked anything like that.
The original has this - and I think the copy is the same:
#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
-- Les Mikesell lesmikesell@gmail.com
On Wednesday 12 June 2013, Les Mikesell lesmikesell@gmail.com wrote:
#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
Ah, you posted this in the forum, didn't you? The line that starts with "device" is new to me. I thought it was something specific to UEFI or GPT I didn't know about, but apparently it can only be used at the Grub shell, not in the grub.conf file.
Look at http://wiki.centos.org/HowTos/GrubInstallation and create a grub.conf file as described in section 2.
On Wed, Jun 12, 2013 at 5:56 PM, Yves Bellefeuille yan@storm.ca wrote:
On Wednesday 12 June 2013, Les Mikesell lesmikesell@gmail.com wrote:
#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
Ah, you posted this in the forum, didn't you?
No, it is gmail's web client that likes to wrap lines.
The line that starts with "device" is new to me. I thought it was something specific to UEFI or GPT I didn't know about, but apparently it can only be used at the Grub shell, not in the grub.conf file.
This is copied from the working system - it is something that the Centos installer wrote.
Look at http://wiki.centos.org/HowTos/GrubInstallation and create a grub.conf file as described in section 2.
The problem is that the same thing that works on the master system doesn't work on the cloned copy. So it probably has something to do with the initial stage(s) of the boot - unless that long device string is some uuid thing that won't match on the copy.
-- Les Mikesell lesmikesell@gmail.com
On 06/13/2013 01:41 AM, Les Mikesell wrote:
device (hd0) HD(1,800,64000,0557c1a7-7538-4ba1-b81e-74c4328b8b8d)
Just an ideea: check this line to see if "0557c1a7-7538-4ba1-b81e-74c4328b8b8d" is not related to the boot disk. you said you cloned it so probably you must put there the UUID of the cloned disk.
On Thu, Jun 13, 2013 at 1:43 AM, Alexandru Chiscan lec@chiscan.dnsalias.org wrote:
On 06/13/2013 01:41 AM, Les Mikesell wrote:
device (hd0) HD(1,800,64000,0557c1a7-7538-4ba1-b81e-74c4328b8b8d)
Just an ideea: check this line to see if "0557c1a7-7538-4ba1-b81e-74c4328b8b8d" is not related to the boot disk. you said you cloned it so probably you must put there the UUID of the cloned disk.
I gave up and restored a backup onto a host without the EFI boot partition and tweaked it to use the old-style grub invocation. The machines seem to fail back to 'legacy' mode when there is no EFI/fat partition to boot from. This gives a layout where rear and clonezilla 'just work' and I'll know how to fix it if anything breaks. Maybe I'll try again when rear supports UEFI (in the works) and I can look at their shell scripts to figure it out.
-- Les Mikesell lesmikesell@gmail.com
Les Mikesell wrote:
On Thu, Jun 13, 2013 at 1:43 AM, Alexandru Chiscan lec@chiscan.dnsalias.org wrote:
On 06/13/2013 01:41 AM, Les Mikesell wrote:
device (hd0) HD(1,800,64000,0557c1a7-7538-4ba1-b81e-74c4328b8b8d)
Just an ideea: check this line to see if "0557c1a7-7538-4ba1-b81e-74c4328b8b8d" is not related to the boot disk. you said you cloned it so probably you must put there the UUID of the cloned disk.
I gave up and restored a backup onto a host without the EFI boot partition and tweaked it to use the old-style grub invocation. The machines seem to fail back to 'legacy' mode when there is no EFI/fat partition to boot from. This gives a layout where rear and clonezilla 'just work' and I'll know how to fix it if anything breaks. Maybe I'll try again when rear supports UEFI (in the works) and I can look at their shell scripts to figure it out.
You might look at the firmware setup - our Dells let you choose UEFI or BIOS.
mark
On Thu, Jun 13, 2013 at 2:37 PM, m.roth@5-cent.us wrote:
I gave up and restored a backup onto a host without the EFI boot partition and tweaked it to use the old-style grub invocation. The machines seem to fail back to 'legacy' mode when there is no EFI/fat partition to boot from. This gives a layout where rear and clonezilla 'just work' and I'll know how to fix it if anything breaks. Maybe I'll try again when rear supports UEFI (in the works) and I can look at their shell scripts to figure it out.
You might look at the firmware setup - our Dells let you choose UEFI or BIOS.
Letting it fall back on its own is OK - the problem was that someone set up a server for development work, then wanted a bunch of identical copies. And the default install had set up the UEFI boot stuff. Another box I had installed myself with explicitly configured partitions didn't. Seems kind of strange, but who understands anaconda?
-- Les Mikesell lesmikesell@gmail.com