# UEFI boot on Asus Sabertooth 990FX

## sgarcia

I just got a new Asus Sabertooth 990FX motherboard (with associated processor and memory) as well as a 64G SSD to be the new system drive.  

That means that in addition to dealing with new motherboard issues, I get to install a new system onto a new drive.  I figured as long as I'm starting with a new drive, I'd try to install it using the EFI boot process.  This motherboard supports BIOS boots as well as (reputedly) EFI boots.  Almost all of the EFI supporting boot manager installation procedures seem to expect that you're doing them from a system already booted in EFI mode.  Since the new kernels can provide their own EFI bootloader if properly configured, this would seem to be do-able, if a bit fiddly.

But so far, I've had no luck at all.  My old disk still boots fine in MBR mode (once I switched all fstab and grub references from sda to sdb.)  But the boot process doesn't even give me a failed boot from the SSD -- it skips right to the old disk unless I disable sdb completely, at which point it just tells me to insert boot media.

Here's what I've got set up.  Using gparted I created GUID partitions 

```
/dev/sda1     FAT32   Boot Flag  at /boot/efi

/dev/sda2     ext2               at /boot

/dev/sda3     ext4               at /
```

I've included the efi shell in efi/EFI/tools/ as well as in the efi base directory (efi/).  I've included a kernel with all the EFI options and a initramfs in efi/EFI/gentoo, and I compiled in a command line so the kernel can (we hope) find its initramfs.  If I got that wrong, it might fail to boot successfully, but that would be progress.  As it is, the SSD is just ignored, even though it's first (and sometimes only) in the boot order.

My understanding is that if I have a FAT32 partition flagged as a GUID boot partition, it should offer me the chance to boot from files on that partition.  If the efi shell would load, presumably I could get it to boot the kernel I have there.  I can't find anything in the EFI motherboard settings (I guess we can't say BIOS) that might govern this.  There is a "tools" menu that among other things allows me to place a flash file in the EFI area and flash the BIOS^h^h^h^h firmware, and *that* actually allows me to navigate that partition, so I know the motherboard can see that partition.  

I'm obviously confused about something.  This sees like a chicken and egg situation -- once I get booted in EFI mode I can install all kinds of boot managers, but I have to get that first one going.  What am I doing wrong?

Since this motherboard supports BIOS boots, I can easily repartition and just use a BIOS mode setup, but I hate to give up on this.

----------

## platojones

Welcome to the UEFI club...it's a wild ride...but kinda fun once you get over the dizzyness.

You're on the right track, but I think you skipped a few steps.  A EFI system partition isn't enough to get the UEFI interface (or BIOS) to see a bootable disk...it needs the proper boot structure and the boot system files...otherwise, there's nothing there for the UEFI interface to work with and it'll just skip the whole thing.  I'm using grub2, and my grub boot file is /boot/efi/EFI/Boot/BOOTX64.EFI...it's just the grub2 bootloader UEFI application.  But I'm getting ahead of myself.

My board (an ASUS RIVE), has an option in the boot EXIT menu to launch an EFI shell...you might want to see if yours has that...or something similar.  I didn't find the EFI shell very useful though.

My advice would be to decide which way you want to go with your boot loader (for instance, if you want a multi-boot system, I would say go with grub2...if only Gentoo, then maybe set up a direct EFI kernel boot.  There are other options like rEFInd, whose author has some posts here in the forums). 

Here's a few links that helped me get thru it all:

http://en.gentoo-wiki.com/wiki/UEFI

http://wiki.gentoo.org/wiki/GRUB2

http://www.rodsbooks.com/refind/

Lot of very good info in the ArchLinux docs too...

Anyway, your partition layout is very similar to the one I used as well...so I can say that will definitely work with grub2.

If you decide to go with grub2, I can help a bit on that, since that's the way I went...but I'm no expert, by any means.

----------

## srs5694

Platojones has provided some good basic information. I'd like to elaborate a bit, though....

The EFI/boot/bootx64.efi file on the ESP is a sort of "default" or "fallback" EFI boot loader. Theoretically, EFI systems should boot using the boot loaders described in NVRAM, and they should provide some sort of boot manager to let you select from among these. Of course, if you're starting from scratch, you won't have any entries there. Normally, OS installers create suitable NVRAM entries, but with Gentoo you'd have to set it up yourself with the efibootmgr utility from an EFI boot, so you'd need to use something like an Ubuntu live CD (which has EFI support) to add your NVRAM boot loader entries. Some EFI implementations provide menus from which you can add boot loaders to the NVRAM list, too. Many EFI implementations provide poor options or are flaky in one way or another. Thus, it's often easier to use the EFI/boot/bootx64.efi name for your primary boot loader (ELILO, GRUB, rEFInd, an EFI-enabled kernel, or whatever).

You might consider downloading the rEFInd CD image. (See the Getting rEFInd page for links.) With any luck, it will boot in EFI mode and, if you've installed other boot loaders on your disk, will let you launch them. If you've got an otherwise working Gentoo system, this will get Gentoo up and running in EFI mode, you can emerge efibootmgr, and add an NVRAM entry for the boot loader you want to use. (Note: I'm rEFInd's maintainer.)

FWIW, I've got a Web page on EFI boot loaders. In my experience, the kernel's EFI stub loader is the most reliable EFI boot loader for Linux, but to make it practical you'll need either a good boot manager in your EFI or a separate boot manager such as rEFInd. ELILO comes next in reliability, followed closely by Fedora's patched GRUB Legacy. GRUB 2 comes dead last in my experience; it's very finicky and unreliable. That said, there are significant system-to-system differences in boot loader reliability. Some people have no problems with GRUB 2, for instance, and others can't get GRUB Legacy or ELILO to work. You may need to try two or three before you find one that works. Fortunately, EFI makes trying new boot loaders relatively painless compared to the same process in BIOS, at least once you've wrapped your brain around the way EFI handles boot loaders.

----------

## Xytovl

There is a lot of voodoo in EFI boot, I am sure firmwares are as buggy as BIOS are.

I have a working setup on a Samsung laptop (pheonix firmware), here is parted output:

```
Partition Table: gpt

Disk Flags: 

Number  Start   End     Size    File system     Name                  Flags

 1      1049kB  20.0GB  20.0GB  ext4            root

 3      20.0GB  20.0GB  19.7MB  fat16           EFI System Partition  boot

 4      20.0GB  22.0GB  1981MB  linux-swap(v1)  swap

 2      22.0GB  64.0GB  42.0GB  ext4            home
```

I think the name of the partition is supposed to be the key for the firmware to find it.

I don't know why, but automatic boot refuses to start anything else than boot/bootx64.efi, if I choose the entry in manual boot selector (pressing esc) entries created with efibootmgr work.

----------

## srs5694

 *Xytovl wrote:*   

> There is a lot of voodoo in EFI boot, I am sure firmwares are as buggy as BIOS are.

 

More so, if anything. EFI is newer and the code base is bigger. It's comparable in size to the core of the Linux kernel (stripped of its drivers).

 *Quote:*   

> I think the name of the partition is supposed to be the key for the firmware to find it.

 

No, the firmware uses the partition type code to identify the ESP. GNU Parted doesn't normally report the type code, although in the case of ESPs, it identifies them as having the "boot flag" set. GPT includes a name field, but the firmware ignores that. Note that the GPT name for the partition is independent of the filesystem label. Most partitioning tools report one or the other but not both, so the name can seem to change if you switch from one partitioning tool to another.

----------

## jathlon

I'm playing with a Sabertooth 990FX board as well.  I just stuck mine under my old Phenom X6 and threw more ram and a pair of GT 570's on it. (Playing in Blender is my current obsession).

The easiest way I found to boot into UEFI mode was to use a CD.  Probably due to my own lack of knowledge I never figured out how to get the UEFI boot mode to happen with a USB stick.  Might have also been a limitation of the firmware interface. (Yea, let's go with that)  Using a CD the UEFI option was obvious.

The first boot CD I burned was Kubuntu, so that was were I began my odyssey.  There may be others but by the time I stumbled on the concept of using a boot CD I was sick of downloading distros and using various methods to install the iso's  to the flash drives, so Kubuntu was what I used to do my install.

Hope that's enough to get you started in the right direction for the simple reason that I'm still not really sure what the h*** I did that got it going.

Good luck,

joe

----------

## sgarcia

Thanks to everyone.  

I guess what I need to do is boot from an EFI enabled CD.  I have been using the Gentoo DVD as my install platform, but I didn't even think to check whether it boots into EFI mode.  I had already downloaded the rEFInd CD image, but hadn't tried it either.  I'll do that when I get home tonight.

I may also try copying my EFI enabled kernel to EFI/boot/bootx64.efi and see if it will work even without installing a boot manager first, but that will be mainly just to see if I can do it.  Ultimately rEFInd is probably going to be my method, but we'll see once I get it booted the first time (to the new disk.)

I had set up a /boot partition as well as the ESP which will be mounted at /boot/efi:

```
Partition Table: gpt

Number  Start   End     Size    File system  Name  Flags

 1      1049kB  269MB   268MB   fat32              boot

 2      269MB   672MB   403MB   ext2

 3      672MB   64.0GB  63.4GB  ext4
```

I'll be keeping the spinning drive for /home and /var.

----------

## srs5694

Sgarcia, your partitioning looks reasonable from an EFI point of view. There are ways you can optimize what you put on an SSD vs. a spinning disk, but that's a whole different topic....

Anyhow, if your kernel is properly compiled and if its options are right, setting it up as EFI/boot/bootx64.efi on the ESP will probably get it booted and working. The problem is that the command-line options can be a bit fiddly for the EFI stub loader. For instance, the initrd specification has to be a complete path from the ESP's root, and I'm pretty sure it needs to use backslashes rather than the more normal (in Linux) slashes as directory separators. Thus, you might need to recompile the kernel a few times before you get it right, or (much easier) launch it manually from an EFI shell. Other options include using Ubuntu or some other EFI-enabled system to get started and chroot into the Gentoo installer; or install in BIOS mode and then switch boot modes after you've got at least a basic Gentoo system up and running.

----------

## jathlon

 *sgarcia wrote:*   

>      but I didn't even think to check whether it boots into EFI mode.  

 

On my Sabertooth two options would appear for the CD.  One would be just the plain name of the CD drive, and the second would be prefixed with UEFI.  And never one right after the other.  They would often be seperated by other drives, internal, usb, esata, etc.

When I look in the /sys/firmware/... etc. directory there is a bunch of stuff.

```
~ # ls /sys/firmware/efi/vars/

AMIMemInfo-43387991-1223-7645-b5bb-aa7675c5c8ef          ConErrDev-8be4df61-93ca-11d2-aa0d-00e098032b8c          MemoryS3SaveNv-b1cfc482-4cb2-4cee-9b00-ce2579ec7186         PNP0510_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031       Timeout-8be4df61-93ca-11d2-aa0d-00e098032b8c                             dump-type0-3-1336236811-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

AMITSESetup-c811fa38-42c8-4579-a9bb-60e94eddfb34         ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c              MemoryS3SaveVol-0a51b41d-de21-43fe-be27-d6dbc9efd104        PNP0510_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031       UMAVar.-8be4df61-93ca-11d2-aa0d-00e098032b8c                             dump-type0-4-1336236811-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

AcpiGlobalVariable-af9ffd67-ec10-488a-9dfc-6cbf5ee22c2e  ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c           MemoryS3SaveVolLength-0a51b41d-de21-43fe-be27-d6dbc9efd104  PNP0604_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031       UMAVarB.-8be4df61-93ca-11d2-aa0d-00e098032b8c                            dump-type0-5-1336236812-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c            ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c             MonotonicCounter-8be4df61-93ca-11d2-aa0d-00e098032b8c       PNP0604_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031       UsbMassDevNum-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9                       dump-type0-6-1336236812-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

Boot0001-8be4df61-93ca-11d2-aa0d-00e098032b8c            ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c          NBMemoryLength-490216c0-076a-44d3-a536-ace05c90e386         PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c       VARSTORE_OCMR_SETTINGS_NAME-c05fba7d-7a92-49e0-bcee-233b14dca803         dump-type0-7-1336236812-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

Boot0002-8be4df61-93ca-11d2-aa0d-00e098032b8c            CpuS3Resume-30b98b95-dfa3-4501-a3ce-e38c186384a0        PNP0400_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031           PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c  VARSTORE_OCMR_TIMING_SETTINGS_NAME-93c483a1-d3fa-4e92-b437-733b2a346e23  dump-type0-8-1336236812-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

Boot0003-8be4df61-93ca-11d2-aa0d-00e098032b8c            HpcModeBU-8be4df61-93ca-11d2-aa0d-00e098032b8c          PNP0400_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031           Setup-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9              del_var                                                                  dump-type0-9-1336236813-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

Boot0004-8be4df61-93ca-11d2-aa0d-00e098032b8c            Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c               PNP0501_0_NV-560bf58a-1e0d-4d7e-953f-2980a261e031           SetupAccFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9   dump-type0-1-1336236811-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0             new_var

BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c         LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c          PNP0501_0_VV-560bf58a-1e0d-4d7e-953f-2980a261e031           SetupCpuFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9   dump-type0-10-1336236813-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c           LegacyDevChecksum-a56074db-65fe-45f7-bd21-2d2bdd8e9652  PNP0501_1_NV-560bf58a-1e0d-4d7e-953f-2980a261e031           SetupHWMFeatures-ec87d643-eba4-4bb5-a1e5-3f3e36b20da9   dump-type0-11-1336236813-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0

CMOSfailflag-c89dc9c7-5105-472c-a743-b1621e142b41        LegacyDevOrder-a56074db-65fe-45f7-bd21-2d2bdd8e9652     PNP0501_1_VV-560bf58a-1e0d-4d7e-953f-2980a261e031           StdDefaults-4599d26f-1a11-49b8-b91f-858745cff824        dump-type0-2-1336236811-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
```

joe

----------

## sgarcia

Well, the rEFInd CD didn't boot at all.  When I go into the boot menu, I only see one entry for the CD.  

I'm currently downloading the Ubuntu 12.04 CD -- maybe that will make it happier and the boot menu will show me two options.

I hadn't seen the "Exit" menu from the firmware before.  When I trigger the EFI shell I get what looks like a missing library error -- I can't cut and paste that, maybe I should write it down next time.

Here's the command line I have compiled into my kernel:

```
CONFIG_CMDLINE="root=/dev/ram0 init=/linuxrc ramdisk=8192 real_root=/dev/sda3 udev  initrd=EFI\\gentoo\\initramfs-genkernel-x86_64-3.3.4-gentoo"

```

But if I got that wrong I would expect to see some evidence that my EFI kernel had failed, maybe halt the machine.  I don't get that though, it just goes straight to the /dev/sdb BIOS boot using GRUB.

----------

## platojones

Getting booted up with a UEFI enabled linux kernel was the toughest part for me...I finally did it by loading the Archlinux archboot ISO image on a USB (not the normal Archlinux install ISO).  Nothing ever worked for me when booted from cdrom...including Ubuntu.

----------

## sgarcia

 *platojones wrote:*   

> Getting booted up with a UEFI enabled linux kernel was the toughest part for me...I finally did it by loading the Archlinux archboot ISO image on a USB (not the normal Archlinux install ISO).  Nothing ever worked for me when booted from cdrom...including Ubuntu.

 

I'm right there with you.  The Ubuntu CD boots, but it doesn't boot into EFI mode.

I've got a spare USB here, guess I'll be downloading the Archlinux usb image.

This is what I get when I choose EFI shell from the Exit menu.

```
ASSERT_EFI_ERROR (Status = Not Found)

ASSERT c:\dev\shellbinddev\MdeModulePkg\Library\UefiHiiServicesLib\UefiHiiService

sLib.c(88): !EFI_ERROR (Status)
```

It may be that I don't have the shell in the right place.  

```
efi/EFI/tools/shellx64.efi

efi/shellx64.efi
```

----------

## jathlon

I'm also running the latest "bios" from ASUS for the board.  Version no. 1102.  

Not sure if that actually makes a difference or not.  Never tried the CD thing until after I updated.

joe

----------

## platojones

 *Quote:*   

> I'm right there with you. The Ubuntu CD boots, but it doesn't boot into EFI mode. 
> 
> I've got a spare USB here, guess I'll be downloading the Archlinux usb image. 
> 
> This is what I get when I choose EFI shell from the Exit menu. 
> ...

 

Make sure and use the archboot ISO from here:

https://wiki.archlinux.org/index.php/Archboot

And I had similar problems with the newest EFI shell as well...the only one that would work for me was the older 1.0 version.

----------

## sgarcia

Well, mixed success.  I upgraded to firmware 1102, but as near as I can tell it didn't make any difference.  Neither the CDROM nor the USB gives me any indication of being UEFI, and they both boot into the BIOS mode.

I downloaded the newer Archlinux, but it still boots in BIOS mode.

I downloaded the older EFI shell, and it *does* boot now, so I'm encouraged.  But the help command runs off the top of the terminal, so I think I'm going to have to study its commands from the web and take it up later.  Then we hope the kernel I created was properly configured to boot...

This is obviously going to be a multi-day project. :/

----------

## platojones

 *sgarcia wrote:*   

> Well, mixed success.  I upgraded to firmware 1102, but as near as I can tell it didn't make any difference.  Neither the CDROM nor the USB gives me any indication of being UEFI, and they both boot into the BIOS mode.
> 
> I downloaded the newer Archlinux, but it still boots in BIOS mode.
> 
> I downloaded the older EFI shell, and it *does* boot now, so I'm encouraged.  But the help command runs off the top of the terminal, so I think I'm going to have to study its commands from the web and take it up later.  Then we hope the kernel I created was properly configured to boot...
> ...

 

I had to use the F8 boot menu key to bring up the boot menu to boot the archboot USB stick in UEFI mode.  It never selected that option by default for some reason.

In any event, if you can boot the EFI linux kernel from the EFI shell, that should do the trick.  It gets much easier when you finally get a UEFI kernel booted.  Hang in there.

----------

## srs5694

 *sgarcia wrote:*   

> Well, the rEFInd CD didn't boot at all.  When I go into the boot menu, I only see one entry for the CD. 

 

It sounds like you're having problems with EFI-mode boots from CD in general on this machine.

If you want to try to get rEFInd working early in the process vs. late, you could partition your hard disk using GPT, at least enough to create an EFI System Partition (ESP), and install rEFInd on there as EFI/boot/boot64.efi, as described on the Installing rEFInd page. With any luck, that'll get rEFInd booted up, and you might then be able to select boot loaders on USB flash drives, and perhaps even on CDs. (Your odds of success with CDs might go up if you install an EFI ISO-9660 driver, as described here.)

 *Quote:*   

> This is what I get when I choose EFI shell from the Exit menu.
> 
> ```
> 
> ASSERT_EFI_ERROR (Status = Not Found)
> ...

 

It's more likely that you're running an incompatible version of the shell. All but the most recent UEFI implementations should use a shell with a 1.0 version number. You can sometimes get lucky with a newer shell on a somewhat older EFI, but as often as not you'll run into problems like that one. You can find download links for both varieties here.

 *Quote:*   

> Well, mixed success. I upgraded to firmware 1102, but as near as I can tell it didn't make any difference. Neither the CDROM nor the USB gives me any indication of being UEFI, and they both boot into the BIOS mode. 

 

I don't know about your system specifically, but some EFI implementations try to figure out whether to use an EFI-mode or a BIOS-mode boot by doing things like looking for a boot loader in the hard disk's MBR, examining the size of the hard disk, or examining the partition table type on the hard disk. The rules used are invariably undocumented or poorly documented, so it takes a lot of experimentation to figure out how to do what you want. Generally speaking, though, making your hard disk look as much like a regular boot disk for an EFI-based system as possible can't hurt your chances to coax an EFI-mode boot out of the thing.

 *Quote:*   

> I downloaded the older EFI shell, and it *does* boot now, so I'm encouraged. But the help command runs off the top of the terminal

 

Try adding "-b" to the command, as in "help -b". That invokes a simple pager, similar to "more".

----------

## jathlon

What are you using for a cd/dvd player?  I've got just a low end Liteon SATA CD/DVD writer/player.  And like platojones suggested, I have to hit F8 while the firmware is still loading to get to the boot media selection screen.

Isn't being an early adopter of new tech fun.

joe

----------

## jms.gentoo

hey just joining the efi boot club.

I advise  you to use http://www.sysresccd.org

It's well done

its based on gentoo, its kernels are efi enabled ,one can use it as a gentoo install cd

well as from me I try to install gentoo on a macbookpro.

goal dual boot with osx at the moment.

 and using grub2 efi gpt

I have efi working (looks like)

I get into grub2 boot menu but have problem there (file missing or modules)

using grub-2.00-beta4

with a fat partition for /boot and  I use as efi

and partition for /usr another for portage and another for home..

----------

## sgarcia

Gar!  Had this whole post almost finished when my nVidia card at work "fell off the bus."  Grr.

I had a few minutes yesterday to work on this.

 *srs5694 wrote:*   

> 
> 
> It sounds like you're having problems with EFI-mode boots from CD in general on this machine.

 

Yes.  I can't even see the optical drive from the EFI shell.  "map" shows all partitions from both the SSD and the HDD, but not the DVD.

 *srs5694 wrote:*   

> If you want to try to get rEFInd working early in the process vs. late, you could partition your hard disk using GPT, at least enough to create an EFI System Partition (ESP), and install rEFInd on there as EFI/boot/boot64.efi, as described on the Installing rEFInd page. With any luck, that'll get rEFInd booted up, and you might then be able to select boot loaders on USB flash drives, and perhaps even on CDs. (Your odds of success with CDs might go up if you install an EFI ISO-9660 driver, as described here.)

 

Ah!  Maybe that ISO9660 driver will make my optical drive visible.

 *srs5694 wrote:*   

> 
> 
> I don't know about your system specifically, but some EFI implementations try to figure out whether to use an EFI-mode or a BIOS-mode boot by doing things like looking for a boot loader in the hard disk's MBR, examining the size of the hard disk, or examining the partition table type on the hard disk. The rules used are invariably undocumented or poorly documented, so it takes a lot of experimentation to figure out how to do what you want. Generally speaking, though, making your hard disk look as much like a regular boot disk for an EFI-based system as possible can't hurt your chances to coax an EFI-mode boot out of the thing.

 

Rather than partition my hard drive, maybe I should just pull the SATA cable off so that only the SDD is hooked up.  It's already partitioned with GPT, although without a boot loader.  The HDD *will* be used ultimately, as /home and as /var, but I don't really need it now, until I get the EFI stuff working.  Maybe the fact that the HDD is there and has a boot loader is masking the EFI stuff.

 *srs5694 wrote:*   

> Try adding "-b" to the command, as in "help -b". That invokes a simple pager, similar to "more".

 

That helped.

But I've got some weirdness with the ESP.  I have two directories in the root of the ESP, EFI and GRUB2.  GRUB2 is just a stub I put in before I realized I'd have to get booted into EFI first, so it's completely empty.  EFI has a number of subdirectories, holding things like my kernel, the initramfs that goes with it, copies of the shell, of rEFInd, and of the ROM for the newer firmware.

However, cd and ls/dir both refuse to do anything with EFI, telling me that "EFI is not a valid directory."  They work fine with GRUB2, which is empty.  It's also interesting that when I booted into the firmware itself to flash the new ROM, the integrated flashing tool refused to descend into EFI, so I had to boot to linux to copy the ROM file to the root of the ESP.  Then it worked fine.

I was also able to boot into linux and copy my kernel to the root, and the EFI shell allowed me to launch the kernel.  It failed, of course, barfing on the inaccessible initramfs, but it did try.  Baby steps.  I guess I'll copy rEFInd into the root as well, but if I can't get to anything in a subdirectory with children of its own, I may have a problem.  I ran out of time, I didn't test to see if that's the problem with accessing that directory, but *something* is the matter.  Maybe I just need to delete that directory and start again.

 *jathlon wrote:*   

>  What are you using for a cd/dvd player? I've got just a low end Liteon SATA CD/DVD writer/player. And like platojones suggested, I have to hit F8 while the firmware is still loading to get to the boot media selection screen.  

 

It's a Samsung SATA DVDRW, not sure the model right now.  It does show up when I hit F8, but only one instance, evidently the BIOS version.

 *jathlon wrote:*   

>  Isn't being an early adopter of new tech fun.  

   Yeah.  :/  I feel like a real pioneer.  Arrows in the back to prove it.

----------

## srs5694

 *sgarcia wrote:*   

> Gar!  Had this whole post almost finished when my nVidia card at work "fell off the bus."  Grr.

 

I feel your pain. I've had things like that happen, too!

 *Quote:*   

>  *srs5694 wrote:*   
> 
> It sounds like you're having problems with EFI-mode boots from CD in general on this machine. 
> 
> Yes.  I can't even see the optical drive from the EFI shell.  "map" shows all partitions from both the SSD and the HDD, but not the DVD.

 

Try "map -u" and/or "map -r". Those commands tell the EFI to re-map drives. It's conceivable that one of them will get the CD to show up, particularly if you try loading an ISO-9660 driver first.

OTOH, it's possible that nothing will work. I've got a laptop like that. It's not actually EFI-based, but I use it with DUET, which is essentially UEFI in software for BIOS-based computers. When DUET is booted, it refuses to "see" the optical drive, no matter what I do with it.

 *Quote:*   

> Rather than partition my hard drive, maybe I should just pull the SATA cable off so that only the SDD is hooked up.  It's already partitioned with GPT, although without a boot loader.

 

Simplifying is always a good step in troubleshooting.

 *Quote:*   

> But I've got some weirdness with the ESP.  I have two directories in the root of the ESP, EFI and GRUB2.  GRUB2 is just a stub I put in before I realized I'd have to get booted into EFI first, so it's completely empty.  EFI has a number of subdirectories, holding things like my kernel, the initramfs that goes with it, copies of the shell, of rEFInd, and of the ROM for the newer firmware.
> 
> However, cd and ls/dir both refuse to do anything with EFI, telling me that "EFI is not a valid directory."  They work fine with GRUB2, which is empty.

 

It sounds like you've got some filesystem corruption. You could try using dosfsck on the ESP (or CHKDSK from Windows). If that doesn't help, back up all the files, create a fresh FAT32 filesystem, and restore everything. If the EFI can't access anything in the EFI directory, then you're going to go nowhere fast.

----------

## jathlon

 *srs5694 wrote:*   

> OTOH, it's possible that nothing will work. 

 

Which would be  a little strange since I have the same m/b.   Just checked;  right by the where the Sabertooth 990FX is silk screened onto the motherboard it says Revision 1.01.

A place I worked at had a lot of machines that were suppose to be identical.  Turned out while the m/b's were the same model #, there was a few different revisions of said model.  Caused a lot of interesting problems until that was sorted out.

joe

----------

## sgarcia

Woohoo!  I'm posting this from an EFI booted Ubuntu disc!  Had to manually set up the network and remove network manager which kept disconnecting me.  And endure my first real brush with Unity.  But that doesn't matter.  It's in EFI mode!

The magic formula?  Unplug the DVD from the SATA II port and plug it into the SATA III.  Makes no sense, but it seems to be working.

The UEFI option now appears in the firmware settings, and F8 gives me a UEFI option.  I didn't even bother trying the EFI shell, went straight to the DVD boot.

Oh, and I renamed the EFI and GRUB2 directories and then renamed them back, and now everything is happy.  Black magic.  Maybe it was sacrificing that goat.

Now I'll try working my way through the actual setup.  That may be tomorrow's project.

----------

## srs5694

 *sgarcia wrote:*   

> The magic formula?  Unplug the DVD from the SATA II port and plug it into the SATA III.  Makes no sense, but it seems to be working.

 

I should have thought of that! The port to which a device is attached can be an issue on many systems (even under BIOS). These ports are often handled by different chipsets, or at least different components of a single chipset, and may require different drivers. Annoyingly, manufacturers don't always provide equivalent driver support for all their ports in their own firmware. IMHO, they should cover such ports with a sticker that reads "WARNING: WON'T WORK AS BOOT DEVICE!"

Anyhow, I'm glad you've finally gotten it booted. With any luck you'll make rapid progress from here onward.

----------

## jathlon

 *sgarcia wrote:*   

> Woohoo!  I'm posting this from an EFI booted Ubuntu disc!

 

Congratulations.

 *sgarcia wrote:*   

> And endure my first real brush with Unity.

 

Heheh.  That's _why_ I used kubuntu.

joe

----------

