Unable to install Ubuntu/Kubuntu/Lubuntu 13.04 UEFI on Sony Vaio SVE17137!

Background/Hardware:

• Sony Vaio SVE17137 CXB, pre-installed with Windows 8
• Intel Core i7-3632QM
• Mobile Intel® HM76 Express Chipset
• AMD Radeon HD7650M
• 16 GB RAM
• 1 TB internal drive
• Windows 8 wiped. No dual boot.
• Secure Boot is turned off.
• UEFI is on.

Booting any of the (U/Ku/Lu)buntu installations, I get the split screen error that others have reported with the latest AMD Mobile Graphics controllers. This isn't a problem. Once the installation is complete (assuming it does complete), I simply install the latest Catalyst distribution, and the split screen problem is gone.

Regardless of which distribution I use, my disk is partitioned as follows:

• /dev/sda: GPT Partition Table
  1. /dev/sda1: 256 MB EFI boot partition (automatically mounted on /boot/efi)
  2. /dev/sda2: 16 GB swap partition (Overkill. I know.)
  3. /dev/sda3: 900+ GB ext4 partition mounted on /

Every attempt at installing one of the three Ubuntu distributions mentioned above fails in some way!!!

Kubuntu (which I prefer) and Lubuntu fail before completion of the installation.

In both cases, I boot up the CD's, and select "Try Ubuntu". Once in the booted OS (which do work just fine, BTW!), I select "Install Ubuntu".

I partition my disk as above, and let it run. Both versions fail with one of two fatal errors:

• "subprocess installed post-installation script returned error exit status 17"
• "grub-install dummy fatal error"

The latter sometimes reports a different grub-install failure, which I've unfortunately forgotten to write down, but it's essentially the same.

Regardless, there is no reason for these to fail! My partitioning is as simple as possible, and I'm not trying to do anything more than install a single OS! I understand the difficulties with dual booting. They don't apply.

I should add that I've also tried selecting the "entire disk" partitions, where the installer partitions the disk itself. I've tried both using and not using LVM. The installations fail in the exact same way! (And, it should be noted, the partitions created by the installer are essentially the same as mine.)

So, even with virtually zero customization on my part, these installers fail!!!

The Ubuntu installation acts somewhat differently. It will sometimes just crash on me, but usually it installs successfully! When I try to log in, the interface freezes. That is somehow linked to the AMD split screen error.

At that point I just open a console and install the AMD Catalyst. The split screen error and the login freeze both go away.

I log in, and get a blank screen! That's ALL!!! I can right click and change my background. I can create a new document or a new folder. Nothing else!

The desktop manager doesn't start. I've re-installed at least a dozen times with the same exact results!

Please note, I've searched and searched for explanations to these errors. I've tried every single fix I've been able to find. NONE of them have helped!

Any help would be greatly appreciated!

EDIT: 5/11/2013

With the help of Rod Smith's response, I now have more information to add to my attempts to install Kubuntu... (Although I'm still failing!)

The first error message I referenced:

• "subprocess installed post-installation script returned error exit status 17"

was due to the fact that I'd stupidly turned Secure Boot back on to test it, and then promptly forgot that I'd done so!

After turning Secure Boot off again, I'm back to the second error:

• "grub-install dummy fatal error"

Rod, in answer to your suggestions, yes, the installer is installing in EFI mode! The directory you referenced, /sys/firmware/efi does indeed exist.

Furthermore, when I had Secure Boot turned on, the first of the error messages happened earlier in the installation process than the grub-install dummy fatal error. Therefore, with Secure Boot on, the /boot/efi directory was never even populated. Now that directory contains /boot/efi/EFI/kubuntu/grubx64.efi.

Regardless, now that I've realized that I'm an idiot and have corrected my mistake, the installation still continues to fail with:

• "grub-install dummy fatal error"

My next test is to try installing in BIOS mode, using the BIOS boot partition you mentioned. (Thanks for that! I didn't know that GPT disks needed that!)

However, I would very much prefer to boot in EFI mode, if at all possible!

Googling that error message returns a number of hits, but none of them have helped!

EDIT: 5/14/2013

Rod, there's too much to write to do so in a comment...

I tried to install rEFInd from your website, but it failed, and I'm not sure why! First off, here are the steps that I took:

1. While running the Live CD, and after the installation failed, I mounted the following:

   • /dev/sda3 on /mnt
   • /dev/sda1 on /mnt/boot/efi

2. I copied refind-bin-0.6.11.zip onto the system and unzipped it.

3. After unzipping the archive, I cd'd to it and ran:

   sudo ./install.sh --root /mnt

but got the error:

There were problems running the efibootmgr program!
You may need to rename the refind_x64.efi binary to the default name (EFI/boot/bootx64.efi on x86-64 systems or EFI/boot/bootia32.efi on x86 systems) to have it run!

I used efibootmgr to list out the boot entries, and no change was made to the list. The rEFInd entry was absent.

I didn't quite know where to go from there, so I decided I would just do it manually, from the instructions on your website.

I generally prefer doing things that way anyway! Believe it or not, I've been a System Administrator for over 25 years! However, all of my experience has been with Sun systems running Solaris, and, before that, SunOS, as well as quite a bit of experience with Windows. I'm therefore familiar with the basics of Linux and, obviously, the GNU software, as most of it is similar to Solaris. Unfortunately, I have zero experience with UEFI! I'm using BIOS on the new Windows system I just build, because it wasn't worth the time to figure out how to use UEFI. Well, now it's time to learn!

Anyway, I went through the manual instructions exactly as on your site. (Add sudo before all of these commands.):

1. The internal drive is mounted under /mnt and /mnt/boot/efi, as above.

2. From "refind-bin-0.6.11", ran cp -r refind /mnt/boot/efi/EFI/

3. cd /mnt/boot/efi/EFI/refind

4. rm -r drivers_ia32 tools_ia32 refind_ia32.efi

5. cd drivers_x64 ; rm ext2_x64.efi hfs_x64.efi reiserfs_x64.efi ; cd .. (Didn't know if I should keep iso9660_x64.efi, so I kept it.)

6. mv refind.conf-sample refind.conf

7. And finally, I ran "efibootmg", using the long form options, simply to make it easier for me to read:

   efibootmgr --create --disk /dev/sda --part 1 --loader \\EFI\\refind\\refind_x64.efi --label rEFInd --verbose

which returned absolutely nothing. It just returns without any messages or any output whatsoever, which, considering that I specified the '--verbose' option, was a bit of a surprise!

EDIT: 5/15/2013

So, I was looking through the system logs, and noticed that every time efibootmgr is run, it logs an entry in /var/log/kern.log.

According to, well, you, (in another thread), the efivars module is now built into the kernel, and the /sys/firmware/efi directory is evidence of that.

So then, one would not expect this in their kernel log:

kubuntu kernel: [80182.133386] efivars: set_variable() failed: status=8000000000000009
kubuntu kernel: [80633.493177] efivars: set_variable() failed: status=8000000000000009
kubuntu kernel: [80696.988083] efivars: set_variable() failed: status=8000000000000009
kubuntu kernel: [80721.952797] efivars: set_variable() failed: status=8000000000000009
kubuntu kernel: [80725.893414] efivars: set_variable() failed: status=8000000000000009
kubuntu kernel: [80790.848496] efivars: set_variable() failed: status=8000000000000009
kubuntu kernel: [86511.078667] efivars: set_variable() failed: status=8000000000000009

I have no idea why these are happening, but, for now, it's all a moot point...

Since I'd already wiped Windows off of this sytstem, I figured I'd just use the DOS BIOS upgrade tools. I of all people should have known that there was something screwy with their instructions! I should have searched online about this first, because, for the first time in my life, I have bricked a machine!!!! :-(

This machine is only a month old, so Sony is actually sending someone out to take a look at it. The guy I spoke with seemed to think it wouldn't be a problem getting it fixed!

There are literally dozens of posts online from Vaio owners who have done the same thing when trying to flash their BIOS in DOS!!!

So, I won't be able to test anything more for a time! :-)

I'll be back!

EDIT: 5/26/2013

And he's back...

So, rather than continue to try the same thing over and over and expect a different answer, I decided to take an alternate root!

I decided that the easiest way to deal with this was to install the system in Legacy mode and then convert it to EFI mode.

I know that this isn't "easy", but it gives me the advantage that I start with an installed system, rather than running off of CD.

That said, this required some "pre-configuration" first...

To make this possible at all, I had to partition my disk with both an EFI system partition and a BIOS boot partition! Unfortunately, I discovered that, if you boot the Live CD in Legacy mode, you cannot create an EFI partition with the Ubiquity installer! Unlike when you boot in EFI mode, the selection of the EFI system partition is missing from the disk partition interface.

Note that I could have used Rod's excellent GPT fdisk utility to create the partition table I needed, but I wanted the EFI partition setup first.

1. I first booted the Live CD in EFI mode. I started the installer, so that I could partition my disk as follows:

   • 1 Type: fat32 Name: EFI System Flags: boot
   • 2 Type: Name: BIOS boot Flags: bios_grub
   • 3 Type: swap Name: Linux Swap
   • 4 Type: ext4 Name: Linux Filesystem

2. I actually let the installer run until it crashed (as always) at the EFI boot manager installation.

3. I then changed the BIOS to Legacy and did the full install, making sure not to touch the EFI partition.

4. And there I am...

While this may sound convoluted (because it is! :-D ), I now at least have a running Kubuntu installation, for the first time! :-)

I don't know where to go next! Rod, if you see, do you have instructions on how to turn a BIOS boot with a GPT disk into an EFI boot? I thought you did, but I can't find it.

As always, any advice, such as: "You idiot! What were you thinking?!? No, here is the right way to do it..." would be greatly appreciated!

(In the interest of keeping this cordial, respectful site the way it is, perhaps it would be best to leave out the first part!!!)

Thanks!

The errors with Kubuntu and Lubuntu sound like one of two things is happening:

• The installer may have booted in BIOS mode rather than EFI mode. Given your partitioning, the installer would then try to install a BIOS-mode GRUB 2; but on a GPT disk, GRUB 2 likes to have a BIOS Boot Partition on the disk, and your system lacks that, so the installation might plausibly fail (although I've not tested that it will fail under these conditions; I'm speculating).
• The installer may be running correctly in EFI mode, but the distribution maintainers may have introduced a bug in their installers' EFI support. In this case, you may have no choice but to run the installer in BIOS mode. You could then leave the installed system running this way or convert to an EFI-mode boot, as you prefer.

You can check your boot mode by dropping to a shell and looking for a directory called /sys/firmware/efi. If it's present, you've booted in EFI mode; if it's absent, you've probably booted in BIOS mode. Most EFI-based computers give you some control of boot mode through their built-in boot managers and/or firmware options; however, the details vary greatly from one computer to another, so I can't give you precise instructions for how to change this detail, if it needs changing.

Your Ubuntu problem sounds like it may have failed to install your desktop environment, or perhaps it's launching something generic instead. You could try logging out and, at the login prompt, click the circle to the right of your name. That should produce a list of available desktop environments and window managers. Select whatever you prefer (or even something you don't prefer, for testing).

EDIT: Given the new information, my suggestion is to try installing another EFI boot loader. Several are available; see my Web page on the topic for details. My personal preference is rEFInd -- but as I maintain it, I'm biased. Given your current setup, I recommend booting a Linux live CD/emergency disc, preferably in EFI mode, and installing from the binary .zip file of rEFInd. In theory, you should be able to do this with the --root option to install.sh; but this feature has not been well-tested. See the full install.sh instructions for details. If that fails, you should follow the manual installation instructions.

One big caveat: The description of the problem you're experiencing in Ubuntu makes me think you've got some sort of X driver issue, and that could crop up in Kubuntu and Lubuntu, too. If so, you may need to tackle that after getting the boot loader issue sorted out.

EDIT 2:

You can install rEFInd on a system with a working EFI-mode Windows and a working BIOS-mode Linux. There are actually several ways to do this. The two easiest are likely:

• Do it from Windows. The rEFInd Windows installation instructions give details. Note that you'll need to manually install an EFI driver for whatever filesystem you use on Linux's root (/) (or /boot if it's separate) partition. You'll also need to create a /boot/refind_linux.conf file. Given that a BIOS-mode Linux boot works, the easiest way to create this file is to boot in BIOS mode and run the mkrlconf.sh script that comes with rEFInd.
• Boot Linux in BIOS mode, mount your ESP at /boot/efi, and run rEFInd's install.sh script. This should install rEFInd and create the /boot/refind_linux.conf file; but the installation will be done in a rather hackish way. Namely, the installer renames the Windows boot loader and installs rEFInd in its place. This works, but it's a violation of EFI's recommendations on boot loader naming. Also, some users report that Windows replaces foreign boot loaders named as the Windows boot loader in some situations, so this might not work in the long term, or the changes might need to be re-done.

Success! I now have Kubuntu installed in UEFI mode, and it's working perfectly.

I'm writing this up so that anyone else with this problem can hopefully follow these instructions and get UEFI boot working on the Sony Vaio. Note that this installation is for Kubuntu, but there's no reason why it wouldn't work with any flavor of Ubuntu.

Many thanks to Rod Smith (http://www.rodsbooks.com) for helping me to get to this point and to the others who contributed to this post!

These instructions are the same as what I wrote in my 5/26/2013 edit.

Some things to note:

• These instructions assume that you're using the entire disk for the Kubuntu installation. You'll obviously have to adjust the partitioning scheme if that's not the case.
• The third post says to "purge grub before install" when running boot-repair. I don't think I did that, so I don't yet know the result of that step.
• I have Secure Boot turned off. I simply don't need it, and I didn't want to complicate matters. You'll have to adjust these instructions if you intend to use Secure Boot. YMMV.
• As with all things EFI, if you need more information, refer to Rod's truly excellent site, http://www.rodsbooks.com!

• All instructions assume that you are running as root. If not, then preface each command with "sudo".

  1. (See EDIT: 6/8/2013 below.) Install in UEFI mode and run until it fails.
  2. Set the BIOS to boot in Legacy mode, and boot the Live CD. Select "Try Kubuntu."
  3. Download Rod's GPT Fdisk program from: http://download.opensuse.org/repositories/home:/srs5694/Debian_6.0/amd64/gptfdisk_0.8.6-1_amd64.deb.
  4. Install GPT Fdisk: "dpkg -i gptfdisk_0.8.6-1_amd64.deb".
  5. Using 'gdisk', partition the disk as follows:
     • Partition 1: Type: efi, TypeCode: EF00, Name: EFI System
     • Partition 2: Type: bios, TypeCode: EF02, Name: BIOS boot partition
     • Partition 3: Type: swap, TypeCode: 8200, Name: Linux Swap
     • Partition 4: Type: ext4, TypeCode: 8300, Name: Linux Filesystem
  6. Install the system in Legacy mode, mounting the 4th partition on /.
  7. When the installation is done, reboot the system and enter BIOS. Set it back to UEFI boot, and reboot the Live CD.
  8. Download and install Boot-Repair as noted in the third post.
  9. Run boot-repair, pointing to the EFI partition as the installation/boot partition.

Once boot-repair finishes, your system will boot in UEFI mode with no problems, at least none that I've seen so far!

Finally, don't forget to edit your GRUB configuration to accurately display your boot options.

I hope this helps! Let me know if you have any questions, and I'll try to help as best I can.

EDIT: 6/8/2013

I decided to reinstall my laptop from scratch, following my own instructions, and I ran into a problem! Boot-repair failed every time, and I finally figured out why.

It turns out I left out one step that I'd done the first time through, and it seems it was critical!

So, as I said, you should be able to install Ubuntu in Legacy mode, switch to UEFI mode, boot the Live CD, and run boot-repair. Every time I tried this, boot-repair came back telling me that I didn't have an EFI partition on my disk! Except, at that same time, I was staring at my partition table, which clearly showed /dev/sda1 as an EFI partition, with type code 0xEF00 and the boot flag set. So, what was the problem?

Simple... The EFI partition was empty. I had skipped was my first attempt to install in UEFI mode!

I had tried many times to install in UEFI mode, but each attempt failed. However, those failed attempts had populated the /boot/efi directory, located on /dev/sda1, the EFI partition.

Without those files on that partition, boot-repair didn't recognize it as an EFI partition! And so, it would tell me I had no EFI partition and fail!

So, I tried adding my original UEFI attempt back in to my instructions and, voilà, boot-repair succeeded, and the system booted in UEFI mode!

Now, @Marco Guimarães mentioned in his response that he was able to succeed without attempting (and failing) to install in UEFI first. I'm not sure how! @Marco Guimarães and/or @Radu Rădeanu, could you comment on this? Do you know for sure that your EFI partition was empty when you ran boot-repair, and that it worked regardless? Were there any other steps you took that might explain this?