HCL: Thinkpad T410

178 views
Skip to first unread message

Vincent Penquerc'h

unread,
Mar 15, 2014, 6:07:26 PM3/15/14
to qubes...@googlegroups.com
It seems to be working fine now, modulo having to use kernel 3.9.

I had trouble at start with 3.11 messing up display here (it looks as if
display was planar displayed as linear, I could read some of the text,
but not all). 3.9 works fine.

LUKS creation failed till I realized I was pressing the wrong button
("Done" instead of "Continue"), though this is probably an Anaconda
thing rather than Qubes.

I just had a failure to run a terminal in an AppVM, due to qrexec-daemon
failing to launch. Logs in the AppVM show:

[ 4.475] (II) config/udev: Adding input device PC Speaker
(/dev/input/event0)
[ 4.475] (II) No input driver specified, ignoring this device.
[ 4.475] (II) This device may have been added with another device file.
(EE) BUG: triggered 'if (inSignalContext)'
(EE) BUG: log.c:484 in LogVMessageVerb()
(EE) Warning: attempting to log data in a signal unsafe manner while in
signal context.
Please update to check inSignalContext and/or use
LogMessageVerbSigSafe() or ErrorFSigSafe().
The offending log format message is:
randdev: unix closed

(EE)
(EE) Backtrace:
(EE) 0: /usr/bin/Xorg (LogVMessageVerb+0x195) [0x4709f5]
(EE) 1: /usr/bin/Xorg (xf86Msg+0x8f) [0x496a3f]
(EE) 2: /usr/lib64/xorg/modules/drivers/qubes_drv.so (?+0x8f)
[0x7f4ab1a075af]
(EE) 3: /usr/bin/Xorg (DPMSSupported+0x1d7) [0x489f67]
(EE) 4: /usr/bin/Xorg (xf86SerialModemClearBits+0x238) [0x4b35a8]
(EE) 5: /lib64/libpthread.so.0 (__restore_rt+0x0) [0x7f4ab6e3efff]
(EE) 6: /lib64/libc.so.6 (__select_nocancel+0x2a) [0x7f4ab595385a]
(EE) 7: /usr/bin/Xorg (WaitForSomething+0x190) [0x469f00]
(EE) 8: /usr/bin/Xorg (SendErrorToClient+0xe1) [0x4395d1]
(EE) 9: /usr/bin/Xorg (_init+0x3a7a) [0x42b98a]
(EE) 10: /lib64/libc.so.6 (__libc_start_main+0xf5) [0x7f4ab5889a05]
(EE) 11: /usr/bin/Xorg (_start+0x29) [0x428621]
(EE)
(II) randdev: unix closed
[ 1749.084] (II) qubesdev: Off.
[ 1749.158] (II) UnloadModule: "qubes"
[ 1749.270] Server terminated successfully (0). Closing log file.

I can't copy paste the AppVM logs since I restarted it and the logs went
away, but it did read something along the lines of: "pacat exited with
code 256. Error 11, resource temporarily unavailable" after 19000
tries". Not sure it was "tries", so not sure if that's a failing op
repeated 19k times, or the count of syscalls/X calls. The VM was not
running when I started the terminal.

This might already be fixed. I updated dom0 and template/AppVMs but I've
not added the testing repo yet. I've requested a terminal again (after
killing the VM, as it would not shutdown), and it worked fine. It would
make sense if it was a normal EAGAIN I suppose.


Qubes-HCL-LENOVO-2516CTO-20140315.txt

Vincent Penquerc'h

unread,
Mar 15, 2014, 6:20:08 PM3/15/14
to qubes...@googlegroups.com

On 03/15/14 22:07, Vincent Penquerc'h wrote:
> I had trouble at start with 3.11 messing up display here (it looks as
> if display was planar displayed as linear, I could read some of the
> text, but not all). 3.9 works fine.

I should add: that planar/linear thing stopped when X started. At that
point, blank screen, and no VTs available (or it crashed altogether).
Monkeying around, it seems 3.11 does not create a /dev/fb0 device for
the vesa driver to use, though the FB config is set to /proc/config.gz.

On the Anaconda text version, one is never asked for the LUKS
passphrase, which had me stumped for a while trying to get around that
(I got the text version by trying xdriver=vga, a driver that turns out
not to exist). The web says this is an Anaconda bug that's meant to be
fixed in .26, though Qubes seems to be using .37 (IIRC), so something a
bit fishy here maybe.

cprise

unread,
Mar 15, 2014, 10:32:57 PM3/15/14
to Vincent Penquerc'h, qubes...@googlegroups.com

On 03/15/14 18:07, Vincent Penquerc'h wrote:
> It seems to be working fine now, modulo having to use kernel 3.9.

Check to see how Firefox runs with large web pages. I found having 3.9
running dom0 caused Firefox to slow down and lurch a lot, and that's why
I'm running 3.7.4 as an alternative to 3.11.


Vincent Penquerc'h

unread,
Mar 16, 2014, 10:30:47 AM3/16/14
to cprise, qubes...@googlegroups.com
It doesn't seem to be outrageously slow to use, though it goes to 99%
CPU. With Firefox, it might not be that unexpected.

BTW, while dom0 runs 3.9, the AppVMs run 3.11. I'm not sure why that is.
It is the only kernel present in /var/lib/qubes/vm-kernels. Installing
the kernel with the right version seems to install it in dom0 /boot, but
not in the VM kernels list so I can't test/compare 3.11 vs 3.7 until I
find the right incantation.


Marek Marczykowski-Górecki

unread,
Mar 16, 2014, 10:33:46 AM3/16/14
to Vincent Penquerc'h, cprise, qubes...@googlegroups.com
VM kernel is in kernel-qubes-vm package.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

signature.asc

Vincent Penquerc'h

unread,
Mar 16, 2014, 10:52:33 AM3/16/14
to qubes...@googlegroups.com
On 03/16/14 14:33, Marek Marczykowski-Górecki wrote:
>
> VM kernel is in kernel-qubes-vm package.
>

Yes, I have the 3.11 version of it. I did find a previous thread with
attempts at yum install/downgrade kernel-qubes-vm-3.9*, but those don't
help here (nor did they in that thread). The last rpm command which did
work in the thread doesn't here, as I don't have such a file in my rpm
tree already.

yum list kernel-qubes-vm only shows 3.11, and the man page says this
list "available" packages (though it does print "Installed"). I'm not
familiar with yum to know if it's just that it list an empty set of
"uninstalled" packages.

Vincent Penquerc'h

unread,
Mar 16, 2014, 12:28:18 PM3/16/14
to qubes...@googlegroups.com
On 03/16/14 14:52, Vincent Penquerc'h wrote:

> yum list kernel-qubes-vm only shows 3.11, and the man page says this
> list "available" packages (though it does print "Installed"). I'm not
> familiar with yum to know if it's just that it list an empty set of
> "uninstalled" packages.

FWIW, yum list all | grep kernel shows all three for kernel.x86_64 but
only 3.11 for kernel-qubes-vm.x86_64. I see the relevant rpm files on
yum.qubes-os.org though.

Also, this finds the right package:
yum provides /var/lib/qubes/vm-kernels/3.11.1-2/vmlinuz
But this finds nothing:
yum provides /var/lib/qubes/vm-kernels/3.7.4-5/vmlinuz
Not found for the 3.9.2-2 one either.

Something odd: in /etc/yum.real.repos.d/qubes-cached.repo, I have gpgkey
pointing to file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-1-primary, but I
have no such file. I have the same with s/1/2/ though (changing it to
that didn't help see the other kernels though). I'm not sure why nothing
moaned when I updated dom0 earlier. Is that actually old and unused ?

Marek Marczykowski-Górecki

unread,
Mar 16, 2014, 3:00:01 PM3/16/14
to Vincent Penquerc'h, qubes...@googlegroups.com
On 16.03.2014 17:28, Vincent Penquerc'h wrote:
> On 03/16/14 14:52, Vincent Penquerc'h wrote:
>
>> yum list kernel-qubes-vm only shows 3.11, and the man page says this
>> list "available" packages (though it does print "Installed"). I'm not
>> familiar with yum to know if it's just that it list an empty set of
>> "uninstalled" packages.
>
> FWIW, yum list all | grep kernel shows all three for kernel.x86_64 but only
> 3.11 for kernel-qubes-vm.x86_64. I see the relevant rpm files on
> yum.qubes-os.org though.
>
> Also, this finds the right package:
> yum provides /var/lib/qubes/vm-kernels/3.11.1-2/vmlinuz
> But this finds nothing:
> yum provides /var/lib/qubes/vm-kernels/3.7.4-5/vmlinuz
> Not found for the 3.9.2-2 one either.

Yum in dom0 doesn't have direct access to repository (so search, list etc
commands do not show meaningful results). qubes-dom0-update downloads
requested packages and hand it over to yum.

> Something odd: in /etc/yum.real.repos.d/qubes-cached.repo, I have gpgkey
> pointing to file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-1-primary, but I have no
> such file. I have the same with s/1/2/ though (changing it to that didn't help
> see the other kernels though). I'm not sure why nothing moaned when I updated
> dom0 earlier. Is that actually old and unused ?

Indeed this is a bug... But the key is imported during installation - this is
why no error was reported.
signature.asc
Reply all
Reply to author
Forward
0 new messages