ASUS U24a can't boot without live disk

Question

I recently picked up a new ASUS U24a while travelling in asia. I've managed to go through hell with the UEFI setup, and finally now have a working GRUB.

However, I can't manage to get past the "Loading initial ramdisk".

If I boot the live CD-USB (only in BIOS legacy mode), I get a wonderful, working Ubuntu.

I finally managed to get UEFI installed on the hard-drive (no option for legacy BIOS boot, or I'd be there in a flash!), and can boot in UEFI mode into GRUB2.

But... I can't manage to get past the "loading initial ramdisk". It appears that the disk drivers are failing (there is no disk activity after this point).

Ideas? pastebin from the boot-repair is at: http://paste.ubuntu.com/1290011/

best, -tony

New (22.10.2012): Well, one of the problems seems to be that when I boot in UEFI mode, the hard disk is NOT recognized by the boot loader. It's a standard GPT formatted disk, but the boot loader (grub command line, or shell.efi's) can't seem to find it. Thoughts for what to load in order to get it recognized? I've tried loading part_gpt and similar other obvious candidates ingrub, but does any one have an incantantion I can study for "installing" a disk which is not seen?

So here's what really bugs me -- if I boot in legacy compatibility mode from the USB sticks, I get ALL of the file systems (hd0, hd1), but if I boot in UEFI mode, I just get the USB stick. Does this have anything to do with a secure UEFI safe mode, or something? Or something else?

Answer 1

I keep seeing reports that GRUB 2's EFI support has improved recently, but every time I've tried it, it's been awful. I have yet to try Ubuntu 12.10, so I don't know if the version of GRUB 2 it includes is any better. If not, my suspicion is that you're running into a GRUB 2 problem; but it's also possible that my bad experiences with GRUB 2 are poisoning my interpretation of your problem.

In any event, if I'm right, my suggestion is to install another boot loader and try using it. Your Boot Info Script output suggests you've already got an ELILO configuration set up, so you could just try copying your Ubuntu kernel and initrd file and editing elilo.conf (probably in EFI/debian on your ESP, /dev/sda1) to boot Ubuntu. If your ELILO isn't working, though, you might try rEFInd, which is capable of directly booting a Linux 3.3.0 or later kernel, which Ubuntu 12.10 provides. (This assumes, however, that Ubuntu has included the EFI stub loader support in their kernel. I don't know if they've done so.) The rEFInd documentation includes a section on booting Linux. In brief, you would:

1. Install rEFInd according to its documentation.
2. Create a refind_linux.conf file that includes your kernel options. (According to your Boot Info Script output, root=UUID=1de654ef-3c5e-4d17-8fc8-8490926d8d76 ro quiet splash i915.modeset=0 xforcevesa should work. See the rEFInd documentation for details of the refind_linux.conf file format.) Place this file where your kernels reside on the ESP (copied in the next step).
3. Copy your kernel (vmlinuz-*) and initrd (initrd*) files from your Ubuntu /boot directory to the EFI/ubuntu directory on your ESP (your /dev/sda1), renaming the kernel file so that its name ends in .efi.

When you reboot into rEFInd, you should then see a new option in its menu for launching Ubuntu. If this process works, you can take some steps to ensure that rEFInd picks up your future kernel updates automatically. (The easiest is to reconfigure your system to mount the ESP as /boot and change refind.conf to uncomment the scan_all_linux_kernels option.)

Another observation: Your /dev/sda4 is incorrectly flagged in your partition table as an ESP. This is unlikely to be causing your current problem, but it could cause difficulties in the future. I recommend you fix it. You can do this in GNU Parted or GParted by removing the boot flag from the partition or in gdisk by changing the type code from EF00 to 8300. The latter is preferable on a dual-boot system, since your libparted will probably give the partition an improper type code for Windows rather than for Linux. (This bug will be fixed in the next version of libparted, which is due out this month.)