FS#33745 - [linux] 3.7.x - 3.12.x Unable to boot using EFI
Attached to Project:
Arch Linux
Opened by Shawn Tan (shawntan) - Thursday, 07 February 2013, 05:22 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 13 August 2014, 07:17 GMT
Opened by Shawn Tan (shawntan) - Thursday, 07 February 2013, 05:22 GMT
Last edited by Tobias Powalowski (tpowa) - Wednesday, 13 August 2014, 07:17 GMT
|
|
Details
Description:
Unable to boot using linux-3.7.6 kernel using EFI boot with rEFInd. After selection of kernel at the refind menu, the kernel begins to load, but stops after displaying the parameters the kernel is being loaded with. Boots normally after switching back to linux-3.7.5 kernel and initramfs image. Additional info: * package version(s) Name : linux Version : 3.7.6-1 Name : refind-efi Version : 0.6.7-1 * config and/or log files etc. Steps to reproduce: Use refind bootloader with linux 3.7.6 and initramfs. |
This task depends upon
Closed by Tobias Powalowski (tpowa)
Wednesday, 13 August 2014, 07:17 GMT
Reason for closing: Fixed
Additional comments about closing: 3.16
Wednesday, 13 August 2014, 07:17 GMT
Reason for closing: Fixed
Additional comments about closing: 3.16
FS#33721?Does the following combination work?
linux 3.7.6-1
refind-efi 0.6.6-1
efibootmgr -c -g -d /dev/sdX -p Y -w -L "rEFInd" -l '\EFI\refind\refind_<arch>.efi'
This didn't work either.
I tried installing the linux-3.7.6 package, but booting with the 3.7.5 kernel and image.
This booted, but the boot process stopped when attempting to mount /boot/efi, which was a vfat partition.
I suspect some kind of module problem?
I guess you could try rebuilding linux 3.7.6 with the following config change reverted:
https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=5cd6ba89c8dd1672bc68b5336aaff8e7b6d6d61e
Tobias Powalowski (kernel and refind-efi maintainer) might be able to provide further troubleshooting advice when he gets back. (He's currently away for a few days.)
I am using the Lenovo X1 Carbon by the way, I'm not sure if that helps.
if I AM mistaken about graphic card please ignore and excuse the noise.
EDIT-- just as a point of fact... the bug didn't hit me until 3.7.4 (ish) (i believe)
(Although, most likely, that's not causing this problem.)
http://archlinux.2023198.n4.nabble.com/rEFInd-0-6-4-linux-3-7-2-1-fail-to-boot-td4683026.html
Never seen a valid fix being discussed, only that the issue magically disappears after upgrading to some newer kernel version. :\
Crossing my fingers and hoping the stable release will boot for me. Heh.
I tried manually booting the kernel from the EFI shell and encountered the same freeze so to me it looks more like an efistub problem than a rEFInd specific one.
I belive that the boot parameters are printed by rEFInd and not the kernel as was suggested in the description, so perhaps the kernel does not even begin to boot.
https://bbs.archlinux.org/viewtopic.php?pid=1246697#p1246697
i have to use grub2 instead
I use the auto-detect feature of refind, so no need to copy the images. I use 3.8.4-1 in [testing] thought, haven't try 3.8.4-1 in [core].
I use the ext4 driver with the kernel and image on /boot so no need to copy them over to the ESP. (I don't use auto-detect but it is the same idea.)
I could ask, are you sure that you were copying the new images over before since all 3.7.* booted just fine for me...
If I insert the arch cd/usb and choose a uefi shell v1, I can boot. Trying uefi shell v2 results in freeze, though
Did you vote? This bug has only 2 votes despite the number of comments. I don't know if votes mean much but if they do, it is a shame people are not using them!
It is the severity rating that really puzzles me. How can something which prevents booting be "low" severity? I understand it might not be highest (there are other ways to boot) but "low" seems odd.
probably because there are also
https://bugs.archlinux.org/index.php?do=details&action=details.addvote&task_id=34358 (close, but not the same)
https://bugs.archlinux.org/task/34401 (gummiboot related, but seems like the same problem)
and those are marked as critical, so they probably draw all the attention from people experiencing the problems
This is with refind 0.6.8-1, though it's probably not related to refind
Did anything change with the EFI stub? I use auto-recognition by refind.
The developer of rEFInd suspects a bug in the way some Arch developers compile the kernel which manifested given various outside conditions or, possibly, a bug in the compiler being used to compile the kernel.
The trouble with this bug is that it almost certainly isn't a rEFInd bug even though there is a rEFInd work around for some situations.
Neither does updating my BIOS to the latest available...
Still fails for 3.8.8-2...
Thinkpad x220, gummiboot or direct EFISTUB.
"Failed to alloc lowmem for boot params"
Is there an upstream bug report? This does not seem to be an arch only problem: http://forums.gentoo.org/viewtopic-p-7287332.html and according to this: http://www.rodsbooks.com/efi-bootloaders/efistub.html (7th bullet point) the efi-stub main developer has been informed. But i think we might need a place to gather some infos. (gcc version, system, bootloader, etc)
To clarify, try building the kernel with these packages installed (preferably in a chroot, so you don't mess up your install):
http://arm.konnichi.com/core/os/x86_64/cloog-0.17.0-2-x86_64.pkg.tar.xz
http://arm.konnichi.com/core/os/x86_64/gcc-4.7.1-1-x86_64.pkg.tar.xz
http://arm.konnichi.com/core/os/x86_64/gcc-libs-4.7.1-1-x86_64.pkg.tar.xz
http://arm.konnichi.com/core/os/x86_64/libmpc-0.9-2-x86_64.pkg.tar.xz
http://arm.konnichi.com/core/os/x86_64/libtool-2.4.2-6-x86_64.pkg.tar.xz
http://arm.konnichi.com/core/os/x86_64/ppl-0.12.1-1-x86_64.pkg.tar.xz
https://bugs.archlinux.org/task/35909
- This is my forum post about GRUB: https://bbs.archlinux.org/viewtopic.php?id=164101
- When I try to boot from the new install medium (13/06), which uses gummiboot, I get the error "Can't load initrd".
- Has anyone tried to downgrade GRUB? (instead of recompiling it?)
Any testing or things I can try? Currently I'm running 3.9.7 kernel
Running a Lenovo X230, with 3rd gen Intel i5 and UEFI is enabled and set as only boot (No Legacy).
It's likely that this is buggy firmware, which the EFI stub will have to be patched to work around.
3.10.1 is good again
Previous versions of kernel worked OK for me.
But after recent update(linux 3.10.2-1) my laptop(Lenovo G780) started to experience the same symptom.
REFInd begins to load the kernel, prints the parameters the kernel is being loaded with and then stops.
I've tried different versions of rEFInd (6.8 - 7.1) - problem is the same.
The most _interesting_ part is:
The problem disappears if an Archlinux bootable USB flash drive is connected (and rEFInd sees four new options from it).
System boots fine when there are other options for boot!
Now I boot the laptop with the USB drive in.
And looking forward for the new kernel release :)
1 What's going on?
2 Is this the same problem? Should I add a new task?
FS#36519. Briefly: 3.10.6-2 is broken one some machines where 3.10.3-1 works.Symptoms -
After reboot and using the same boot line from either gummiboot or any other bootloader the screen will just be blank with no errors or anything, it doesn't look like the vmlinuz-linux (or whatever you named it) is working.
Anyone with a problem with the latest arch should just downgrade to the latest version that they have had working.
My error doesn't give any kind of error, it just boots through gummiboot to a blank screen with nothing else. You can try adding another boot option and a wait of a couple seconds to the gummmiboot to see if you are actually getting past the boot process and loading linux.
linux-3.10.3-1-x86_64.pkg.tar.xz (good)
linux-3.10.7-1-x86_64.pkg.tar.xz (bad)
linux-3.10.9-1-x86_64.pkg.tar.xz (good)
@all suffering from this bug: I have mounted ESP on /boot and installed syslinux as a backup boot loader, which never failed me. This way i can easily switch from gummiboot to syslinux by toggeling the boot mode (legacy/uefi) in the "bios"
This is with a Lenovo X230
linux-3.11-1-x86_64.pkg.tar.xz (bad)
Ulf, hasn't pretty much the same patch been applied with http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/x86/boot/compressed/eboot.c?id=f8b8404337de4e2466e2e1139ea68b1f8295974f introduced with the 3.10 release? Why did you have to patch again?
Because of the above patch and no boot problems, I'm beginning to think that the bug is resolved for my hardware. Will wait a couple of releases and report if this changes.
It hit me again (Lenovo X220) with the recent 3.11.0 kernel I built. I did not use the PCI patch.
* refind-efi 0.7.3-2 (not latest version, but due to the most recent efibootmgr crashing on me I ran refined-install from the latest live-usb)
* efibootmgr 0.6.0-3
* linux 3.11.1-1
* linux-lkts 3.10.12-1
[Note: I have the issue unusually consistently. It doesn't come and go or affect some kernels and not others.]
My solution and workaround (as mentioned above) is to insert a flash drive before boot process.
Could anybody confirm this, please?
Acer Aspire V5-121, AMD APU C-70
3.12.6-1-ARCH works fine.
Can confirm. 3.12-7-1 won't boot using EFISTUB on Lenovo X220.
I'm using gummiboot and I can verify that gummiboot works without a problem as I am also using it to boot to Windows loader. Once I enter linux it will not start loading arch linux. Is there anything I can test to figure out what is causing this?
It boots with BIOS, but the disk is GPT. It's using syslinux.
According to the case, It's a DELL optiplex 740.
Could you guys verify, that apllying a patch like this: https://bugs.archlinux.org/task/33745#comment114120 works?!
I have been using reFIND bootmanager with ESP mounted at /boot/efi and with the kernels installed in /boot (on ext4 partition) and using the "ext4_x64.efi" driver of reFIND.
This configuration has worked for me for all 3.10, 3.11 and 3.12 kernels until I upgraded to kernel 3.12.7-1. It still works with kernel 3.12.6-1.
I can boot the 3.12.7-1 kernel using GRUB2. That is what I am doing temporarily. But I still hope that I can return to the reFIND - EFISTUB method.
I am using gummiboot with ESP mounted at /boot. This is on a Lenovo Thinkpad X1 Carbon.
I am using gummiboot with ESP mounted at /boot. Lenovo Thinkpad X1 Carbon as well.
What next? Broken kernels and/or gummyboot just won't boot, good ones boot just fine. How to debug what's the problem?
After reading https://bugs.archlinux.org/task/33745#comment108126, I decided to manually download and run the PKGBUILD files to build the linux 3.12.7 kernel instead of installing a pre-compiled kernel from the Arch core repository.
Results: After manually building and installing the linux 3.12.7 kernel using the PKGBUILD instead of the pre-compiled version from core, my machine successfully boots!
Hypothesis: The Arch developers are occasionally doing something strange when they create the pre-compiled linux kernel, as suggested in the following comment from this same thread: https://bugs.archlinux.org/task/33745#comment108126.
* Choose an up to date mirror
* Install devtools
* Mount a btrfs file system on /var/lib/archbuild (another file system will also work, but creating the chroots will be less efficient due to lack of snapshots - as a test case, we could also try with and without btrfs)
* Add the following lines to the sudoers file using visudo:
brian ALL=NOPASSWD: /usr/bin/extra-i686-build
brian ALL=NOPASSWD: /usr/bin/extra-x86_64-build
brian ALL=NOPASSWD: /usr/bin/multilib-build
brian ALL=NOPASSWD: /usr/bin/multilib-staging-build
brian ALL=NOPASSWD: /usr/bin/multilib-testing-build
brian ALL=NOPASSWD: /usr/bin/staging-i686-build
brian ALL=NOPASSWD: /usr/bin/staging-x86_64-build
brian ALL=NOPASSWD: /usr/bin/testing-i686-build
brian ALL=NOPASSWD: /usr/bin/testing-x86_64-build
* Get the PKGBUILD directly from svn: svn co svn://svn.archlinux.org/packages/linux/trunk linux
* Build the package using 'sudo extra-x86_64-build -c' or 'sudo extra-i686-build -c'
tpowa, could you also do the same on your build machine and upload all test kernels for Brian to test? In particular, build packages with and without btrfs and recreate all chroots using '-c'.
This is a very weird problem: Both the working and non-working kernels have been built on your build machine.
This is just an hypothesis, though; I haven't tried to reproduce this problem or track it down further. (I don't have a computer that's ever shown this symptom.)
compiled kernel with -j1 in a new setup chroot.
Please try this.
I've got my chroot environment setup on a btrfs and ext4 filesystem, along with the sudoers file configured as explained by Thomas. Just to rule out possible causes, I'll test -j1, -j2, and -j8 MAKEFLAGS under each filesystem. I'll post my results as soon as I find some time to compile the kernel under the two filesystems.
I think this is a bug in the kernel itself. Maybe the patch brian suggested (https://bugs.archlinux.org/task/33745#comment114120) works. I'm gonna try and report back.
Works fine with GRUB2 but using Gummiboot it just shows a black screen. Worked fine with earlier kernels.
Hardware
Lenovo Thinkpad T420i 4178-BAG
The 3.12.7-2 kernel from the core repository still does not boot on my machine with UEFI.
The 3.12.7-2 kernel compiled using the PKGBUILD on my local machine (not in a chroot environment) works, i.e. my machine successfully boots. Note that I tried this using -j2, -j4, and -j8 MAKEFLAGS, all of which resulted in successful boots. Also note that my filesystem is ext4.
Here are the interesting results. I set up two different chroot environments as instructed by Thomas. The first chroot was on a btrfs filesystem. The second chroot was on an ext4 filesystem.
The 3.12.7-2 kernel on the clean chroot btrfs filesystem was compiled with MAKEFLAGS="-j4" and using the 'sudo extra-x86_64-build -c' command as instructed by Thomas. I installed the generated tar.xz package using 'sudo pacman -U linux-3.12.7-2-x86_64.pkg.tar.xz' and the installation finished without any errors. I restarted my machine and it failed to boot.
The 3.12.7-2 kernel on the clean chroot ext4 filesystem was compiled with MAKEFLAGS="-j4" and using the 'sudo extra-x86_64-build -c' command as instructed by Thomas. I installed the generated tar.xz package using 'sudo pacman -U linux-3.12.7-2-x86_64.pkg.tar.xz' and the installation finished without any errors. I restarted my machine and... Yes!!! My machine successfully booted!
New hypothesis: compiling the linux kernel on a btrfs filesystem may randomly result in some UEFI machines not booting, particularly ones in which the kernel is being installed to an ext4 or other non-btrfs filesystem when it was compiled on btrfs.
Second hypothesis: compiling the linux kernel on an ext4 filesystem results in successful boots, at least on machines in which the ext4 compiled kernel is installed onto an ext4 or more generally, a non-btrfs filesystem.
Why is this happening? It may be a bug in how the kernel operates on btrfs systems.
What does everyone else think?
Thinkpad X220 (4290-W1B), Bios: 1.39, FW: 1.24
UEFI Boot with gummiboot, /boot is vfat (EFI Partition), Kernel installed to /boot, LUKS in use
Last working kernel: 3.12.6-1 (have downgraded since)
Bad kernels so far: 3.12.7-1 and -2
Didn't try Tobias' kernel yet.
Here is the one I compiled on the ext4 filesystem: https://dl.dropboxusercontent.com/u/35472586/ext4-linux-3.12.7-2-x86_64.pkg.tar.xz.
@Brian: Yesterday, I built 3.12.7-1 (-j4, ext4, extra-x86_64-build), but it didn't work either. Maybe the patches added in -2 did something, or it's the fact that I changed the pkgname to linux-selfbuild (For the sake of not having to replace my current), because otherwise, I don't know how it worked with you.
I'm going to try compiling it without changing anything to the PKGBUILD, and getting it directly from SVN (instead of ABS). Let's see if it works.
EDIT: NVM, you can use the linux-headers from core with @Brian's kernel.
Currently running @Brian's ext4 build. It works!
Will try to compile my own kernel next.
Edit: Compiling it myself didn't help. Still can't boot 3.12.7... I'll keep 3.12.6 for now.
Let's not completely dismiss the ext4/btrfs hypothesis just yet. Perhaps the makefile for the kernel does some configuration behind the scenes that we have not considered, for example the makefile is setting some flags in the kernel during compilation depending on the type of filesystem it is being built on. If the filesystem type is not the issue, then maybe it is some other flag(s) in the kernel's makefile.
======
kernel good/bad
======
GOOD arch3-12-6/boot/vmlinuz-linux (arch stock 3.12.6-1)
BAD arch3-12-7-2/boot/vmlinuz-linux (arch stock 3.12.7-2)
BAD btrfs/boot/vmlinuz-linux (brian's btrfs 3.12.7-2)
GOOD ext4/boot/vmlinuz-linux (brian's ext4 3.12.7-2)
BAD tpowa/boot/vmlinuz-linux (tobias' 3.12.7-2)
In lack of any better idea or knowledge in the field of uefi binaries I gathered some file size stats. I played around with objdump too and there are differences, but i could not tell what they mean. Interestingly the not working 3.12.7-2 images all have the same sizes, but as i could see with objdump and md5sum different content. Anybody got any idea?
======
ls -l
======
3875280 20. Dez 19:40 arch3-12-6/boot/vmlinuz-linux
3867728 12. Jan 13:10 arch3-12-7-2/boot/vmlinuz-linux
3867728 14. Jan 20:13 btrfs/boot/vmlinuz-linux
3867664 14. Jan 21:05 ext4/boot/vmlinuz-linux
3867728 14. Jan 15:30 tpowa/boot/vmlinuz-linux
======
md5sum
======
c2784212a2d4fb6333ef42267887023b arch3-12-6/boot/vmlinuz-linux
8b42b8f424aac23dfcaffe25ed0723cf arch3-12-7-2/boot/vmlinuz-linux
bae23189d4a7a59bace614339a4239b6 btrfs/boot/vmlinuz-linux
69539063e24920c14bb48bdb4dd99631 ext4/boot/vmlinuz-linux
85502b4ea01e83274621d2837be1c9bd tpowa/boot/vmlinuz-linux
======
size -Ax
======
arch3-12-6/boot/vmlinuz-linux :
section size addr
.setup 0x41e0 0x200
.reloc 0x20 0x43e0
.text 0x3addd0 0x4400
Total 0x3b1fd0
------
arch3-12-7-2/boot/vmlinuz-linux :
section size addr
.setup 0x41e0 0x200
.reloc 0x20 0x43e0
.text 0x3ac050 0x4400
Total 0x3b0250
------
btrfs/boot/vmlinuz-linux :
section size addr
.setup 0x41e0 0x200
.reloc 0x20 0x43e0
.text 0x3ac050 0x4400
Total 0x3b0250
------
ext4/boot/vmlinuz-linux :
section size addr
.setup 0x41e0 0x200
.reloc 0x20 0x43e0
.text 0x3ac010 0x4400
Total 0x3b0210
------
tpowa/boot/vmlinuz-linux :
section size addr
.setup 0x41e0 0x200
.reloc 0x20 0x43e0
.text 0x3ac050 0x4400
Total 0x3b0250
I'm using gummiboot, my boot partition is 1GB fat32 (EFI Partition), root partition is ext4, partition table is gpt and I'm running the x86_64 version.
https://dl.dropboxusercontent.com/u/79189298/linux-3.12.7-2-x86_64.pkg.tar.xz
https://dl.dropboxusercontent.com/u/79189298/linux-docs-3.12.7-2-x86_64.pkg.tar.xz
https://dl.dropboxusercontent.com/u/79189298/linux-headers-3.12.7-2-x86_64.pkg.tar.xz
[Btw, one workaround seems to be:
Install elilo from aur, copy over elilox64.efi and elilo.conf to /boot(/EFI) and configure elilo.conf accordingly. Set up your normal EFI boot manager to chainload elilo which then loads the kernel. This could be set up as a permanent backup solution in case this bugs occurs again, so you're not a sitting duck with your unbootable machine]
Seeing how the kernel in the repositories works for some people and not others, and also my kernel works for some people and not others, perhaps this is specifically hardware related.
I'll post back after I've have a chance to try Max's kernel.
I'm out of ideas now. What could possibly be going on? UEFI is a must-have for me. I don't mind compiling my own kernel just to get it working; however, I would still prefer to use the one from the repositories (when it works) because it is quicker to install.
Could somebody please give any comment on my workaround to this problem?
3.10.2-1 and 3.12.5-1 were bad for me.
I used to insert a flash drive into USB before starting my laptop to boot the kernels, which failed to boot otherwise.
A mere presence of any (maybe not even bootable) flash drive let the miracle happen.
Could you please confirm/disprove/elaborate on this?
I disprove. I've tried it several times with different kernels. It makes no difference for me.
Both max's and brian's kernels work on my PC.
I also disprove. Having a flash drive in any of the USB ports on my machine made no difference.
I strongly believe it's related to something that was changed in the kernel itself in version 3.12.7 (at least there seem to be a _lot_ of people which were able to boot 3.12.6 but not 3.12.7). And the list of changes between 3.12.6 and 3.12.7 is not so long.
git bisect start
# bad: [4301b7a8fe14a787fbf0bb9cad16b623f45956f6] Linux 3.12.7
git bisect bad 4301b7a8fe14a787fbf0bb9cad16b623f45956f6
# good: [d0266db287d492abe63e19859ad99dd232bc0e89] Linux 3.12.6
git bisect good d0266db287d492abe63e19859ad99dd232bc0e89
# good: [f3c1f0d0aaf20f9dee35ae99ec8b8705af4dc60e] drm/radeon: fix render backend setup for SI and CIK
git bisect good f3c1f0d0aaf20f9dee35ae99ec8b8705af4dc60e
# good: [f3b578d9d009a9f670e893cec8579aa069aaaccb] mm: numa: avoid unnecessary work on the failure path
git bisect good f3b578d9d009a9f670e893cec8579aa069aaaccb
# bad: [e93b100931a45490cd07960a1ec51d9d8e5100cb] GFS2: Fix slab memory leak in gfs2_bufdata
git bisect bad e93b100931a45490cd07960a1ec51d9d8e5100cb
# bad: [eede0e9020693adaeed01fb464261a00ce9d05ad] mm/memory-failure.c: recheck PageHuge() after hugetlb page migrate successfully
git bisect bad eede0e9020693adaeed01fb464261a00ce9d05ad
# good: [ef36ec29945653ced2c30158213841d248299a8a] mm: fix TLB flush race between migration, and change_protection_range
git bisect good ef36ec29945653ced2c30158213841d248299a8a
# bad: [9c612a77032a98b264d12fd6e3df2ca530d968d2] mm: numa: defer TLB flush for THP migration as long as possible
git bisect bad 9c612a77032a98b264d12fd6e3df2ca530d968d2
# good: [186fa6eb6131954d17457f37283e654cb079c25b] mm: numa: guarantee that tlb_flush_pending updates are visible before page table updates
git bisect good 186fa6eb6131954d17457f37283e654cb079c25b
# first bad commit: [9c612a77032a98b264d12fd6e3df2ca530d968d2] mm: numa: defer TLB flush for THP migration as long as possible
I'll try to apply the inverse of 9c612a77032a98b264d12fd6e3df2ca530d968d2 on top of 3.12.7 next.
Also, it happens in the very early boot code (arch/x86/boot/compressed). The mm subsystem (and the rest of the kernel) isn't even loaded at this time.
It might have something to do with the alignment or the content of the compressed kernel. Using another compression type (such as XZ or LZO) might hide the problem again.
"Failed to alloc lowmem for boot params"
This can be found in arch/x86/boot/compressed/eboot.c
Yesterday, I built the 3.12.7-2 Arch kernel myself and it did not boot. Today, I built it again, and now it boots.
I now believe this bug is a combination of the hardware, kernel, and bootloader. Originally I was only using gummiboot which resulted in the kernel not booting. Then I decided to try refind. Same result. It did not boot. Then I tried GRUB, following the UEFI installation and configuration instructions from the Arch Linux Beginner's Guide. This resulted in a successful boot.
What's strange is that some people have said that all 3 bootloaders failed to work, others have said that all 3 bootloaders work, and the remaining people, myself included, could only get one of the bootloaders to work (specifically GRUB).
For those doing kernel re-builds, might I suggest that you clean your temporary files and re-build the kernel multiple times, without making any other changes? I suggest four or five re-builds. The most notable aspect of this bug is its amazing inconsistency. If multiple builds of the same kernel produce different boot results, then that's important information -- it could indicate some sort of problem during the build process that can come and go or something that's sensitive to build-specific information. (Two back-to-back builds of the same kernel will not produce 100% identical binaries because information like the kernel build time will be embedded in the kernels. Although I can't suggest how, such differences might be feeding into this bug.) If several builds from the same source file produce consistent results, on the other hand, then that suggests something more static (but still changeable from one version to another) is at the root of the problem.
The first build (bad) was made on the 2nd Arch system, the second one (good) on the 1st Arch system. The next days I did some rebuilds again on both systems. Both systems produced some good and some bad builds. So, there is no point in trying to find out if a difference between the 2 systems could be the cause of the different results.
I also have GRUB2 installed and I have configured reFIND to display the option of calling GRUB2. GRUB2 has always worked for me, even when the EFISTUB loader fails, but I still prefer the beauty and simplicity of reFIND over GRUB2.
@Rod Smith, when doing rebuilds, I have always started from a fresh copy of the /var/abs/core/linux directory. So, there cannot be any interference with temporary files left over form previous builds. I am convinced that several builds of the same source produce different results for the EFISTUB loader problem: it is either random, or depending on the date and time.
I can confirm this. I am on a Lenovo Thinkpad x220. First failed to boot when upgrading to 3.12.7-2, when I plugged in a bootable flash drive I successfully booted. I am now reverted to 3.12.6-1.
As others reported success with 3.10.10-1, I tried it and it does boot on my thinkpad x230.
As a test, can anyone make multiple copies of the same kernel on the ESP and try to boot each one of them? What about re-creating the file system on the ESP from scratch, does that change anything (be careful, you need to make sure that any other OS, like Windows, still boots afterwards, so only do this if you know what you are doing)? Or simply defragmenting the ESP?
(More factors I can think about: this may depend on file size, fragmentation, ...)
I also used efibootmgr to try making new entries for refind. As my fresh install still locked up, I restored from backups to find out that the linux kernel was also locking up. At first I suspected that the change of UUID could be the issue so I ran a chroot from the installation media and reinstalled the linux package with pacman which didn't fix the problem.
Then I found out my arch-ck kernel wasn't locking up, so I updated the associated refind_linux.conf and I managed to boot in arch-ck.
My ESP is a gdisk 512MB EF00 partition formatted in fat32 mounted on /boot/efi (followed instructions from the beginner's guide).
Let me know if I can provide more information or run some tests to help.
---
thinkpad x230 with 16GB RAM, crucial M4 SSD
1st boot attempts after upgrade resulted in just the kernel params showing. After 6 reboot attempts, the machine just booted. I shrugged it off. Next day (this morning), about 15 reboots didn't work. I plugged a USB thumb drive I use to transfer files via sneaker-net into a USB port and it booted. I don't know if it was coincidence or not. I downgraded the Kernel to 3.12.7-2 because I have a meeting today and need it.
Also, the same for us is I have the ESP mounted at /boot/efi (Arch lives in /boot/efi/EFI/arch/*). I also use rEFInd and it boots from /boot/efi/EFI/boot. What may be different (and may or may not be an issue) is when I followed the Beginners guide last year (got the new laptop at the end of January), I created an ESP -- but I already had one for Windows. So my machine has TWO ESP partitions -- FS0: and FS1:. I boot my machine from FS1. I must be honest in telling you that I am not a UEFI expert, so any questions you have might need specific details for me to answer.
My machine: Acer v3-771, i7 16GB RAM, Intel/nVidia Optima, 1TB HD, updated daily, [testing] repo NOT enabled.
If I get a chance tonight I will upgrade the Kernel again and make multiple copies of it.
--------
Wim Herremans(herremaw) has an Acer V3-571 and CAN boot the latest, but not the previous 2 Kernels. I have a V3-771 and it's the opposite for me right now. Not sure if that matters.
boots >> linux-3.10.10-1-x86_64
hangs << linux-3.12-1-x86_64
hangs << linux-3.12.1-2-x86_64
boots >> linux-3.12.1-3-x86_64
boots >> linux-3.12.2-1-x86_64
boots >> linux-3.12.3-1-x86_64
boots >> linux-3.12.4-1-x86_64
boots >> linux-3.12.5-1-x86_64
boots >> linux-3.12.6-1-x86_64
hangs << linux-3.12.7-1-x86_64
hangs << linux-3.12.7-2-x86_64
hangs << linux-3.12.8-1-x86_64
Looking at my backups the kernel installed was linux-3.12.7-2-x86_64 and I'm pretty sure it worked fine at the time, actually I've been using arch on this laptop for a year and didn't encounter this bug before.
I tried making several copies of the 3.12.8-1 kernel in /boot/efi/EFI/arch{1..6} and none of those worked.
*Note* Not sure it matters but I should mention that I upgraded my crucial M4 SSD firmware from 040H to 070H before attempting the fresh install.
Contrary to what most other people are doing, I keep the kernels in /boot on the root ext4 partition. The ESP I mount on /boot/efi. I have installed reFIND in /boot/efi/EFI/refind. I have also installed reFIND's ext4 driver in /boot/efi/EFI/refind/drivers such that both reFIND and the UEFI firmware can read the kernels from the ext4 root partition.
This setup has served me well for at least 6 months, till kernel version 3.12.7 came along.
I have a trick that I've been using since then to boot. With affected kernels, if i launch the efi shell, then use it to re-launch boot manager, and then use that to launch the kernel, it boots most of the time.
This worked both with refind and gummiboot.
It might help somebody stuck with a non-booting kernel. It's also a nice demonstration of efi stub's handoff code being at fault.
--------
Most recent testing information:
Last night I re-updated the Kernel to 3.12.8. I then told the machine to reboot (not POWEROFF, just REBOOT). It rebooted just fine. I did this 5 times -- reboot, sign into Enlightenment, reboot. Afterwards I shut the laptop down for the evening.
This morning at work I powered on -- it would NOT boot. It stopped after displaying the Kernel params. I CTL+ALT+DEL and tried to boot again and it failed again. I went into the EFI Shell and back out (just to do something different), and it failed to boot. I waited for 10-15 seconds on the rEFInd boot menu and then tried -- still failed.
I plugged in my USB thumb drive and the rebooted -- started up just fine! This thumb drive only has a few documents and image files on it I use to transfer between machines, it is NOT A BOOT DRIVE FOR ARCH OR ANY OS (not shouting, just emphasizing). Why does having a USB thumb drive in a USB port make the boot process work? I have a USB mouse receiver plugged in all the time, but that doesn't matter.
I will see if gummiboot does the same thing...
--------
UPDATE: Gummiboot acts the same way, no USB thumb drive, no boot. I removed the wireless mouse receiver and tried rebooting -- still no booting. I went into the BIOS (or whatever it's called now) and moved all USB devices further down below Arch in the boot order, and the machine would still not boot with 3.12.8 unless I had a USB drive plugged in.
I think this may make my issue different than the crux of this thread, right?
I check my BIOS version against what Acer said mine should be for the V3-771G. I had 2.16 and the latest update was 2.23. I cringed, but updated my BIOS to 2.23. I had to reset the boot options to boot rEFInd again, but after that the machine booted just fine -- no USB thumb drive required.
Obviously, everyone else's mileage will vary, but does this not give some indication that whatever is being done at the earliest levels of the Kernel booting is affected by something in the BIOS?
Also, I only tested rebooting a couple of times. This may cause other issues down the road, or in fact not have completely solved my problem, and I just "lucked up" for a couple of boots. I will also update the forum post I have been participating in with this same info. (https://bbs.archlinux.org/viewtopic.php?id=175662)
GUMMIBOOT doesn't work
EFI Shell v1 & V2 do not work
I know this probably isn't the right place to post this but can someone explain to me how to patch the kernel with the efi patch? http://pastebin.com/24kvw8kt I really would like to try it out and see if that will fix my issues.
Thanks
@all: looks like Matt Fleming found a solution to the problem. i.e. the reloc2.patch. I built a stock 3.12.7-2 arch kernel with this patch and uploaded it here [1]. Plz try the kernel package or build it yourself [2] and report back to the upstream bug report [3].
[1] https://mega.co.nz/#!0UsxBKLS!FkFIK_av-cNrxmdg2fNc9_GM3UvasGJb3IAgIpAnBjk
[2] https://mega.co.nz/#!AF9hTCaL!lIHgKSbdSo08y1uacAMQvE1Ho9LjrjL27BPGtVWSGl4
[3] https://bugzilla.kernel.org/show_bug.cgi?id=68761
As 3.12.9-1 is out, I gave it a try and it hangs too but with a an additional twist, this time I have graphical artifacts appearing on top of the screen, a few lines of different colored pixel suggesting some kind of memory corruption.
Update: So I followed some other suggestions and the 3.13 mainline pkg from Aur compiled and booted without a problem on my computer.
I'm running a lenovo x230 with the latest bios anymore suggestions?
1) drop to UEFI Shell x86_64 v1 first
2) then exit the Shell
3) then boot
everything works! This is very strange... I have a Toshiba Satellite L855-14Z.
Kernel versions 3.12.7-1 and 3.12.7-2 were the only ones that hung at boot without any output, even when adding the boot parameter "ignore_loglevel". Rebuilding kernel version 3.12.7-2 myself, always with the same procedure and always from a fresh copy of /var/abs/core/linux, sometimes resulted in a good kernel and sometimes in a bad one.
I have an idea, regarding searching the bug with git: You could try to find the subset of changes which changed from each kernel release to its successor. All you need is a list of working/nonworking kernels and a bit of git knowhow. I already asked how to do this with git here[0], but I didn't get an answer, yet! I don't know if it helps, but it could minimize the set of code you have to search in! I don't know if this is possible with git and I don't know if this is already done by one of you, but it may helps!
[0]: http://stackoverflow.com/questions/21117901/git-get-subset-of-changes-from-several-diffs
I've applied Matt Fleming's reloc2.patch to graysky's 3.12.9-1-ck and that's also started up fine, too.
Also let me remind you that I have built both booting and non-booting kernels from the same source (3.12.7-2), using the same procedure. So, what is the point in looking for differences in the source? There is no difference between 3.12.7-2 and 3.12.7-2. It just seems to be randomness at work.
@Wim Herremans: This kind of randomness is consistent with writing to some part of memory you're not supposed to, sometimes it has no visible effect if at all and other times it causes unexpected behavior or crashes the whole system. As it happens early in the boot process, we have no feedback, error message or logs to look at, which makes things harder to debug.
I am using reFIND + EFISTUB.
3.12.6-1 works fine for me.
You should probably get a kernel that's working for you and build it with a separate naming scheme so you always have a working kernel in your boot menu.
I followed the wiki instructions for compiling a kernel with a modified pkgbase here: https://wiki.archlinux.org/index.php/Kernels/Compilation/Arch_Build_System
The kernel 3.12.9-2 installed from the Arch repo, boots on my machine. Taking into account norealname4u's suggestion, I have tried to build the same version of the kernel with a different name that I keep in my boot menu in order to have a fallback if an upgrade of the offical kernel fails to boot. I have needed several rebuilds to get a booting 3.12.9-2 kernel with name 'vmlinuz-linux-custom'. So, also for version 3.12.9-2, I see the same weirdness that builds from the same source sometimes result in a booting kernel and sometimes don't. The only consistency is that a binary that boots once, always boots and a binary that fails to boot, always fails.
I have also double checked right now that I have uploaded the correct images and that they boot or don't boot as indicated.
While I am quite sure that all these kernels were built from the same source (3.12.7-2), I am not sure that I did not install updates on my system. I am fairly sure that I did not install updates between the last 2 builds. So, if the differences between the builds stem from the system environment and not from the source, it is possible that the difference between the last 2 builds is smaller.
Not sure if 3.13.2 would fix this issue: https://www.archlinux.org/packages/testing/i686/linux/
Grub works though.
Edit: I'm on a Lenovo Thinkpad X220 , booting with rEFInd!
As many others I'm using Gummiboot on a Lenovo Carbon X1
With rEFInd 0.7.7 installed, I can only get 3.12.6 to boot. No later. Any newer (including the 3.13.5) hangs when booting.
Same here, but my machine is a Lenovo ThinkPad E531. I'm usin gummiboot rather than rEFInd, though.
Even manually loading the kernel via UEFI Shell V2 causes a hang.
- linux-3.12.9-2-x86_64 boots without issue
- linux-3.13.3-1-x86_64 boots without issue
- linux-3.13.4-1-x86_64 hangs with a blank screen
- linux-3.13.5-1-x86_64 hangs with a blank screen
"hangs with a blank screen" means that I do not see ANY indication that the kernel even loaded. I hit enter in gummiboot and am greeted with a blank (black) screen. I have to do a hard power cycle of the machine, nothing else works.
3.12.9-1 works
3.13.2-3 works
3.13.5-1 doesn't work
3.13.6-1 works
I just installed the lts kernel in addition to the latest kernel to be able to boot.
Update: I build the kernel my self with the ABS PKGBUILD file but this didn't help.
3.13.5 worked fine but 3.13.6 hangs on a dell XPS13 Haswell using gummiboot
3.13.5-1 doess not work!
3.13.6-1 works!
I can boot my kernel with rEFInd again!
3.13.5-1 does work
3.13.6-1 does not work (blank screen immediately on trying to boot the kernel)
Lenovo X220, rEFInd.
It's a good thing that I can now reproduce this bug myself, but so far it hasn't helped me understand it.
3.12.9-2 works
3.13.4-1 works
3.13.5-1 works
3.13.6-1 hangs
3.13.7-1 hangs
works until 3.13.6-1
fails since 3.13.6-2
I could only reproduce this problem with gummiboot, but my Thinkpad boots fine without gummiboot.
I have downgraded to version 3.12.7-2, which does not boot with reFIND (it boots with GRUB2 though), to see if I could boot this kernel via efistub directly.
I have copied vmlinuz-linux and initramfs-linux.img to EFI System Partition and I have installed a boot entry for it by calling efibootmgr as follows:
efibootmgr -d /dev/sda -p 2 -L efistub -l /vmlinuz-linux -u "root=/dev/sda11 rw initrd=/initramfs-linux.img"
It does not boot and I don't get any error messages. It is just dead. But it does respond to Ctrl-Alt-Delete by rebooting. Just as with reFIND.
I have also tried to run it from the EFI shell, with the same result.
Afterwards, I have upgraded to kernel 3.13.7-1 again and I have copied vmlinuz-linux and initramfs-linux.img to the EFI System Partition again, to see if I could boot this kernel via EFISTUB directly. The result is that it boots normally, thus confirming that the boot entry was configured correctly with efibootmgr.
The main point of this discussion by the way is not the discussion of hanging boots, but a pointless stream of "me too" comments. Your comment however has exceeded the uselessness of those comments. You show complete ignorance at the difficulty and variety of the problem and at the same time act like a smartass trying to lecture others. A few more of such comments and I might just close the bug since keeping it open only serves to fill my inbox, but not to add any useful new information.
What I am wondering, is only ArchLinux users have experienced this problem? If yes, we may search why is that. Maybe because we use vanilla (kernel, gummiboot, etc.), but others use patched versions.
Probably if Fedora guys had it, the best kernel developers could step in?
Can we summarize information so far?
I myself have this issue, on my Thinkpad T430s, which is pitty.
Summary of information so far:
* Booting with EFISTUB may hang the system with no output and no indication of what the error may be.
* This is not bound to any changes in the code, but two builds of the exact same source may result in one booting and one failing kernel.
* This is limited to certain firmware, but present across several vendors.
* It depends on side-effects that are hard to reproduce: Depending on who tries to reproduce it, one of these may be the case:
+ It works without gummiboot but fails with gummiboot.
+ It works when first entering EFI shell before booting.
+ It only works when a USB device is plugged in.
+ It works when chainloading from refind to gummiboot to Linux, but not otherwise.
+ ... (more obscure situations)
None of this bug report's comments has added any new information to that in the last 4 weeks. I actually believed in a common but subtle configuration error, but now that I can reproduce the bug myself (thanks to my new Thinkpad), I am entirely clueless.
"If you use any Thinkpad and want UEFI, go to this ArchWiki page on how to install GRUB chainloader."
[1] https://wiki.archlinux.org/index.php/EFISTUB
I had been inadvertently regressing this particular commit with a patch I have been using since 3.7.7.
System: Host: anduril Kernel: 3.12.4-2-hplove x86_64 (64 bit) Desktop: Enlightenment 0.18.99.18202
Distro: Arch Linux
Machine: System: Hewlett-Packard product: HP EliteBook 2570p v: A1009D11
Mobo: Hewlett-Packard model: 17DF v: KBC Version 61.23
Bios: Hewlett-Packard v: 68ISB Ver. F.42 date: 07/17/2013
I use efistub and used the ck kernel line as a safe failover up until the last 2 revisions. I'm now frozen to 3.12.6-1-ARCH which is the last kernel version that boots for me, none of the 3.13 worked.
I'm largely ignorant about the linux kernel and its boot process, but the bug when the boot process hangs before even showing anything or a few lines of colored pixels feels like memory corruption of some kind, or maybe wandering in the wrong neighborhood of memory. I probably don't know what I'm talking about but as the bug happens after the screen refresh following and before something is displayed I'd start by looking at what happens in this time frame.
I have given up on ever getting this fixed and gone back to using Grub, I would prefer to use Gummiboot but almost none of the kernels including some of the AUR kernels such as linux-ck have stopped working in different builds. Linux-ck was my go to kernel and only stopped working in the last couple of builds.
I was actually looking into readding efilinux to the repositories, so you could call efilinux from gummiboot to boot the kernel.
Install it, then create boot entires for them. I'll use gummiboot as an example:
title Arch Linux (EFILINUX)
efi \EFI\efilinux\efilinux.efi
options xx -f \vmlinuz-linux initrd=\initramfs-linux.img root=/dev/xyz rw ...
The 'xx' after options is weird - if I write 'options -f ...', it doesn't work. This seems like a problem in gummiboot. Just put anything between the 'options' and '-f'. This should work similarly with refind.
---
bad: linux-3.14-4-x86_64.pkg.tar.xz - stock - gummiboot -> kernel
bad: linux-3.14-4-x86_64.pkg.tar.xz - stock (recompiled -j8) - gummiboot -> kernel
bad: linux-3.14-4-x86_64.pkg.tar.xz - stock (recompiled -j1) - gummiboot -> kernel
good: linux-3.14-4-x86_64.pkg.tar.xz - stock - gummiboot -> eflinux -> kernel
good: linux-3.14-4-x86_64.pkg.tar.xz - stock (recompiled -j8 - no setup_pci) - gummiboot -> kernel
None of the 3.14-* kernels worked for me so I was stuck with 3.13.6-1 (the last one that did work).
With the efilinux.efi handover I am able to boot 3.14-5 :)
This is on T440p.
---
bad: linux-3.14-4-x86_64.pkg.tar.xz - stock (recompiled -j8 - double check) - gummiboot -> kernel
good: linux-3.14-4-x86_64.pkg.tar.xz - stock (recompiled -j8 - setup_pci_hack2) - gummiboot -> kernel
@Jakub: This is really weird. I am using the T440s, doesn't that use even the same firmware as the T440p. The T440s boots fine all the time.
@Ulf: Can you recompile a kernel with the setup_pci hack several times? Since this bug occurs randomly, you might just have had luck. If this still works after several recompilations, we might be on to something here. If this is the case, you should post this to Matt on the upstream bug report.
[1] https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/linux&id=8a0cef5c69929f717a19f9624e4e1f798b53d1f6
@all: please try this very old patch: http://pastebin.com/24kvw8kt. To investigate this further I realy need some feedback, whether this "fixes" the bug or not.
commit 579d8f085b5745ea443a7e79b8283178f28981e0
Author: Borislav Petkov <bp@suse.de>
Date: Sat Jan 18 12:48:17 2014 +0100
x86/efi: Make efi virtual runtime map passing more robust
@Gerd: this did not solve the issue on my dell xps13
@Thomas: There is absolutely no need to disregard what Keshav and Ross say. I can only repeat what I and them have been saying: commenting out setup_efi_pci() "fixes" the bug any single time on atleast some systems. That is exactly why I wanted more sample data, as Matt kind of reacts the same way as you do. But if this works for 10 people instead of just 3 he might be more willing to listen to this. I put fixes above in quotes, as i really think this only shadows the bug. This bug is caused by some kind of memory corruption and storing all pci option roms into memory certainly does not help then. When we see that commenting out that function works for more people, matt or others might find out what exactly gets overwriten by those roms and why this happens. (double free?)
If this does not fit here, or I can help with testing something, please tell me. I tried to read through all the comments but it got a bit messy. I also read through https://bugzilla.kernel.org/show_bug.cgi?id=68761 and it seemed to have stopped at a point where the bug is still not solved. The issue there seems to match my problem well: when trying to boot it hangs without any output.
I've built at least a dozen vanilla kernels and grsecurity patched kernels with no issues since the code32_start patch was backported for the Arch package (T530 with up-to-date firmware, works with both gummiboot and direct efistub). The LTS kernel (3.10.39) also works fine for the past couple of point releases. It's possible that there are similar bugs on other hardware, but I don't think there are any left on mine. The majority of kernel builds didn't work before.
3.14-3 and 3.14-5 - don't work
3.14.1-1, 3.14.2-1 and 3.14.3-1 - all work fine
Version 1.55
UEFI: 1.55 / ECP: 1.55
(New) Added support for the UEFI DriverOrder feature.
(New) Updated the Diagnostics module to version 2.03.00.
(Fix) Fixed an issue where the power button did not work while the lid was closed.
(Fix) Fixed an issue where UEFI KeyShiftState was not correctly returned for some keys.
(Fix) Fixed an issue where SMBIOS type 15 structure (System Event Log) was incorrect.
(Fix) Fixed an issue where the LCD brightness control might not work on Linux.
I just wonder if the SMBIOS type 15 structure may have any bearing on this efistub issue? I guess it will take a while to see if I get an further boot failures - recent kernels have booted OK for my with rEFInd but I will report if there is any problem with updated kernels.
I also noticed that they released a new BIOS for the W540 in the past week also, and again owners of that machine who update might check if that makes any difference also.
Make.tiano:46: recipe for target 'refind_x64.dll' failed
make[1]: *** [refind_x64.dll] Error 1
make[1]: Leaving directory '/home/mike/Documents/install_stuff/arch/refind-debugging/builds/src/refind-0.8.1/refind'
Makefile:34: recipe for target 'tiano' failed
make: *** [tiano] Error 2
==> ERROR: A failure occurred in build().
Aborting...
Has anyone been able to build refind-efi version 0.8.1 so that it can be tested?
@Daniel: if you still run into trouble, you might try the patch [1] I posted at [2]. It does not fix the problem but betterifies the logging in combination with "ignore_loglevel earlyprintk=efi" as kernel parameters.
[1] https://bugzilla.kernel.org/attachment.cgi?id=134131
[2] https://bugzilla.kernel.org/show_bug.cgi?id=68761
@Ulf I added your patch to your custom kernel and it now boots but takes a while to do so as it logs everything. I have no idea what I am looking at in the logs before the normal kernel log lines, anything I can do to help?
@Ross: The logging patch is only really useful, when it is compiled in a kernel that does not boot.
So has anyone got any experience with diagnosing really early boot problems as this bug relates to? There are a lot of experts who have been looking into this but so far all attempts at triage have not led to a solution.
I also found there are links to edk2 debug information at https://uefidk.com/sites/default/files/UDK_Debugger_Tool_User_Manual-SR1_v1_10.pdf which is a link from https://uefidk.com/develop/intel-uefi-tools-and-utilities/intel-uefi-development-kit-debugger-tool
For quite some time I have not had an efi stub kernel fail to load on my uefi machines, but if someone has a recent kernel that won't load in rEFInd or gummiboot then although this possible route to debug will take time and effort to set up maybe it will give the first positive information about what is going on with this bug?
linux-3.15.3-1 : bad
linux-3.15.3-1 (rebuild) : good
linux-3.15.3-1 (rebuild, err logging patched) : good
with my error logging patch applied and earlyprintk=efi, I can see that setup_pci always fails on my dell xps13 fhd ivb, but the kernel still boots. I upoaded the the kernel (stock arch 3.15.3-1 with [1]) here: [2]. If someone wants to try the kernel, watch out for the very first logging messages.
@Tobias, Thomas: Could we apply [1] to the stock arch kernel? I will ask Matt to include it in mainline, but i guess this will take some time.
[1] https://bugzilla.kernel.org/attachment.cgi?id=134131
[2] https://mega.co.nz/#!FQB3BIbL!zu4BnrziYVi30ueC-Coop8s3w-q8RWZL4vEeHmW4B0c
[2] https://git.kernel.org/cgit/linux/kernel/git/mfleming/efi.git/patch/?id=b50a7cee9532e9b17e8a90b022121188c9fc718c
[1] https://mega.co.nz/#!VlcEjDoK!51qTJvZHs5w6s4WFblLSS8cBXyPwuJqS9Ih2ado7ufc
[2] https://mega.co.nz/#!gosH0QKa!pnBrFsvVtyKHRkKnA6G2ZW7dM_Ea4WBLlhGGHEj5Cbo
@Steven: the kernel i posted above does not boot on your system, odes it?
Cheers, Ulf
That was 3.15.5-1 from [core].
Will check 3.15.5-2 today and let you know if it works.
commit c7fb93ec51d462ec3540a729ba446663c26a0505
Author: Michael Brown <mbrown@fensystems.co.uk>
Date: Thu Jul 10 12:26:20 2014 +0100
x86/efi: Include a .bss section within the PE/COFF headers
The PE/COFF headers currently describe only the initialised-data
portions of the image, and result in no space being allocated for the
uninitialised-data portions. Consequently, the EFI boot stub will end
up overwriting unexpected areas of memory, with unpredictable results.
Fix by including a .bss section in the PE/COFF headers (functionally
equivalent to the init_size field in the bzImage header).
Signed-off-by: Michael Brown <mbrown@fensystems.co.uk>
Cc: Thomas Bächler <thomas@archlinux.org>
Cc: Josh Boyer <jwboyer@fedoraproject.org>
Cc: <stable@vger.kernel.org>
Signed-off-by: Matt Fleming <matt.fleming@intel.com>
This is the installer I used:
archlinux-2014.07.03-dual.iso
Could the installer be fixed please?
Thanks!
Edited: to add installer name