You are not logged in.
Experiencing the same problem with ThinkPad T430, gummiboot and kernel version 3.7.6-1 (black screen after gummiboot menu). I wonder if anyone in this thread has everything working with the new kernel?
Same thing here on my T430; 3.7.4 & 3.7.6 both caused issues, 3.7.5 works fine.
Offline
btby wrote:Experiencing the same problem with ThinkPad T430, gummiboot and kernel version 3.7.6-1 (black screen after gummiboot menu). I wonder if anyone in this thread has everything working with the new kernel?
Same thing here on my T430; 3.7.4 & 3.7.6 both caused issues, 3.7.5 works fine.
Same here. T430s.
Offline
Same here, 3.7.5 worked but 3.7.6 didn't. Thinkpad w530. However, downgrading didn't work for me. I'll give it another go when I can get my hands on a live media, I might have forgotten to copy the efistub kernel last time. Will report back. Do you guys think it's thinkpad-specific or kernel-specifik?
EDIT: I am now reporting back, copying the efistub kernel to the right location worked. How stupid of me to forget that little part just because I were in a chroot (i.e. no systemd to do it for me).
Last edited by MFserver (2013-02-12 10:31:50)
Sometimes, when I'm trying to get any audio software or hardware working with my system, I wonder why I ditched Windows. But every time I work at a windows computer, I remember it again.
Offline
Has anyone here tried the 3.7.7 yet?
Offline
3.7.7 works fine.
Offline
3.7.7 works fine.
Works for me as well. I'm really curious as to what the cause of this is.
Offline
The problem is gone when using 3.7.7 for me as well.
Offline
Confirmed here too, 3.7.7 works.
Sometimes, when I'm trying to get any audio software or hardware working with my system, I wonder why I ditched Windows. But every time I work at a windows computer, I remember it again.
Offline
I've been using linux-ck from the repo-ck. 3.7.7 and earlier worked just fine, but 3.7.8 doesn't load. I'm using rEFInd on a T420.
Offline
I've been using linux-ck from the repo-ck. 3.7.7 and earlier worked just fine, but 3.7.8 doesn't load. I'm using rEFInd on a T420.
I can confirm that the fun continues with 3.7.8 not booting. This is becoming quite a nuisance. Has anyone checked the kernel builds to see what is changing between the kernels that boot and the ones that don't?
Offline
Same here with 3.7.8, Thinkpad X230 refind uefi boot.
I made sure, the kernel and refind are copied in place.
Offline
My thinkpad seems to be doing just fine, though I have an E430. Whenever I do actually run into booting problems I always test with the uefi shell to see whether or not it really is the stub loader (for me it hasn't been as of yet). Usually it is me having done something silly with gummiboot.
Offline
Just to chime in. I am having the same problem. Using rEFInd on an IdeaPad z580. This sounds very related to Lenovo hardware. My only problem is that I am in the middle of installing for the first time so I can't downgrade the kernel. Anyone have any ideas on what I can do. Should I just install with the ISO that has the 3.6 kernel on it?
Offline
@DaBungalow, I say just use a uefi bootloader for now. You can always change/add boot method later. Plus it is actually nice to have a backup boot solution for when stuff like this occurs. The beauty of uefi is that you can totally have gummiboot, refind, grub, etc coexist and all be able to boot your system. So keep your system up to date and choose an actual bootloader instead of a boot manager for now.
You could also use BIOS booting for now... like syslinux, as that too can exist without effecting other uefi bootloaders.
Offline
So, this problem occurs both with rEFInd and Gumiboot, o I think we can assume it's not a problem with the bootloader. It occurs with kernels 3.7.3, 3.7.4, 3.7.6, and 3.7.8, and has so far only been reported on Lenovo hardware. As I see it, there are three possible problems:
- It's kernel-related. But then, users with non-Lenovo systems should have appeared here by now.
- It's related to the way Linux boot managers work in general. But again, someone with a non-lenovo laptop should be here.
- It's Lenovo-related. This seems like the most probable explanation.
I'll post on the Lenovo forums to see if other distros are affected too. If anyone has a UEFI laptop that can be used to perform some tests with both rEFInd and Gummiboot with a couple of problematic kernels, it would be great. I don't really want to do that on my main laptop right now, I might get in a spot where I don't have time to fix it again. I'll test 3.7.8 tomorrow, though, and maybe the latest rEFInd with 3.7.{5,6,7,8}. Will post my results here and on the Lenovo forum. I have a feeling that a bug should be reported somewhere.
Sometimes, when I'm trying to get any audio software or hardware working with my system, I wonder why I ditched Windows. But every time I work at a windows computer, I remember it again.
Offline
Hm, that's really a strange phenomenon. I have a Lenovo Thinkpad Edge E520 (1143bbg) and it works pefect with rEFInd and every new kernel over the last three or four months (since I'm using rEFInd and boot my machines in UEFI mode).
So, I don't think it's a general Lenovo problem, but maybe a problem of some Lenovo products. Maybe it's worth to collect the models, the mainboards and the firmware of the affected devices.
Another relevant point: It looks as if at least some combinations of kernels and rEFInd are indeed working with the devices in question. So, there are a lot of variables
Arch_x64 on Thinkpad Edge E520 (Intel Core i5, 4 GB RAM, 128 GB Crucial M4 SSD) + ITX-Desktop (Asrock H77M-ITX, Intel Core i3-2120T, 8GB RAM, 64 GB Samsung 830 SSD)
Offline
Could you post a list of the kernels you have tried? i.e, what is the output of:
ls /var/cache/pacman/pkg | grep linux-3.7
This is a strange problem indeed. I have made a little research, but haven't found it reported on any other forum. I submitted a thread at the Lenovo forums here. I hope it's a kernel or boot manager problem so that it will be fixed, if it's Lenovo they might just let it be. Similar things has happened before.
Sometimes, when I'm trying to get any audio software or hardware working with my system, I wonder why I ditched Windows. But every time I work at a windows computer, I remember it again.
Offline
OK,guys,I just did a little experiment with my laptop.The result was pretty interesting.I think we are one step closer to the nature of the problem.
Hardware: Thinkpad E530(3259C13)
Steps and results:
1.refind(0.6.6,0.6.7) + linux 3.7.7-->booted
2.refind(0.6.6,0.6.7) + linux-zen 3.7.8 -->failed:white screen
3.update linux-zen to 3.7.9. refind(0.6.6,0.6.7) + linux-zen 3.7.9 -->failed:white screen
4.modprobe efivars;Add archlinux and archlinux-zen entry directly to uefi with efibootmgr
Boot0013* Arch Linux Zen
Boot0014* Arch Linux
Boot0012* rEFInd HD(2,6000,1ff802,5283a745-253f-456f-bbc9-53acf0b5da8b)File(\EFI\refind\refind_x64.efi)
Boot0013* Arch Linux Zen HD(2,6000,1ff802,5283a745-253f-456f-bbc9-53acf0b5da8b)File(\vmlinuz-linux-zen)r.o.o.t.=.U.U.I.D.=.a.4.e.4.7.d.d.5.-.b.b.8.b.-.4.a.7.5.-.b.a.9.a.-.2.3.d.a.f.5.9.b.7.0.4.0. .r.o. .r.o.o.t.f.s.t.y.p.e.=.e.x.t.4. .a.d.d._.e.f.i._.m.e.m.m.a.p. .i.n.i.t.r.d.=.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x.-.z.e.n...i.m.g...
Boot0014* Arch Linux HD(2,6000,1ff802,5283a745-253f-456f-bbc9-53acf0b5da8b)File(\vmlinuz-linux)r.o.o.t.=.U.U.I.D.=.a.4.e.4.7.d.d.5.-.b.b.8.b.-.4.a.7.5.-.b.a.9.a.-.2.3.d.a.f.5.9.b.7.0.4.0. .r.o. .r.o.o.t.f.s.t.y.p.e.=.e.x.t.4. .a.d.d._.e.f.i._.m.e.m.m.a.p. .i.n.i.t.r.d.=.\.i.n.i.t.r.a.m.f.s.-.l.i.n.u.x...i.m.g...
5.boot Arch Linux (Boot0014) in UEFI menu -->failed: kernel indeed booted but immediately rebooted.I saw 2 lines of text on the top of the screen after UEFI menu disappeared.
6.boot Arch Linux Zen (Boot0013) in UEFI menu -->booted!
7.boot Arch Linux (Boot0014) in UEFI menu,again -->booted!
8.refind(0.6.7) + linux-zen 3.7.9,again -->booted!
9.install gummiboot.both 3.7.7 and 3.7.9 --> booted!
All the things went normal after adding 2 entries with efibootmgr and booting them in UEFI.
Last edited by darrenlee (2013-02-18 15:05:22)
Offline
4.modprobe efivars;Add archlinux and archlinux-zen entry directly to uefi with efibootmgr
Could you please put your command details for using efibootmgr to add the updated archlinux and archlinux-zen kernels to the uefi menu? I did this a bunch a few months ago, but I've forgotten the steps and am too lazy to read up on it again. (I know, of course, that I need to load the efivars module, but I can't remember the rest.)
While I'm really happy that you've evidently found a fix, I'm still mystified why suddenly there's now no success with the previously tried-and-true method of renaming a new arch kernel with an efi extension and copying it, along with its corresponding initramfs.img, to the EFI partition -- and especially why this efi stub method stopped working with kernel 3.7.6, resumed working with 3.7.7, and ceased working again with 3.7.8 and 3.7.9.
I always have a second way of booting a new Arch kernel since I have, in my rEFInd menu, an option for booting via grub, and my grub config always pulls up whatever Arch kernel is current. But I prefer to bypass this.
Thanks, darrenlee.
------
UPDATE: I got unlazy and I think I've rediscovered the needed command string here under the section "Using efibootmgr entry":
https://wiki.archlinux.org/index.php/UEFI_Bootloaders
Last edited by dhave (2013-02-18 15:20:33)
Offline
darrenlee wrote:4.modprobe efivars;Add archlinux and archlinux-zen entry directly to uefi with efibootmgr
Could you please put your command details for using efibootmgr to add the updated archlinux and archlinux-zen kernels to the uefi menu? I did this a bunch a few months ago, but I've forgotten the steps and am too lazy to read up on it again. (I know, of course, that I need to load the efivars module, but I can't remember the rest.)
While I'm really happy that you've evidently found a fix, I'm still mystified why suddenly there's now no success with the previously tried-and-true method of renaming a new arch kernel with an efi extension and copying it, along with its corresponding initramfs.img, to the EFI partition -- and especially why this efi stub method stopped working with kernel 3.7.6, resumed working with 3.7.7, and ceased working again with 3.7.8 and 3.7.9.
I always have a second way of booting a new Arch kernel since I have, in my rEFInd menu, an option for booting via grub, and my grub config always pulls up whatever uArch kernel is current. But I prefer to bypass this.
Thanks, darrenlee.
You're welcome.I'm very glad I could help.
The exact command lines are:
echo "root=UUID=$(blkid /dev/sda8 -o value -s UUID) ro rootfstype=ext4 add_efi_memmap initrd=\\initramfs-linux.img" | iconv -f ascii -t ucs2 | efibootmgr -c -g -d /dev/sda -p 2 -L "Arch Linux" -l '\vmlinuz-linux' -@ -
echo "root=UUID=$(blkid /dev/sda8 -o value -s UUID) ro rootfstype=ext4 add_efi_memmap initrd=\\initramfs-linux-zen.img" | iconv -f ascii -t ucs2 | efibootmgr -c -g -d /dev/sda -p 2 -L "Arch Linux Zen" -l '\vmlinuz-linux-zen' -@ -
My root fs is on /dev/sda8
My EFI system fs is on /dev/sda2
Offline
Thanks, darrenlee. I'm still trying to get the kinks out, but I'm glad to be reminded how to go about de-kinking things.
Last edited by dhave (2013-02-18 16:01:30)
Offline
So, this problem occurs both with rEFInd and Gumiboot, o I think we can assume it's not a problem with the bootloader.
No, that's not a safe assumption -- but your phrasing may simply reflect a lack of understanding or looseness with language. In diagnosing this problem, it's critical to distinguish, and understand the relationships, between boot loaders and boot managers:
Boot managers provide a user interface that enables the user to select which boot option to use. In EFI, the firmware itself provides a boot manager (usually very primitive), while rEFIt, rEFInd, and gummiboot are all add-on boot managers.
Boot loaders load the kernel into memory and transfer control to it. In EFI, efilinux, ELILO and the EFI stub loader are all purely boot loaders. GRUB 2 is a boot loader, too, but it also includes boot manager functions. (So does ELILO, but only between Linux kernels, which is why I've classified it as a boot loader.)
Since the EFI stub loader is built into the kernel, using it can blur the distinction between boot loaders and boot managers. To a user, both rEFInd and ELILO provide boot menus that sit between the firmware and the kernel, so they seem to fill a similar role. The critical difference is in how they launch the kernel. Boot managers do so by launching the kernel as an EFI application and relying on the EFI stub loader, whereas boot loaders do so with their own code that loads the kernel and executes it in other ways.
This problem seems to involve loading certain Linux kernels via their EFI stub loaders. Thus, it's entirely plausible that the problem lies in the EFI stub loader code, which is a boot loader. The fact that darrenlee has reported problems with three boot managers (the EFI's own boot manager, rEFInd, and gummiboot) strongly suggests that the cause is not in the boot manager, but is in the kernel or the kernel's EFI stub loader. The fact that the same combination of boot loader and boot manager loaded the kernel after making changes to the EFI's boot loader settings (via efibootmgr) is peculiar. Perhaps this NVRAM change is having some subtle follow-on effect for the stub loader or the kernel...
Another test one of you could perform is to install ELILO or GRUB (or perhaps efilinux, but it's related to the EFI stub loader and is difficult to get working, in my experience -- in fact, I've never succeeded). If the problem persists with rEFInd or gummiboot but is overcome when using ELILO or GRUB, then that strongly implicates the EFI stub loader as the culprit. If the problem occurs with ELILO and/or GRUB, then it's something else in the kernel that's causing problems on some systems.
Offline
@srs5694: Maybe this info will be helpful:
When I boot via grub (I have grub as one of my rEFInd menu options), I'm able to boot all these new kernel releases on my UEFI-only Thinkpad T420. On the other hand, when I use the Arch kernel option from rEFInd, kernel 3.7.6, 3.7.8, and 3.7.9 fail. Kernel 3.7.7 boots.
(When I say "Arch kernel option from rEFInd", I mean that rEFInd attempts to boot the initramfs.img and kernel that I've copied to my EFI partition.)
I had been hoping that maybe rEFInd no longer liked even-numbered kernels, but then when 3.7.9 failed today, that theory went out the window.
Last edited by dhave (2013-02-18 16:33:41)
Offline
FYI, at some point, I believe that efibootmgr was updated to accept ascii, so the piping is apparently no longer necessary. I have not tried it myself, as I have been using gummiboot, so no binary args are needed, but I found an old thread regarding this that I can now no longer find...
So just for the record, I am on a Lenovo ThinkPad E430 (3254-CTO) and everything works for me with gummiboot 17-1 and all kernels. I have not tried refind yet, and am out of town right now, so I will give it a go when I get a chance and report back.
Offline
Could you post a list of the kernels you have tried? i.e, what is the output of:
ls /var/cache/pacman/pkg | grep linux-3.7
These are the 3.7* kernels I had/have in use on my TP Edge E520 (1143bbg):
$ ls /var/cache/pacman/pkg/ | grep linux-3.7
linux-3.7.3-1-x86_64.pkg.tar.xz
linux-3.7.4-1-x86_64.pkg.tar.xz
linux-3.7.5-1-x86_64.pkg.tar.xz
linux-3.7.6-1-x86_64.pkg.tar.xz
linux-3.7.7-1-x86_64.pkg.tar.xz
linux-3.7.8-1-x86_64.pkg.tar.xz
linux-3.7.9-1-x86_64.pkg.tar.xz
... and these are the versions of refind-efi I had/have in use:
$ ls /var/cache/pacman/pkg/ | grep refind-efi
refind-efi-0.6.4-1-any.pkg.tar.xz
refind-efi-0.6.5-1-any.pkg.tar.xz
refind-efi-0.6.6-1-any.pkg.tar.xz
refind-efi-0.6.7-1-any.pkg.tar.xz
With all of these I never had a problem booting Arch.
Arch_x64 on Thinkpad Edge E520 (Intel Core i5, 4 GB RAM, 128 GB Crucial M4 SSD) + ITX-Desktop (Asrock H77M-ITX, Intel Core i3-2120T, 8GB RAM, 64 GB Samsung 830 SSD)
Offline