| Summary: | install failed with UEFI and GPT issues (grub2-install) | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Tony Blackwell <tablackwell> |
| Component: | Installer | Assignee: | Thierry Vignaud <thierry.vignaud> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | Normal | CC: | davidwhodgins, eeeemail, mustafa1024m, olegbosis, tmb, zen25000 |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | 4alpha3 | ||
| Source RPM: | drakxtools | CVE: | |
| Status comment: | |||
|
Description
Tony Blackwell
2013-09-29 09:22:45 CEST
Looks like you need to create one more partition: BIOS Boot Partition. See here how to do this: http://en.wikipedia.org/wiki/BIOS_Boot_partition . CC:
(none) =>
olegbosis
Barry Jackson
2013-09-29 19:19:43 CEST
CC:
(none) =>
zen25000 Hmm, I thought the BIOS boot partition was only needed for BIOS-based booting. Perhaps by turning the system back to legacy-mode I now require this. I'd thought that by preserving the EFI system that the pre-installed widows had, all would be OK... 1. Where are we at for having M4 using EFI boot in general, and secure boot in particular? (Where does that leave me if I wanted to have MS-Win8 booting in secure boot mode as an alternative?) 2. If I create a tiny BIOS boot partition, will that interfere with EFI boot if I went through the clumsy process of fiddling with the BIOS to get back to that? 3. As a component of this, M4 install doesn't smoothly deal with GPT. This is now on this laptop by default, and I don't see the average user knowing how to pre-setup the disk with gdisk or parted. I note the following: http://www.kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/ Do we build our kernel with UEFI booting enabled? (In reply to Tony Blackwell from comment #3) > I note the following: > http://www.kroah.com/log/blog/2013/09/02/booting-a-self-signed-linux-kernel/ > > Do we build our kernel with UEFI booting enabled? zgrep EFI /proc/config.gz shows the first two are set zgrep CMDLINE /proc/config.gz shows the next two are not set, as our installs are still using a boot loader zgrep INITRD /proc/config.gz shows CONFIG_BLK_DEV_INITRD=y, but CONFIG_INITRAMFS_SOURCE is not set, again because of the use of a boot loader. So everything is there to be able to boot in uefi mode. With Mageia 3 final, installing in uefi mode using the live iso images was close to working, but the installer wasn't working properly with grub2-efi, so the ability to install in uefi mode was put off, hopefully for Mageia 4. As far as I know, no work has been done on the installer since, to fix the problem with grub2-efi. Note that the experimental support in Mageia 3 was only for installation using one of the live dvds, not the classical installer, and required copying the contents of the iso image to a vfat partition on a usb stick with a label of MGA3LIVE I expect when it does get fixed, the label will have to be MGA4LIVE. CC:
(none) =>
davidwhodgins
Dave Hodgins
2013-09-30 01:07:01 CEST
CC:
(none) =>
tmb
claire robinson
2013-09-30 09:38:38 CEST
Whiteboard:
(none) =>
4alpha3
claire robinson
2013-09-30 09:38:45 CEST
CC:
(none) =>
eeeemail Any chances of waking this up again as a critical issue for M4? If UEFI and GPT are becoming universal, it will be very hard to install M4 on new hardware without both these issues addressed. it is "planned" (iirc this bug is a duplicate but as I'm not sure..) Summary:
install failed with UEFI and GPT issues =>
install failed with UEFI and GPT issues (grub2-install)
Manuel Hiebel
2013-10-10 21:31:22 CEST
Assignee:
bugsquad =>
thierry.vignaud Current status: Deleted everything on the hard disk and started again. Previously I'd had a small bios boot partition first, then EFI, but this seemed non-standard (either the system will use legacy boot and the bios boot partition, or EFI, not both), and it seems to be a convention that EFI comes first on the disk - some other OS software expect this I think. (As an aside, I made the EFI partition 1Gb, because some reading on a MS site gave a formula for calculating EFI size which allowed up to 1Gb and I want to play with direct book of suitable kernel sometime in the future. I noted in passing however some earlier discussion about ubuntu EFI partition causing problems if > 250Mb. The MS-Win_8 which was preinstalled had 300Mb). The classic DVD install disk wouldn't boot without first activating CSM in the BIOS. I note Manuel's comment above that fixes for this are 'planned' - is there someone or someones working on this? Time-frame? Before the next alpha?? I think we need to bring up the host computer in EFI mode for an EFI install to proceed? Installation of M4a3 x86_64 proceeded OK until boot install of grub2 failed right at the end with error messages blaming this on lack of a bios boot partition. Re-did it with grub instead of grub2. No complaints but it wouldn't boot. Don't know what if anything got installed for grub. Comment: The install script needs fixing to recognise if being installed on an EFI system - most installs on new personal hardware will be EFI from now on I think? The installation site needs to offer the EFI partition for boot installation, and do it. Installs elsewhere will not boot as I understand it? We need all the appropriate UEFI tools as part of the M4 distribution, with enough on the install disk to enable booting. Further comment:I rebooted the laptop with gnome live DVD,and from command line in a usb stick ran urpmi ./grub2-efi* to install. This reported the scriptlet failed, exit status 1. Tried to run grub2-install, it failed with: /usr/lib/grub/i386-pc doesn't exist. Please specify --target or --directory. (the urpmi install of grub2-efi mostly succeeded, as shown by /usr/lib/grub now containing the file x86_64-efi and the directory x86_64-mageia) Guess I need to tell it to use the x86_64 stuff. I haven't yet succeeded in setting up all the command-line parameters for this grub2-install. Could use syntax suggestions for doing this, for a GPT disk with EFI as partition 1 and the M4 partition being partition 4. Appreciate any help Tonyb http://wiki.gentoo.org/wiki/GRUB2 looks very useful. Following the UEFI/GPT section confirms that grub2-efi will not install without efibootmgr previously installed. Still didn't work.
From the gentoo site scripts referenced above, I ran
mkdosfs -F 32 -n efi-boot /dev/sda1
mkdir /boot/efi
echo 'LABEL=efi-boot /boot/efi vfat defaults 0 2' >> /etc/fstab
mount /boot/efi
mkdir -p /boot/efi/{EFI/BOOT,GRUB2}
(actually the fstab entry didn't work, as despite the LABEL being put in as efi-boot, Mageia_4 sees it as EFI-BOOT, i.e. upper case. I'll fix that later, but manually mounted it on /boot/efi.
then:
grub2-install --target=x86_64-efi --efi-directory=/boot/efi --boot-directory=/boot/efi
got the message;
Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables. Try 'modprobe efivars' as root.
Did this and modprobe completed silently, but still the same Fatal error message.
Now I'm out of my depth.
(In reply to Tony Blackwell from comment #10) > http://wiki.gentoo.org/wiki/GRUB2 > looks very useful. Following the UEFI/GPT section confirms that grub2-efi > will not install without efibootmgr previously installed. I think that is mentioned in README.efi in the grub2-efi package, and is the reason that we package efibootmgr. The gentoo reference (see above) points out that EFI stuff can't be seen unless booted in EFI mode, and gives command line to make a suitable memory stick from which to do this. I'll try it. Just use the alpha3 liveDVDs they are capable of booting in UEFI mode, it's just the installer part that still needs fixing Mageia 4 version 2 has more-matured EFI support, - a work in progress perhaps. Closing this as no longer relevant in this context. Status:
NEW =>
RESOLVED |