Ubuntu – 13.10 doesn’t boot on Vaio Pro 13

I have Xubuntu 13.10 running on my Vaio Pro. I ran boot-repair from the LiveCD and managed to get the grub menu, though Xubuntu wouldn't boot. After some research, I discovered this page:

http://www.nicksplace.com.au/2013/07/04/fedora-19-on-vaio-pro-13-ssd-issues/

Its no secret that the Vaio Pro comes with a very nice SSD. The 128GB version is a MZHPU128HCGM made by Samsung. From my benchmarking it is very fast with ~1100MB/s read and ~500MB/s write. But when booting into Fedora 19, it may fail to boot, or the system may lock up for short periods (especially under heavy IO). During boot it may show a stream of the following messages (if it happens while you are logged in they will be in dmesg):

01:45:25,494 ERR kernel:[  155.668632] ata1.00: exception Emask 0x0 SAct 0x3 SErr 0x0 action 0x6 frozen
01:45:25,494 ERR kernel:[  155.668640] ata1.00: failed command: READ FPDMA QUEUED
01:45:25,494 ERR kernel:[  155.668650] ata1.00: cmd 60/08:00:00:08:00/00:00:00:00:00/40 tag 0 ncq 4096 in
01:45:25,494 ERR kernel:[  155.668650]          res 40/00:01:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
01:45:25,494 ERR kernel:[  155.668655] ata1.00: status: { DRDY }
01:45:25,494 ERR kernel:[  155.668659] ata1.00: failed command: READ FPDMA QUEUED
01:45:25,494 ERR kernel:[  155.668667] ata1.00: cmd 60/08:08:80:b8:e7/00:00:0e:00:00/40 tag 1 ncq 4096 in
01:45:25,494 ERR kernel:[  155.668667]          res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
01:45:25,494 ERR kernel:[  155.668672] ata1.00: status: { DRDY }

From my previous experience with the errors on other systems I decided to try disabling Native Command Queuing (NCQ). This immediately fixed the issue.

To make the fix permanent you need to add libata.force=noncq to your GRUB2 default kernel boot parameters. As root, edit /etc/defaults/grub and add libata.force=noncq to the end of the GRUB_CMDLINE_LINUX line. The finished file should look similar to the below:

GRUB_TIMEOUT=2
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="rd.md=0 rd.lvm=0 rd.dm=0 vconsole.keymap=us $([ -x /usr/sbin/rhcrashkernel-param ] && /usr/sbin/rhcrashkernel-param || :) rd.luks=0 vconsole.font=latarcyrheb-sun16 rhgb quiet libata.force=noncq"
GRUB_DISABLE_RECOVERY="true"

Then simply update your GRUB2 menu and reboot:

grub2-mkconfig -o /boot/efi/EFI/Boot/grub.cfg

I am very interested to know if anyone has experienced this issue on their Vaio Pro or whether there is an issue with my SSD.

So, I edited the grub list after booting from the LiveCD using:

sudo nano /etc/default/grub

I then changed this line:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash"

To look like this:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash libata.force=noncq"

And then I ran:

sudo update-grub

Your Boot Repair output looks OK to me -- as far as I can tell, you should be booting to GRUB when the computer starts up. It could be you've got buggy firmware, though, so you might check Sony's Web site for an update. (Of course, if you need to boot Windows to update the firmware, that could get ugly.) If you can update the firmware but the problem persists, re-running Boot Repair might fix the problem.

Another thing you can try is preparing a CD-R or USB flash drive with my rEFInd boot manager. (There are download links for both media types on that site.) If rEFInd boots, it should provide a menu with various options. The Windows option should work, as should an Ubuntu option that boots via GRUB. There should also be at least one option to boot a vmlinuz* file. This one won't work unless you hit F2 or Insert twice to edit the kernel options. Adding ro root=/dev/mapper/ubuntu--vg-root should work. If you can get into Linux via rEFInd, you can try installing the rEFInd Debian package. Ordinarily, this would set up rEFInd as your default boot manager, thus solving your problem. (This will also obviate the need to add kernel options manually.) Unfortunately, given the nature of your problem, I'm not sure this will work for you, but it's worth a try.

If installing rEFInd to your hard disk doesn't work, you could keep fiddling with EFI firmware settings in an effort to find a workaround. Check the Installing rEFInd Manually and Alternative Naming Options sections of the rEFInd documentation for some ideas. Alternatively, if a USB flash drive does the job as a workaround, you could buy a small USB flash drive to hold rEFInd and leave it permanently installed in one of your computer's USB ports. (Some drives are very small -- nearly flush when fully inserted.)

One more comment: Your Boot Repair output indicates inconsistent naming of the volume group that holds your root (/) filesystem. Sometimes it's /dev/mapper/ubuntu--vg-root, but other times it's /dev/mapper/ubuntu-vg-root. It looks to me like the former is correct and the latter is a result of a bug in the Boot Repair script itself, but it's worth keeping this inconsistency in mind. I vaguely recall hearing of a case in the past when somebody used a dash (-) in a volume group name and it caused problems, but I don't recall the details. It's unlikely that this is the source of your current problem, since it sounds like nothing that could read the volume group is even launching, but if you get rEFInd or GRUB to launch but then run into problems getting the system to fully boot, you might just try deleting the whole physical volume and re-installing again, this time using a volume group name that lacks a dash.