2

I was trying to install Kali Linux from a live USB to an 1TB external hard disk. At first I was unable to boot the live USB with my H2O Insyde BIOS. Then I converted my pen drive partition table to GPT and created a 500MB FAT32 partition labeled EFI and copied BOOTX64.efi and grubx64.efi to the directory boot inside my EFI partition. I created the live USB using a Ubuntu in a VirtualBox (when I created with unetbootin and universal installer, it doesn't boot.) and then only I succeeded to boot the live USB.

Then I tried to install Kali Linux in my external hard disk. the whole installation procedure succeeds with both guided partition and manual partition, but GRUB installation fails. I referred online forums and wikis to fix that, but nothing works.

I tried to install GRUB-EFI manually from terminal using the live USB. I followed wiki.archlinux.org and How to reinstall GRUB2 EFI?, but both have failed. for the 1st link, I'm succeeding but same unable to boot to Kali Linux. For the second, when I try to install grub-efi package after mounting the partitions and doing chroot, it asks to insert the Kali Linux CD/DVD in cdrom0 partition. As I'm installing from a live USB, I don't have it in CD/DVD.

I tried to do the same process what I've followed for my live USB, creating a EFI FAT32 partition in the external hard disk and copying those 2 files, but no success.

I asked a question here before. Got suggestion to edit the hard coded UEFI-BIOS. but I want to install the whole Linux OS with boot loader and EFI partition, all in my external hard disk. and set the 1st boot device as external device. So when my hard disk is plugged in, it'll boot from Linux else from Windows 7. As I've succeeded in booting the live USB, I guess, there is no problem with the hard coded UEFI-BIOS.

I tried the same process with Ubuntu by creating a Live USB, but the installation doesn't proceeds after it asks to select the network during installation. Though I select to not use the network or use the network, it doesn't proceed to the partitioning.

I got another suggestion to install the Linux using BIOS in legacy mode and then install the GRUB-EFI to convert it to boot using UEFI. But with my GPT partition, it doesn't boot in Legacy mode and with my MBR partition it doesn't boot in UEFI. So when I'll install using Legacy mode, I can't be able to boot in UEFI without cleaning the installation and converting the disk to GPT partition. So it's of no use.

Can anybody please help?

my hard disk is 1TB Seagate. (converted to GPT partition.)

Videonauth
  • 1,112
RatDon
  • 281
  • Second paragraph "but GRUB installation fails", what does this mean? What errors do you get? Also first paragraph, "EFI partition inside a directory boot", I hope you mean "EFI directory inside a boot partition". The exact commands you've run with their exact output is always best. – phemmer Feb 22 '14 at 07:12
  • @Patrick the error is as i mentioned. it shows an error that GRUB installation in to hard disk failed. and 1st paragraph means a directory boot inside EFI partition. – RatDon Feb 22 '14 at 10:49

3 Answers3

1

You probably don't need grub. The thing is - your UEFI firmware is your bootloader - it already is. When you boot through grub you actually chainload bootloaders - this is unnecessary redundancy. I use rEFInd - it's a boot manager only - it just allows you to choose what to boot then relays that back to firmware and the firmware does the booting. It's not much more than a menu.

This is a good thing because the linux kernel is an EFI-executable binary itself - you can boot linux without any boot-manager/loader at all just by execing it from firmware. I would recommend that option as well, but it's not quite as flexible as an intervening menu manager like rEFInd because you have to rely on the firmware developers to provide that interface - and that can be iffy. But if you're interested look into the efibootmgr interface - it will require setting persistent firmware variables.

The following is a tutorial on how to use first dd then gdisk to ensure you have a bootable EFI system partition.

Just to ensure the partition table is completely clear before starting, you should write over some very early blocks on that disk:

dd ibs=4M count=1 if=/dev/zero of=/dev/${USB_DISK}

Now we get into gdisk. Substitute whatever /dev/... device file your usb disk is on for /dev/${USB_DISK}:

gdisk /dev/${USB_DISK}
GPT fdisk (gdisk) version 0.8.10
Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present
Creating new GPT entries.
Command (? for help): ?

Use ? for the menu to view all options first, but the first one you need to write a clean GPT partition table is o:

...
Proceed? (Y/N): y

Next you'll need an EFI-system partition. Use the n command to create a new partition. At the below prompts where you don't see the key entered it's because I just hit ENTER to agree to the default:

Command (? for help): n
Partition number (1-128, default 1):
First sector (34-1331166, default = 2048) or {+-}size{KMGTP}:
Last sector (2048-1331166, default = 1331166) or {+-}size{KMGTP}: 500M
Current type is 'Linux filesystem'
Hex code or GUID (L to show codes, Enter = 8300): ef00

If you hit L at the last prompt above you'll get a list of all the available partition types but what you need is type ef00 for efi system partition. Do n again as many times as you need to create any other partitions you might need for / or swap or whatever. Again, use L to view the different types, but the defaul 8300 should work for all but swap.

Have a look at your new partition table with p then follow it up with w if you like looks of it to write out your pending changes:

...
Command (? for help): w

Final checks complete. About to write GPT data. THIS WILL OVERWRITE EXISTING
PARTITIONS!!

Do you want to proceed? (Y/N): y

Now create a fat filesystem on your EFI-system partition. -n names the partition. I like to use ESP:

mkfs.vfat -n ESP /dev/${USB_DISK}1
mkfs.fat 3.0.26 (2014-03-07)

Use mkfs.${desired_file_system} /dev/${USB_DISK}[num] for all other partitions you might require. It would be best if you used that filesystem's --help to find out how to specify a GPT label for the partition as well.

Get the refind.bin.*.zip you'll find here then unpack it to your disk and then we'll install your bootloader:

mkdir /tmp/refind
unzip ~/Downloads/refind-bin-0.7.9.zip -d $_  
...
$_/ref*/install.sh --usedefault /dev/${USB_DISK}
Not running as root; attempting to elevate privileges via sudo....
Installing rEFInd on Linux....
UnmountEsp = 1
Copied rEFInd binary files
Copying sample configuration file as refind.conf; edit this file to configure
...

So now you've got a bootmanager. After installing your linux system to the disk you're going to need to do the following:

mkdir -p /mnt/bootdisk/
mount /dev/${USB_DISK}1 /mnt/bootdisk
mkdir -p /mnt/bootdisk/EFI/kali_linux/
cp ${kali_root}/boot/vmlinuz-* \
    /mnt/bootdisk/EFI/kali_linux/
cp ${kali_root}/boot/initrd-* \
    /mnt/bootdisk/EFI/kali_linux/

printf %s\\n "LABEL=${GPT_LABEL} /esp vfat defaults 0 1" \
             "/esp/EFI/kali_linux /boot none bind,defaults 0 0" \
      | sudo tee -a /etc/fstab
mkdir /esp
mount -a

That just about does it. You will need to setup rEFInd a little bit. Substitute your root filesystem's GPT label for ${GPT_LABEL} below:

echo '"Kali" "root=LABEL=${GPT_LABEL} rootwait"'\
    >/mnt/bootdisk/EFI/kali_linux/refind_linux.conf

That should give you a bootable system. Please look through the main refind.conf in ../BOOT - it's very well commented and pretty much documents itself. You'll also want to head over to rodsbooks.com and read the docs there.

sourcejedi
  • 50,249
mikeserv
  • 58,310
  • @fpmurphy1 - refind is not a bootloader, but a boot manager. It just finds/tracks executable kernels and passes them as arguments to the actual bootloader - which is the EFI firmware. – mikeserv Nov 27 '14 at 17:18
  • @fpmurphy1 - well, part of the problem with that is that manufacturers typically suck at implementing useful menu management in their firmware. The UEFI spec is loose at best - while some features are reliably available, the UEFI group is a commercial group at its heart and interface is a thing the group does not specify - to allow its partners to profit. I like a common interface across systems - and rEFInd is easy to use, easy to install, very well documented, and free for all. I've yet to find an EFI interface which it could not improve. It even works with QEMU. – mikeserv Nov 27 '14 at 17:22
  • @fpmurphy1 - if you're interested, I've written more on the subject here, here, and here. If you follow only one of those links, might I suggest it be the last? – mikeserv Nov 27 '14 at 17:26
  • The UEFI specification is not "loose at best". Like many specifications developed by industry groups, it is deliberately silent on certain issues. The Tianocore reference implementation provides a TUI common interface. – fpmurphy Dec 07 '14 at 17:53
  • @fpmurphy1 - Tianocore is a reference - an Intel reference - it is not specified. And yes, UEFI is loose at best and at flux. Perhaps you remember a certain industry giant's laptop that was prone to write over the firmware modules themselves when the var storage space filled? That was a Linux+UEFI nightmare. It is, of course, a far better alternative to its predecessor - because there never was a BIOS standard of any kind. Anyway, rEFInd also provides an on-disk config file, which is convenient for me, and not a typical feature of any implementation that I know of. – mikeserv Dec 07 '14 at 18:29
  • Also remember to recopy the kernel on every kernel update, or your security-focused OS will be running 'vulnerable' code in ring 0 without you realizing. Alternatively, you could try to work out what your OS is designed to support, which will be GRUB. – sourcejedi Jun 06 '15 at 18:54
  • @sourcejedi - no, that would be ridiculous. You just need printf %s\\n "LABEL=${GPT_LABEL} /esp vfat defaults 0 1" "/esp/EFI/kali_linux /boot none bind,defaults 0 0" | sudo tee -a /etc/fstab. In fact, with only that one little fstab tweak, you can easily centralize any/all various os boot partitions into a single, readable-at-boot, directory tree. And you don't need any over-conflated nonsense like grub - just the fact that the kernel's fs location is even a consideration on a system which supports mounts in firmware shows out what a terrible influence grub is. – mikeserv Jun 06 '15 at 19:02
  • Done. Not sure how this invalidates my point about unsupported system configurations from random websites having caveats you're not aware of :). Shame not to have the simple version for chain-loading grub as well though, it makes Linux look unnecessarily awkward. That is, I assume refind will present a Windows option here without needing to reconfigure Windows. – sourcejedi Jun 06 '15 at 21:57
  • @sourcejedi - that is a rather good point. I never argued that this was a good answer, only that grub sucks. I've done better before. You have my apologies if you did this only to justify your very valid complaint. – mikeserv Jun 06 '15 at 23:55
  • @sourcejedi - and yes, refind handles windows admirably well. But really it doesn't - because it doesn't handle much at all. That's the primary difference between a bootloader and a bootmanager - the former actually executes kernel code in memory, whereas the latter draws a few menus on the screen and passes the menu selection over to the firmware to do the hard part. grub is redundant, and so refind doesn't have to work as hard to be way better. – mikeserv Jun 06 '15 at 23:58
  • @sourcejedi - oh, and last - grub and linux are not the same thing. If you look at the inordinately insane amount of work that goes into grub2's update process, and compare it to this, I think you may find that statement worth revisiting. The fact is this uses basically only the prescribed kernel execution process - which is execute the kernel at boot and append its inital root image to its memory space - you should probably just put both of those files in /boot as opposed to the script generating script altering partition structure generating script solutions offered elsewhere. – mikeserv Jun 07 '15 at 00:19
0

As you have difficulty to boot a device in EFI interface you can use existing windows boot loader.

There are 2 things to do
1. Install Linux OS (Kali) as usual but at GRUB install step select your root partition to install the GRUB instead of the whole disk. i.e sda7 not sda (Assuming sda7 is partition selected as root for installation )
2. Download grub2win and copy to root of windows OS.
3. Make a Linux entry on your windows boot loader, by Chainload to root partition from grub. To do open
grub2win -> manage -> add new -> os -> ubuntu -> chainload -> partition

Change
Ubuntu to your OS, if necessary.
Partition to correct partition number (remember sda7).
Save changes, reboot. Now you can select GRUB from windows boot loader then Linux.

RatDon
  • 281
totti
  • 1,484
  • I've copied grub2win to windows root. made an entry for debian-kali 1.0.5. My partition was sdc3. and yet i'm unable to boot to it. windows starts automatically. – RatDon Feb 22 '14 at 06:34
0

For the moment I've installed grub-pc to a MBR partitioned pen drive. Installed Kali Linux to a GPT partitioned external hard disk. each time I want to use Kali Linux, I'm toggling the BIOS settings to Legacy and insert the pen drive to boot. GRUB chain loads it to my hard disk where the Linux is installed and it's working fine for me for the moment. But it's a alternative method and still waiting for my problem to be resolved.

RatDon
  • 281
  • If you're still waiting for a proper resolution, I would unmark your answer as accepted. Once it's accepted, people generally are going to answer any more. – phemmer Feb 22 '14 at 07:13
  • @Patrick ya.. unmarked it. don't know if i'd get any solutions or not... still hoping for it. – RatDon Feb 22 '14 at 10:45