[SOLVED] UEFI with gummiboot: somtimes (!) just black screen

niklaas · 2013-08-17 19:45:08

Hi,

since two days I'm trying to get UEFI work on my Lenovo T420. The problem is that there's only a black screen when activating the "Arch Linux" entry in gummiboot if I have not plugged in the installation medium (as a USB drive). If it's inserted sytemd starts booting but stops at a certain point complaining there are starting jobs running on /dev/sdc (the USB drive); then I get to the rescue shell. If it's not inserted there's just a black screen. To start the system I have to leave the USB drive plugged in and fastly remove it when systemd starts booting after selecting "Arch Linux" in gummiboot. I don't know why, but the system does boot then.

This is what I have done:

In BIOS I changed the settings that it's booting with UEFI "and" BIOS at least trying first BIOS and then UEFI. I followed the installation instructions of the Beginner's Guide (https://wiki.archlinux.org/index.php/Beginners%27_Guide) installing a system with LVM (ensuring that the install medium is booted in UEFI). I followed the recommendations of https://bbs.archlinux.org/viewtopic.php … 3#p1240883 concerning partitioning. This is the setup I have:

niklaas@len-t420-arch ~ % lsblk --output +UUID
NAME                  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT UUID
sda                     8:0    0 238,5G  0 disk            
├─sda1                  8:1    0   100M  0 part            
└─sda2                  8:2    0 238,4G  0 part            
sdb                     8:16   0 119,2G  0 disk            
├─sdb1                  8:17   0   512M  0 part /boot      D3F0-DA3E
├─sdb2                  8:18   0   512M  0 part            d66ae708-051f-43f8-bae8-b35a985cd75f
└─sdb3                  8:19   0 118,2G  0 part            Loovu6-pH7j-Ou8r-HiH0-yJFm-Riq7-Pbsi4s
  ├─VolGroup00-lvroot 254:0    0    25G  0 lvm  /          349e5a88-72ca-40cb-8e44-0b67b85ffee4
  ├─VolGroup00-lvvar  254:1    0    15G  0 lvm  /var       46980ec6-f2f3-4a08-a350-f6621a23054f
  ├─VolGroup00-lvswap 254:2    0     8G  0 lvm  [SWAP]     156243f8-f374-4e27-86f0-d442850c6c3f
  └─VolGroup00-lvhome 254:3    0  70,2G  0 lvm  /home      ae86bb5c-2829-4af9-9ffb-0206d10f02a4

(/dev/sda is Windows 7)

Please note that I /dev/sdb1 is the EFI System Partition and there's also another partition (/dev/sdb2) I created just in case I want to use a separate /boot partition. (Currently there's syslinux on it because I was experimenting whether I get the system to boot normaly, which means without the USB drive, by using Legacy BIOS and syslinux. But I was not successful: Screen also stays black.) This is what /boot looks like and the contents of /boot/loader/entries/arch.conf and /boot/loader/loader.conf:

niklaas@len-t420-arch ~ % tree /boot
/boot
├── EFI
│   ├── BOOT
│   │   └── BOOTX64.EFI
│   └── gummiboot
│       └── gummibootx64.efi
├── initramfs-linux-fallback.img
├── initramfs-linux.img
├── loader
│   ├── entries
│   │   └── arch.conf
│   └── loader.conf
└── vmlinuz-linux

niklaas@len-t420-arch ~ % cat /boot/loader/entries/arch.conf
title   Arch Linux
linux   /vmlinuz-linux
initrd  /initramfs-linux.img
options root=UUID=349e5a88-72ca-40cb-8e44-0b67b85ffee4 rw

niklaas@len-t420-arch ~ % cat /boot/loader/loader.conf
timeout 3
default arch

Additionally to the strange USB-drive-needs-to-be-plugged-in issue there is another one: Because there's a Windows 7 installation (unfortunately I need it) on /dev/sda with Truecrypt I decided to install two bootloaders: one is on /dev/sda and the other one on /dev/sdb. So I can "manually" switch between operating systems by using the boot manager that is provided by the BIOS of the motherboard which makes it possible to change boot priority quite simply. After the installation of gummiboot there was (of course) another entry created, so there are three:

1. Linux Boot Manager
2. ~first SSD (with Windows; /dev/sda)
3. ~second SSD (with Arch Linux; /dev/sdb)

When I select the first entry, even the USB-drive-trick does not work. There just resides the black screen. This I do not understand at all because, as already described above:

If I select the third option, gummiboot gets loaded and I can select "Arch Linux". Then, as already mentioned, there are three options: (a) USB-drive is inserted > I plug it off immediately after systemd starts > system boots (b) USB-drive is inserted > I don't (!) plug it off > systemd complains about starting job running on /dev/sdc > I get the rescue shell (c) USB-drive is not (!) inserted > I just get a black screen.

I hope the issue I have is quite understandable. Otherwise, please ask and I'll try my best to clarify things. Any help is really appreciated,
Niklaas

niklaas@len-t420-arch ~ % uname -a
Linux len-t420-arch 3.10.6-2-ARCH #1 SMP PREEMPT Tue Aug 13 09:47:01 CEST 2013 x86_64 GNU/Linux

Last edited by niklaas (2013-08-18 07:02:01)

srs5694 · 2013-08-17 21:08:43

My hunch is that you're running into the bug that's under discussion here. If so, you may be able to get it working more reliably by switching boot managers (to rEFInd or to the version of rEFInd that's built with GNU-EFI) or boot loaders (to GRUB or ELILO).

cfr · 2013-08-18 01:10:28

I don't know why it would work at all in this case but are you sure that you can specify root= like that on the command line? Rather than e.g. root=/dev/VolGroup00/lvroot, for example?

niklaas · 2013-08-18 07:01:25

srs5694 wrote:

My hunch is that you're running into the bug that's under discussion here. If so, you may be able to get it working more reliably by switching boot managers (to rEFInd or to the version of rEFInd that's built with GNU-EFI) or boot loaders (to GRUB or ELILO).

OK. I decided to use syslinux and installed it from the AUR. After installation was successfull, I copied all files as described in https://wiki.archlinux.org/index.php/UE … LINUX_6.xx to /boot/syslinux and ran command

# efibootmgr -c -d /dev/sdb -p 1 -l /EFI/syslinux/syslinux.efi -L "syslinux"

to create an entry. And I could just successfully boot without USB-drive. Thank you.

cfr wrote:

I don't know why it would work at all in this case but are you sure that you can specify root= like that on the command line? Rather than e.g. root=/dev/VolGroup00/lvroot, for example?

I guess, I also tried this before having the same outcome.

But I still do not understand what's happening when I select my second SSD; because there's still gummiboot loaded and I can still boot the system with the USB-drive. Does anybody know what's happening there? I'm totally clueless why the system is somehow accessing the flash drive?!

Last edited by niklaas (2013-08-18 07:02:31)

cfr · 2013-08-18 14:15:19

Is gummiboot installed as EFI/boot/bootx64.efi on your EFI partition? That's the fallback boot loader location and what you get if you select the hard drive (rather than an EFI boot menu entry) to boot.

niklaas · 2013-08-18 21:26:57

cfr wrote:

Is gummiboot installed as EFI/boot/bootx64.efi on your EFI partition? That's the fallback boot loader location and what you get if you select the hard drive (rather than an EFI boot menu entry) to boot.

Ah, that makes sense! But do you have any clue why the system booted without problems with the flash drive plugged in? I'm just curious.

cfr · 2013-08-18 23:28:47

I don't. But srs5694 may well have an idea.

EFI booting is still... how shall I put it? A bit like chucking darts at a dart board blindfolded, with your best hand tied behind your back, while facing in the opposite direction after a few too many drinks at the bar, yet hoping to hit the bullseye. Often the OEM is behind your back repainting the moving dartboard as well.

Last edited by cfr (2013-08-18 23:29:43)

WonderWoofy · 2013-08-19 01:05:35

I think though that this is really highly dependent on your firmware. Though I had some issues at the onset of using this machine, pretty much everything has been ironed out with bios updates. Unfortunately, cfr has had more issues with UEFI than anyone else I have talked to. His understanding of how UEFI works leads me to believe that they are definitely firmware bugs as well. I think it partially has to do with the fact that his machine as UEFI v1, while every new machine now is being shipped with UEFI v2.

cfr · 2013-08-19 01:13:15

Na. It's version 2 it is just quite a early version of version 2 e.g. most people have 2.13 or so and I seem to have 2.00. I think only Macs had version 1 but I could be mistaken.

So we are all playing darts, then, but everybody has a different dartboard in a different direction and some OEMs repaint them with helpfully large bullseyes while others obliterate the bullseye altogether.

WonderWoofy · 2013-08-19 01:20:08

My bullseye got bigger over time

cfr · 2013-08-19 01:24:49

Not only has my bullseye disappeared entirely, somebody nicked all my darts as well .

WonderWoofy · 2013-08-19 01:32:39

I don't know that your target is even a single piece... and said pieces are likely in all different directions... in the next room... behind a half wall... backwards.

Arch Linux

#1 2013-08-17 19:45:08

[SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#2 2013-08-17 21:08:43

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#3 2013-08-18 01:10:28

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#4 2013-08-18 07:01:25

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#5 2013-08-18 14:15:19

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#6 2013-08-18 21:26:57

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#7 2013-08-18 23:28:47

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#8 2013-08-19 01:05:35

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#9 2013-08-19 01:13:15

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#10 2013-08-19 01:20:08

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#11 2013-08-19 01:24:49

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

#12 2013-08-19 01:32:39

Re: [SOLVED] UEFI with gummiboot: somtimes (!) just black screen

Board footer