System does not boot

This change was made by a bot.

Can you follow the "Boot options" instructions on the following wiki to enable additional output on boot:

https://wiki.ubuntu.com/DebuggingKernelBoot

As mentioned on the wiki, it would be great if you can attach a log file which may have captured any messages you see. If you are unable to capture a log file, a digital photo will work just as well. As a last resort you can even copy messages down by hand.

I have read this page before reporting the bug. As I've written, no
kernel message is displayed.
With the default kernel command line, no message is displayed at all,
the machine freezes with a blank purple screen.

With the "quiet splash $vt_handoff" part removed, the last signs of
life I get before the computer freezes are EFI GRUB messages:

  Booting a command list

Loading Linux 3.13.0-21-generic ...
Loading initial ramdisk ...

(see attached picture)

Same thing with the 3.13.0-20-generic version.
I do not have the machine handy right now, I will test later today
with set gfxpayload=text.

On Wed, Apr 2, 2014 at 10:37 PM, Joseph Salisbury
<email address hidden> wrote:
> Can you follow the "Boot options" instructions on the following wiki to
> enable additional output on boot:
>
> https://wiki.ubuntu.com/DebuggingKernelBoot
>
> As mentioned on the wiki, it would be great if you can attach a log file
> which may have captured any messages you see. If you are unable to
> capture a log file, a digital photo will work just as well. As a last
> resort you can even copy messages down by hand.
>
> ** Changed in: linux (Ubuntu)
> Importance: Undecided => High
>
> ** Tags added: performing-bisect
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1301590
>
> Title:
> System does not boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301590/+subscriptions

Achille: Could you also try adding "nr_cpus=1" to the boot options and see if this allows you to boot?

Just tried with nr_cpus=1, still freezes with no message.
On Apr 3, 2014 5:52 PM, "Seth Forshee" <email address hidden>
wrote:

> Achille: Could you also try adding "nr_cpus=1" to the boot options and
> see if this allows you to boot?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1301590
>
> Title:
> System does not boot
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301590/+subscriptions
>

Ok, I've cloned the ubuntu-trusty repo, used git bisect and found the culprit:

dc9c3ed611922e769b1fd595f8f99a93d69c026d is the first bad commit
commit dc9c3ed611922e769b1fd595f8f99a93d69c026d
Author: Borislav Petkov <email address hidden>
Date: Thu Oct 31 17:25:08 2013 +0100

    x86/efi: Runtime services virtual mapping

    BugLink: http://bugs.launchpad.net/bugs/1297658

    We map the EFI regions needed for runtime services non-contiguously,
    with preserved alignment on virtual addresses starting from -4G down
    for a total max space of 64G. This way, we provide for stable runtime
    services addresses across kernels so that a kexec'd kernel can still use
    them.

    Thus, they're mapped in a separate pagetable so that we don't pollute
    the kernel namespace.

    Add an efi= kernel command line parameter for passing miscellaneous
    options and chicken bits from the command line.

    While at it, add a chicken bit called "efi=old_map" which can be used as
    a fallback to the old runtime services mapping method in case there's
    some b0rkage with a particular EFI implementation (haha, it is hard to
    hold up the sarcasm here...).

    Also, add the UEFI RT VA space to Documentation/x86/x86_64/mm.txt.

    Signed-off-by: Borislav Petkov <email address hidden>
    Signed-off-by: Matt Fleming <email address hidden>
    (cherry picked from commit d2f7cbe7b26a74dbbbf8f325b2a6fd01bc34032c)
    Signed-off-by: Tim Gardner <email address hidden>

:040000 040000 52f7a3e427111f66f65fcb67b1d010cee7e5121f 1200735ebee4c3272d1e3eedfc00c7150d17e276 M Documentation
:040000 040000 21376a74b6a2dc5dbe5b581677830b90bec72e49 95678fbb2d7178afb7866daf706dd7706d8da7e6 M arch
:040000 040000 bf1515bb7d32745424abf75d8ce58340f482e88c 59013df8e2ea1c112d96b982105b469917864c8f M include

I think there is a bug, even in the latest (3.13.0-23.45) revision.
It probably affects any 32-bit EFI system.

One easy way to fix it is to insert the following line in efi_32.c:efi_map_region():

        set_bit(EFI_OLD_MEMMAP, &x86_efi_facility);

This helps ensure that the function efi.c:runtime_code_page_mkexec() is called by efi_enter_virtual_mode().
I have rebuilt the kernel with this change and my machine runs fine now.

A temporary workaround is to use the efi=old_map kernel parameter.

It looks like you're running 32-bit, so this may help.

commit c55d016f7a930dd1c995336017123b469a8c8f5a
Author: Borislav Petkov <email address hidden>
Date: Fri Feb 14 08:24:24 2014 +0100

    x86/efi: Fix 32-bit fallout

I put up a test build with this patch at http://people.canonical.com/~sforshee/lp1301590/linux-3.13.0-23.45/. Please test and let me know if it fixes the issue. Thanks!

Yes, I noticed that one yesterday evening in the mainline repository. I've
just installed your image and it works fine too. Thanks.

This bug was fixed in the package linux - 3.13.0-24.46

---------------
linux (3.13.0-24.46) trusty; urgency=low

  [ Andy Whitcroft ]

  * [Config] d-i -- add nvme devices to block-modules udeb
    - LP: #1303710

  [ Paolo Pisati ]

  * [Config] build vexpress a9 dtb
    - LP: #1303657
  * [Config] disable HVC_DCC
    - LP: #1303657

  [ Tim Gardner ]

  * Release Tracking Bug
    - LP: #1305158
  * rebase to v3.13.9
  * CONFIG_RTLBTCOEXIST=m
    - LP: #1296591

  [ Upstream Kernel Changes ]

  * HID: Bluetooth: hidp: make sure input buffers are big enough
    - LP: #1252874
  * ACPI / video: Add systems that should favour native backlight interface
    - LP: #1303419
  * rds: prevent dereference of a NULL device in rds_iw_laddr_check
    - LP: #1302222
    - CVE-2014-2678
  * x86/efi: Fix 32-bit fallout
    - LP: #1301590
  * drm/nouveau/devinit: tidy up the subdev class definition
    - LP: #1158689
  * drm/nouveau/device: provide a way for devinit to mark engines as
    disabled
    - LP: #1158689
  * drm/nv50-/devinit: prevent use of engines marked as disabled by
    hw/vbios
    - LP: #1158689
  * rtlwifi: btcoexist: Add new mini driver
    - LP: #1296591
  * rtlwifi: Prepare existing drivers for new driver
    - LP: #1296591
  * rtlwifi: add MSI interrupts mode support
    - LP: #1296591
  * rtlwifi: rtl8188ee: enable MSI interrupts mode
    - LP: #1296591

  [ Upstream Kernel Changes ]

  * rebase to v3.13.9
 -- Tim Gardner <email address hidden> Fri, 04 Apr 2014 09:26:27 -0400