UEFI 12.04_AMD64 - Win7 dual boot problems

[darkomano]

For my understanding, there is only one MBR on a disk, isn't there?
Does it matter for Grub that sda2 is active?

How can I re-install GRUB in the MBR (resuming my broken dual boot installation)?
Is there another way to start Grub? from Win7 for example? (It used to work with boot.ini files.)

Yes there is only one MBR - first sector on disk.
Grub does not use active partition - it uses partition address.

Grub install/reinstall - https://help.ubuntu.com/community/Grub2/Installing


To dual boot from Windows 7:

1. copy file /boot/grub/boot.img from Ubuntu to say Windows "c:\"
(from Windows - install "ext2fsd" - allows access to ext2/3/4 from Windows 7)
2. using Visual BCD Editor - create "boot sector loader" -> drive = c: and path=\boot.img

[martinr]

Hi Darko,

Thanks for you help.

Here's the information you asked for.

How Win7x64's disk manager sees the drive (in order to determine GPT):


Some BIOS shots to determine which boot sequence is followed and why Grub wasn't installed in the MBR of sda?

No MBR protection option can be found:

EFI is first in the boot sequence:

This is the details page of the EFI DEVICE PRIORITY option:


My new rig also has an Intel Management Engine BIOS on board (which does nothing at the moment).

The question remains, why Grub wasn't installed in the MBR and why can't I find that in the install log files?

[darkomano]

Thank you for the screen shots.

In BIOS Setup - Boot Options screen the first boot device is [EFI Device].

I think it must taken out of order.

So your boot options would be:

1st boot device [CD/DVD]
2nd boot device [HDD]
.....

If you insert a CD/DVD then it is booted, else
HDD is booted (HDD should be in MBR format).

Maybe this [EFI Device] in 1st position of BIOS boot options is confusing Linux installer and GRUB is not written to HDD first sector (MBR position) ?

All new installation media (I think) is prepared for BIOS and for EFI boot.

It is the computer setup which boots either BIOS way or EFI way.
In your case 1st device is EFI so the installation CD/DVD is booted EFI way (I think).
Is Linux setup/installation expecting also a GPT disk as installation target when booted the EFI way ?
I don't know.
If this is true then writing a MBR is meaningless and setup does not write a MBR.
Maybe it is just an error in the setup/installation script ?

Installation is much more complex now with having two kind of disk formats (MBR and GPT) and also two kind of firmware (BIOS an EFI).

[martinr]

My brain reached critical mass this morning, after reading up on EFI boot sequences, WIN7x64 + GPT, Darko's help and reading a lot of other threads.
Here's a recap for other people experiencing similar problems.

Goal:
Create a dual boot system with a pre installed Win7x64 and Ubuntu Desktop 12.04 LTS amd64 with Grub installed as the boot-loader in the MBR of sda.

Problem symptoms:
After Ubuntu installation from the Live CD along side Win7x64, Grub wont start at boot-up of the system. It boots straight into Win7.

Hypothesis:
The Ubuntu Desktop 12.04 amd64 Live CD, was booted with an UEFI boot sequence although the hard disk structure is MSDOS with MBR.
This fools Grub into switching to EFI mode and failing to install itself into the MBR.
To test this hypothesis I will reinstall from the Live CD, but start it with an BIOS/MBR boot sequence.

Needed Materials:

• An external HD and/or a 10 pack of empty DVDs (for backup).
• Ubuntu Desktop 12.04 LTS amd64 Live CD

Method:

1. Backup first.
2. Determine if the HD structure is mdos/MBR or GUID Partition Table (GPT).
3. Determine the utilized boot sequence of the Live CD (U)EFI/GPT or BIOS/MBR.
4. Determine if you can somehow switch between (U)EFI or BIOS/MBR boot sequence.
5. Boot the Live CD in non (U)EFI mode.
6. Install Ubuntu on its partition and install Grub in the MBR of sda (the boot HD).
7. Reboot and test if Grub appears and Win7 and Ubuntu 12.04 work.

Results:

1. As a precaution backup (in order of prevalence): your MBR, your data, burn the (cheap-***) OEM (bastards) factory restore DVDs, burn the Win7 recovery DVDs.
2. Run parted on sda to find out your HD partition structure.
   

   (parted) print 
   Model: ATA WDC WD10EADX-22T (scsi)
   Disk /dev/sda: 1000GB
   Sector size (logical/physical): 512B/512B
   Partition Table: msdos
   
   Number  Start   End     Size    Type      File system     Flags
    1      1049kB  16.1GB  16.1GB  primary   ntfs            diag
    2      16.1GB  16.2GB  105MB   primary   ntfs            boot
    3      16.2GB  177GB   161GB   primary   ntfs
    4      177GB   1000GB  823GB   extended
    5      177GB   182GB   5046MB  logical   ntfs
    6      182GB   189GB   6443MB  logical   linux-swap(v1)
    7      189GB   242GB   53.7GB  logical   ext4
    8      242GB   247GB   5046MB  logical   ext4
    9      248GB   1000GB  753GB   logical   ntfs

3. I verified in the intial install logs (/var/install/syslog) that erroneously grub-efi was installed instead of grub-pc:
   

   Jun 13 13:45:35 ubuntu grub-installer: info: architecture: amd64/efi
   ...
   Jun 13 13:45:38 ubuntu grub-installer: Removing grub-pc ...
   Jun 13 13:45:39 ubuntu grub-installer: Purging configuration files for grub-pc ...
   Jun 13 13:45:40 ubuntu grub-installer: Removing grub-gfxpayload-lists ...
   Jun 13 13:45:40 ubuntu grub-installer: Removing grub-pc-bin ...
   ...
   Jun 13 13:45:44 ubuntu ubiquity: The following extra packages will be installed:
   Jun 13 13:45:44 ubuntu ubiquity:   efibootmgr grub-common grub-efi-amd64 grub-efi-amd64-bin grub2-common
   ...
   Jun 13 13:45:57 ubuntu ubiquity: Setting up grub-efi (1.99-21ubuntu3.1) ...
   ...
   Jun 13 13:45:58 ubuntu grub-installer: info: Installing grub on 'dummy'
   Jun 13 13:45:58 ubuntu grub-installer: info: grub-install supports --no-floppy
   Jun 13 13:45:58 ubuntu grub-installer: info: Running chroot /target grub-install  --no-floppy --force
   Jun 13 13:45:59 ubuntu grub-installer: Installation finished. No error reported.
   Jun 13 13:45:59 ubuntu grub-installer: info: grub-install ran successfully

4. Check for (U)EFI options in your BIOS and or firmware boot menu. Switch off (U)EFI or select the non (U)EFI DVD boot method in your firmware boot menu. My computer offers a firmware boot menu by pressing F12 at start-up. Switch off the (U)EFI boot sequence in the bios or select the non (U)EFI boot device/method in the firmware boot menu. I will choose the non UEFI CD boot in the firmware boot menu (no BIOS changes required).
   

See my next posting for further results, my conclusion and recommendations.

[Whilst I was writing this, I saw that Darko simultaneously had replied, thanks it supports my hunch and gives me confidence I'm on the right track.]

[martinr]

(Results continued)

• 4. (continued) Here's a picture of the F12 boot device selector option during startup of my computer:
  
• 5. I entered the Live CD into the CD/DVD drive, rebooted and hit F12 during startup. The boot device selector appeared and instead of the default UEFI selection, I selected the P2 options (see picture above). To boot the Live CD in non (U)EFI mode.
• 6. I installed Ubuntu on its partition again and noted a difference. I was not served the question "on which partition I wanted to install Grub", any more whereas in the previous attempt I could choose between sda, sda1, ..., sda9.
• 7. After installation I rebooted and Grub appeared as expected! Ubuntu boots correctly and Win7 also. Success!

Conclusion
When the Live CD is booted with an UEFI boot sequence, Grub erroneously expects a GPT structured HD, even if the boot HD is msdos/MBR structured. Grub doesn't installs itself to the MBR. When the same Live CD is booted with a non UEFI boot sequence Grub is automatically installed correctly in the MBR and Win7 is added too. So start the Live CD with a non UEFI boot sequence if you have an msdos/MBR (non GPT) structured HD.

Discussion
A BIOS option to write protect the MBR could also prevent Grub from installing itself in the MBR.

Because by (factory) default my computer tries to boot a CD in UEFI mode it triggers the flow of events that leads to the failing grub-efi installation. The simplest way to correct this, is to re-install the live CD in non UEFI boot sequence mode.

Because more and more computers support UEFI nowadays, the out of the box installation of Grub and hence Ubuntu from the Live CD is expected to fail more often. I would suggest that the installation process should be updated to alert the user of a UEFI boot sequence conflicting with a non GPT structured installation HD or better yet, if possible automatically make the correct Grub installation selection accordingly to the HD's structure.

Recognitions
Along with the authors of helpful threads on this forum, I would like to explicitly thank darkomano for his help and advise in this matter. Thanks!

[martinr]

Please feel free to drop a line if you found this thread helpful or have additional insights.

[YannBuntu]

Hello

@martinr: Thank you for describing your experience. It shows a good example of system where it is possible to deactivate EFI in the BIOS and use standard grub-pc instead of grub-efi.
If I understood well, it also shows a bug of Ubiquity (=the Ubuntu installer). Please could you create a bug report here: https://bugs.launchpad.net/ubuntu/+s...quity/+filebug
Entitle it "Ubiquity installed grub-efi when it should have installed grub-pc", attach your /var/log/installer/syslog and
/var/log/installer/partman files, and please indicate the URL of this report here so that we can follow-up it.


@all: I would like to add that some EFI systems need a procedure different to the one you used in this thread.
Here is why:
- some EFI-BIOS have an option to deactivate EFI boot, some don't. Some BIOS don't have EFI mode at all.
- The procedure for activating/deactivating EFI in the BIOS can be different for each BIOS
- on some systems, it is possible to use grub-pc even if the BIOS is in EFI mode
- on some systems, it is possible to use grub-efi (if BIOS setup in EFI mode), or grub-pc. On some other systems, it is possible to use only grub-pc , or only grub-efi.
- If you want to try grub-efi, it is first necessary to have a GPT disk with an ESP (EFI partition= FAT32, >200Mo, start_of_the_disk, boot flag), and to setup the BIOS in EFI mode. Then you need to install grub-efi (an easy way for this is to use Boot-Repair with the "Separate /efi" option). To finish, some old EFI-BIOS need to create an entry that boots the grub*.efi file in the EFI partition.
- If you want to try grub-pc, it is necessary to have either a non-GPT disk, or a GPT disk with a BIOS-boot partition (>1Mo, no filesystem, bios_grub flag). On some systems it is also necessary to deactivate EFI in BIOS. Then you need to install grub-pc (an easy way for this is to use Boot-Repair without the "Separate /efi" option).
- If you don't know which method you need (grub-pc or grub-efi). I don't know any general rule to know if a system can/must use grub-pc or/and grub-efi. But there are clues that may orientate to one or the other method (eg if Windows is installed in the MBR, try grub-pc first). What I recommend here is to run Boot-Repair's "Recommended repair" which will install either grub-pc or grub-efi according to these small clues, it will also give advice on how to setup BIOS and boot partitions. Note the URL that will appear on a paper, and reboot the PC. If you still can't access Ubuntu, you can then try the other method this way: run Boot-Repair again, click "Advanced options",go to the "GRUB location" tab, toggle the "Separate /efi" option, apply. Note the 2nd URL that will appear, then reboot. If both methods don't work, you may have not setup your BIOS and/or boot partitions correctly, so indicate your 2 URLs to ask help here.

Hope this helps.

[martinr]

@martinr:
If I understood well, it also shows a bug of Ubiquity (=the Ubuntu installer). Please could you create a bug report here: https://bugs.launchpad.net/ubuntu/+s...quity/+filebug
Entitle it "Ubiquity installed grub-efi when it should have installed grub-pc", attach your /var/log/installer/syslog and
/var/log/installer/partman files, and please indicate the URL of this report here so that we can follow-up it.

Thanks for the link YannBuntu. I submitted the report.
The bug report can be found here.

[YannBuntu]

thanks

[martinr]

You can vote for this bug to be permanently fixed over here.
See how many people it affects here.