R2B2 installation failure, Thinkpad X201

[Daniel Selifonov]

Hi all,

I finally got around to clearing off my Qubes 1.0 install on my Lenovo Thinkpad X201, burned a R2B2 DVD, and attempted to install it. When booting the DVD with the standard installation options, the contents of the screen become moderately garbled once KMS is activated, and usually a few seconds later the system shows what looks like a kernel panic stack trace -- only rarely does it get far enough to the graphical installer (which is readable/unusable anyway with the screen scrambling).

Supplying "i915.modeset=0" or "nomodeset" (or using the "basic graphics" mode in troubleshooting, which does variants of this) to kernel arguments addresses the scrambled screen, but when anaconda starts an X server, I get stuck at a fully black screen. Supplying "i915.blacklist=1" instead, results in anaconda failing to start an X server, and falling back to text mode. At this point I'd be perfectly happy attempting a text mode installation, but after setting a timezone and installation destination, the text-mode installer fails with error message "luks device has no key/passphrase" -- and there is no option to configure disk encryption key.

At least in this mode, I can switch to vt2 and read the X.log to figure out what's going on, and I see the following EE entries:

1) open /dev/dri/card0: No such file or directory

2) open /dev/fb0: No such file or directory

3) Screen(s) found, but none have a usable configuration

Further, I notice that if I attempt a "modprobe i915", I get the following error message: "modprobe: ERROR: ctx=0x876010 path=/lib/modules/3.7.6-2.pvops.qubes.x86_64/kernel/drivers/char/agp/intel-agp.ko error=No such file or directory". I would speculate, thus, that the installation environment is missing some components required for properly functioning of (pre-Sandy Bridge) Intel HD graphics, and unfortunately I can't seem to use any of the fallback options to correct this, or proceed with installation.

I attempted passing "nodri" as a boot parameter, and although it addressed the former two X.log messages, X would still fail to find a screen with usable configuration (and continue to generate the 3rd message).

lspci entry for the graphics (CPU is an i7-620M, Arrandale architecture):

00:02.0 VGA compatible controller: Intel Corporation Core Processor Integrated Graphics Controller (rev 02) (prof-if 00 [VGA controller])

The Intel graphics is the only GPU on the system. There is no nVidia Optimus or other separate discrete GPU.

I also attempted loading the Linux kernel and initrd directly without going through Xen -- in case the hypervisor was affecting anything, but the results looked the same.

Any ideas for getting this working? Would any additional information be helpful?

Regards,

-Daniel Selifonov

[iva...@gmail.com]

any sugestions?

is it a bug or missconfiguration or hardware incompatibility?

please just common guideline to know how to proceed.

thnx!

[Marek Marczykowski]

Did you tried any other recent Linux distribution? I'm afraid that above means
that drivers for your hardware are broken current Linux kernel/Xorg.
You can try installation with kickstart script - this should allow you to
complete install in text mode. Standard Fedora instructions applies here.
Remember to setup root password (Qubes installer lock it by default, but
"rootpw" kickstart command should work) - otherwise you will not be able to
login, as user account is created by firstboot, which require working Xorg.

It will be easier to debug issue on installed system.

--
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[iva...@gmail.com]

right after my failure i downloaded latest debian netinstall and there wasn't any problems. now it's running debian. next time i go to the server room i'll try what you write. thnx!

[Igor Bukanov]

As I was also hit by this bug on my X201 I tried live images for Fedora 18, Ubuntu 13.04 beta2 and Linux Mint. None of them showed any signs of booting troubles.

[Daniel Selifonov]

Hi all again,
I've been poking at this periodically since my initial mail to the
list in March. I set up a qubes-builder environment and built a half
dozen kernel/system configuration variants to try to figure this out.
The short version is that I was able to get a working install by
building Qubes with a 3.6.11 Linux kernel version -- no other
configuration changes required/helped.

I built (my final working version) from Marek's repositories
yesterday, and there are a few Qubes specific things that look broken
(qvm-run --tray behavior, and synchronization of applications from the
template), but I ascribe this to building from the latest source code,
rather than whatever was released as beta 2. Post install, I did
notice some minor graphical glitches in KDE with desktop compositing
enabled, but nothing anywhere close to the problems I was having with
the R2-beta2 installation disk.

I did some subsequent research on the topic and discovered these bug
tracking threads on similar issues (but symptoms are slightly
different in Qubes installer environment):
https://bugs.archlinux.org/task/33548
https://bugs.archlinux.org/task/33062
https://bugs.freedesktop.org/show_bug.cgi?id=57365

In summary, it looks like an Intel GPU regression was introduced in
Linux 3.7, but has been corrected as of Linux 3.9-rc1. One of the
Qubes kernel patches (PVUSB) wouldn't apply to 3.9 when I tried to
build, so I chose to try the latest 3.6.x release. Presumably, when
R2-beta3 is released, you'll be updating the kernel version again.

HCL summary:
Qubes release 2 (R2)
Model Name: LENOVO 3249CTO

Chipset: 00:00.0 Host bridge [0600]: Intel Corporation Core Processor
DRAM Controller [8086:0044] (rev 02)
VGA: 00:02.0 VGA compatible controller [0300]: Intel Corporation Core
Processor Integrated Graphics Controller [8086:0046] (rev 02)
CPU: Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz
BIOS: 6QET69WW (1.39 )
VT-x: Active
VT-d: Active

HCL full details package is attached.

Maybe now I can actually work on feature improvements for Qubes,
rather than just getting the latest version working. :)

Regards,
-Daniel Selifonov

[Joanna Rutkowska]

Daniel,

Ok, I don't really want to delve into your specific problems :) But
since you apparently have done quite a bit of work to get your hardware
to work with Qubes, and all that work, like in many other case, was all
about getting the "right kernel" to the right hardware, do you have any
thoughts about adding support for multiple Dom0 kernels to Qubes OS?
This involves ability to choose the proper kernel at installer, not only
during normal boot. This has been once covered by the ticket #581:

http://wiki.qubes-os.org/trac/ticket/581

And also is somehow related to the ticket #727:

http://wiki.qubes-os.org/trac/ticket/727

Perhaps you would be interested in working on this?

In the long term, that's probably the only way to have good HCL coverage...

joanna.

[Daniel Selifonov]

Joanna:
That's fine -- I brought up the solution I came up so the others
having issues on similar hardware have a route to a working install. I
don't think there's much else to say on this particular problem.

With regards to allowing installation from/of alternate kernel
versions, I'd like to hope that flaws of the severity as this Intel
GPU regression are the rare exception, rather than the rule in new
Linux kernels. It's hard to predict what hardware might interact badly
with what software versions, so I think effort would be better spent
in making sure there are working fallback methods for installation,
like text mode anaconda. In this contingency, if a user can get the
system installed, and if they have a working NetVM (which I understand
currently requires X on first bootup), then trying different kernel
versions or other diagnosis procedures would relatively easy.

The biggest problem was that there was no graceful response to
failure, and I had to resort to building my own installation media to
move forward at all.

I'm totally unfamiliar with configuring anaconda for system
installation, and the build process for RPM distros. So, I don't think
I would be very helpful here until I have a better understanding of
the Qubes build process.

But, I will be studying the Qubes codebase this summer. When I'll be
able to make a meaningful contribution, I'll let you know.

Regards,
-Daniel Selifonov

[dcampm...@gmail.com]

I have a thinkpad x230 , and im having a hard time installing also.  I had to use the text based installer but ended up getting the error "luks device has no key/passphrase"  I'm working with R2 but trying to get a grasp on building a new iso with alternate kernel choices is a first for me :/

I can attach a screen shot fwiw

[Axon]

Sounds like an Anaconda problem, which may be due to graphics
incompatibility. Others have reported similar things, and AFAIK it's not
Qubes-specific, so more helpful info may be available by searching upstream.

(This should be in qubes-users, IMO.)