I've been following the beginners guide pretty much word for word. I am trying to setup EFISTUB using rEFInd but I have run into an issue when using efibootmgr to add rEFInd to the UEFI boot menu
as per the instructions i run the command and get this
# efibootmgr -c -g -d /dev/sda -p 5 -w -L "rEFInd" -l '\EFI\refind\refindx64.efi'
Extended partition info not supported.
Error: no partition information on disk /dev/sda.
Cowardly refusing to create a boot option.
I have tried searching for any similar problems but I have found none so far.
Thanks in advance for the help
What is your partition setup? e.g. gdisk -l /dev/sda
Did you modproble efivars successfully? Is everything mounted correctly?
sda1 ntfs windows 7 partition 482GB
sda2 ntfs recovery 23GB
sda3 vfat hp tools 100MB
sda5 vfat UEFI System partition 500MB
sda6 swap linux swap 2GB
sda7 ext4 root 20GB
sda8 ext4 home 112GB
Last edited by theGryphon (2012-12-29 03:29:36)
Output from gdisk would also tell you whether the partition table looks OK. Is sda5 really only 500M? It should be at least 512M although it *may* not cause issues even if it is not. (Depends how fussing your firmware is.) I don't think it would cause this.
Please use [code ][/code ] tags.
Can you explain the steps you took to install rEFInd and the setup of /dev/sda5 e.g. ls -lR /dev/sda5?
Do you definitely have a GPT partition map? gdisk will tell you this, too.
Last edited by cfr (2012-12-29 03:53:43)
My suspicion is that you've got a BIOS-booting computer with a Master Boot Record (MBR) partition table. If so, neither rEFInd nor the EFI stub loader will work for you -- at least, not unless the computer's firmware is actually EFI firmware booting using legacy options. I say this for two reasons:
The error message refers to an extended partition, which is a term that applies to MBR partitions, not to the GUID Partition Table (GPT) used on the vast majority of EFI installations. I just checked the efibootmgr source code, and the comments that surround the error message support this view.
Your reported partitions include no /dev/sda4, which could be a gap where there's an extended partition in an MBR scheme. Such a gap is legal, but a bit odd, in a GPT scheme.
To be more sure of this, please post what cfr asked for: the output of "gdisk -l /dev/sda", not your summary of it, which omits critical details. (The output of "parted /dev/sda print" will do as well.) Post the entire output of the command, and post it between code tags to preserve the columnar formatting.
If you do have EFI firmware that's booting in BIOS mode, there may be ways to do what you want, but they all require jumping through several extra hoops.
sda5 is actually 526MB
to install rEFInd i followed the beginners guide:
# pacman -S refind-efi efibootmgr # mkdir -p /boot/efi/EFI/refind # cp /usr/lib/refind/refindx64.efi /boot/efi/EFI/refind/refindx64.efi # cp /usr/lib/refind/config/refind.conf /boot/efi/EFI/refind/refind.conf # cp -r /usr/share/refind/icons /boot/efi/EFI/refind/icons # nano /boot/efi/EFI/arch/refind_linux.conf "Boot to 5" "root=/dev/sda5 ro rootfstype=ext4 systemd.unit=graphical.target" "Boot to console" "root=/dev/sda5 ro rootfstype=ext4 systemd.unit=multi-user.target"
ls -IR /dev/sda5 gives simply repeats back /dev/sda5
We need the output of gdisk -l.
When I said ls -lR /dev/sda5 I meant the listing for that partition so if it is mounted at /boot/efi then ls -lR /boot/efi/ or whatever. Since I don't know where it is mounted I can't tell you exactly.
But gdisk -l /dev/sda is crucial. Or the parted alternative given by srs5694.
If you don't post information, nobody is going to be able to give you any useful advice and you are just wasting everybody's time.
Similarly, if you don't post accurate information. If you had posted the output of gdisk -l in the first place, I wouldn't have wasted my time telling you the EFI partition should be 512M. (And we wouldn't all be wasting our time trying to persuade you to yield information which should have been provided in your original post.)
Last edited by cfr (2012-12-29 04:16:55)
I am sorry for the lack of quality information.
I am using a MBR partition scheme because gdisk was giving me errors while fdisk did not and I was reluctant to change the existing MBR partitions to GPT for fear of data loss
# gdisk -l /dev/sda GPT fdisk (gdisk) vestion 0.8.5 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: not present ************************************************************* Found invalid GPT and valid MBR; converting MBR to GPT format ************************************************************* Warning! Main partition table overlaps the first partition by 34 blocks! You will need to delete this partition or resize it in another utility Disk /dev/sda: 1250263728 sectors, 596.2 GiB Logical sector size: 512 bytes Disk identifier (GUID): 431106BA-8084-428D-A0ED-0FE5BDC4FC02 Partition table holds up to 128 entries First usabel sector is 34, last usable sector is 1250263694 Partitions will be aligned on 8-sector boundaries Total free space is 2955 sectors (1.4 MiB) Number Start (sector) End (sector) Size Code Name 2 1204889600 1250050047 21.5 GiB 0700 Microsoft basic data 3 1250050048 1250260991 103.0 MiB 0700 Microsoft basic data 5 940697663 941725759 502.0 MiB Ef00 EFI System 6 941725823 945725944 1.9 GiB 8200 Linux swap 7 945726008 985727794 19.1GiB 8300 Linux filesystem 8 985727858 1204889599 104.5 GiB 8300 Linux filesystem
Why are you trying to use UEFI when your M$ installation is booting via legacy bios? You can make this work, but your EFI System partition cannot be on an extended partition (as the error has already told you).
Honestly, it would be much easier to simply have everything boot as bios. Use grub, lilo, or my favorite, syslinux, and then chainload to the windows partition.
You probably should go do some learning about the two different methods that a system can boot from.
I agree with WonderWoofy: why not just use BIOS mode to boot?
Note that the -g in the command you've been trying to use with efibootmgr is short for --gpt.
I would agree that changing from MBR to GPT is not something you would want to do without ensuring everything is backed up. (Although messing around with partition tables at all is also not something you should be doing without a reliable backup.) I don't suppose Windows would like it at all either (although I know nothing about Windows). But that's all just another reason in favour of sticking with BIOS booting.
Is there some particular reason you need or want to boot in EFI mode? (Even assuming your BIOS is a UEFI BIOS.)
Again, like WonderWoofy, I think you should do some more reading about this so that you understand what the options are and what the commands you are using mean. If you are just copying and pasting blindly from the wiki, you are going to run into trouble sooner or later and, in all probability, sooner rather than later.
I'll add my voice to WonderWoofy and cfr; trying to install rEFInd on your current setup is pointless. (Note that I'm the author of gdisk and I maintain rEFInd, so I know what I'm talking about.) The path of least resistance for you is to use GRUB, LILO, or SYSLINUX to boot Linux, as WonderWoofy suggests. If you've got a compelling reason to do otherwise, there may be ways to convert your system to use an EFI boot, but these methods depend upon your system supporting EFI booting (few computers sold before ~1.5 years ago do so) and most of them take significant effort and impose some risk of data loss. They're not worth it just to shave a few seconds off the boot time or to get a prettier boot menu. If you want to go down this path, please tell us precisely why you want to do this so that we can help you figure out the best way to do it. Be aware that the easiest way to do this involves using a second physical hard disk, so if you insist on pursuing this, I may recommend you buy another disk.
...(Note that I'm the author of gdisk and I maintain rEFInd, so I know what I'm talking about.)...
...and I read all his posts, so I kind of know what I'm talking about.
But seriously, listen to srs5694. He's like the grand master of UEFI and Linux.