HCL - Thinkpad T430s works with Qubes 2b1

987 views
Skip to first unread message

cprise

unread,
Feb 12, 2013, 7:07:42 PM2/12/13
to qubes...@googlegroups.com
Hello...

Intel HD4000 (Optimus present but turned off in BIOS)
i5-3320M Ivy Bridge (supports VT-x and VT-d, turned on in BIOS)
QM77 chipset
BIOS version 2.05

Other: TPM, vPro, WLAN Centrino 6300 Ultimate, Samsung 840 Pro SSD, 1600x900 screen, finger scanner

Notes:

Everything except bluetooth works at least on a basic level, but I don't see any indication from Qubes that the hardware virty features are being employed. Is there a way to tell?

I haven't tested the webcam and mic, so I'll get back with an update after trying them.

Keyboards (internal and external) are OK, but the default key repeat setting is far too quick sometimes giving the impression of a key bounce problem (extra copies of a character are produced). Ext keyboard is a PS/2 via a USB adapter and then a USB hub: this works fine in Grub and at all runlevels.

Key layout is a different story: I use Colemak and Qubes doesn't let me switch to it in some situations, even though Colemak is built-in. I believe the same holds true for Dvorak. NetVM does not take the control panel layout setting, nor does the bare Linux console (which in Debian distros at least, can be setup for alternate layouts with a couple of commands). There seems to be no way to get the layout set for the console in either Qubes or Fedora. Lastly, as another Thinkpad user stated, special function keys like Lock and Sleep do not work, nor does the mic mute button (which seems important). In Dom0 and AppVMs the layout setting seems to work with the caveat that setting the Caps Lock key to work as Backspace in the control panel works in only a non-repeating fashion; I must tap the key for each character I want to erase. I don't recall this being a problem in Ubuntu or CentOS. These distros, along with OS X, try to remember a user's keyboard layout (once a non-defualt one has been activated) at the login screen and they have icons there that allow changing the layout.

Mice have no problems, but the internal pointing devices are lacking a bit. There is no way to adjust the Trackpoint from the control panel. Worse, the trackpad's speed cannot be adjusted from the control panel -- which is odd because it can be adjusted in several other ways. As it is, the trackpad seems too slow whereas in Windows it was fine. Also, the trackpad tapping defaults are bad: Tapping is 'enabled' by default but infuriatingly won't produce any clicks when tapping. The cause of the problem is slightly hidden under the Tapping/Buttons section where you must click on each desired action in the left column which then shows in the right column that they (one finger, two finger, etc) are all set to "None". At this point its simple to rectify the settings, but the defaults as they are don't make sense.

The trackpad remains active when the Trackpoint is being used and this can't be changed in the control panel.

Mouse pointer "cues" (the symbols for "busy" and the hyperlink hand) do not appear. Not having the hyperlink hand appear over links is very disconcerting while browsing the web.

Dual displays basically work with the internal screen plus one 1080p DVI. However, the management of the settings and other aspects of the arrangement are somewhat broken. For instance, I cannot disable the internal screen: sometimes it refuses to take the setting, other times it seems to "disable" the screen by shutting the backlight off while still putting important dialogue boxes there (e.g. password for unlocking the session). Also, when a display is plugged in during a session, the running AppVMs do not fully understand this and some apps like Firefox cannot sense mouse activity everywhere on the larger screen -- hovers and clicks in the far right and bottom of web pages will either not be sensed or misread as the wrong coordinates. (Firefox has no problem expanding into and displaying content in the larger space, however.) The AppVM must be restarted manually while the additional display is connected in order for the coordinate anomalies to disappear.

No problems have been detected with performance or thermal management, although the settings for controlling related features is rather impoverished. I remain wary on this subject because Fedora in the past has overheated a couple of 2007 vintage Macbooks where other Linux distros performed responsibly. I generally consider Fedora terrible for laptops.

Qubes VM Manager is working very well for its intended purpose so far. The only problems with it are that the keyboard layout selector only deals with languages and not specific layouts (hence Colemak and Dvorak cannot be selected) and it sometimes prompts me to Kill a VM after I have told it to shut the VM down (and then it does shut down as expected) and then I start the VM again less than 20 seconds after. Manager thinks the original instance of the VM never did shut down. The dialogue that appears only lets me 'Kill' or "Wait 20 seconds more", neither of which are good choices in this scenario; I can't simply dismiss it.

Some added Audio lag is noticeable when watching videos of people speaking. There is also a very slight breakup that can be heard in the audio stream, though I am able to mentally tune it out thus far. As for the lag, which all devices add to the process, media apps already compensate for the lag of native sound chips under normal circumstances... So I wonder if its possible to add to the number of milliseconds that the sound system is already telling the media app to take into account during playback.

The usual CPU meters are very inaccurate in Qubes. Its possible to see a VM in the Manager using a lot of CPU, but hardly anything shows up in the system monitor. I would like a way to easily read the entire CPU load in one place. I would also like (similar to Windows 7) a way to view network load and disk load listed by process (one can always wish).

One other thing that concerned me was the way a disposable VM Firefox keeps announcing itself to the Internet via the Qubes and Fedora startup pages. How can I change the Firefox startup to avoid this... run FF in the Template VM and change the prefs there?

That's all for now and thanks for creating Qubes. :)

Marek Marczykowski

unread,
Feb 12, 2013, 9:37:36 PM2/12/13
to qubes...@googlegroups.com, cprise
On 13.02.2013 01:07, cprise wrote:
> Hello...
>
> Intel HD4000 (Optimus present but turned off in BIOS)
> i5-3320M Ivy Bridge (supports VT-x and VT-d, turned on in BIOS)
> QM77 chipset
> BIOS version 2.05
>
> Other: TPM, vPro, WLAN Centrino 6300 Ultimate, Samsung 840 Pro SSD,
> 1600x900 screen, finger scanner
>
> Notes:
>
> Everything except bluetooth works at least on a basic level, but I don't
> see any indication from Qubes that the hardware virty features are being
> employed. Is there a way to tell?

"xl info" in dom0 console. You should have "hvm" (for VT-x) and "hvm_directio"
(for VT-d) in virt_caps field.

> I haven't tested the webcam and mic, so I'll get back with an update after
> trying them.
>
> Keyboards (internal and external) are OK, but the default key repeat
> setting is far too quick sometimes giving the impression of a key bounce
> problem (extra copies of a character are produced). Ext keyboard is a PS/2
> via a USB adapter and then a USB hub: this works fine in Grub and at all
> runlevels.
>
> Key layout is a different story: I use Colemak and Qubes doesn't let me
> switch to it in some situations, even though Colemak is built-in. I believe
> the same holds true for Dvorak. NetVM does not take the control panel
> layout setting, nor does the bare Linux console (which in Debian distros at
> least, can be setup for alternate layouts with a couple of commands). There
> seems to be no way to get the layout set for the console in either Qubes or
> Fedora.

Not sure about Linux console (check /etc/sysconfig/keyboard in dom0), but in
VM keyboard layout should be propagated from Dom0 at VM startup. So you need
to reboot VM after layout change to have it applied. I see currently some
problems when multiple layout are chosen (only the first one is working), so
ensure you have only one layout.

You can also set per-VM layout from Qubes Manager - when done, this VM will
ignore further Dom0 layout changes.

> Lastly, as another Thinkpad user stated, special function keys like
> Lock and Sleep do not work, nor does the mic mute button (which seems
> important).
>
> In Dom0 and AppVMs the layout setting seems to work with the
> caveat that setting the Caps Lock key to work as Backspace in the control
> panel works in only a non-repeating fashion; I must tap the key for each
> character I want to erase. I don't recall this being a problem in Ubuntu or
> CentOS.

I think it is KDE bug. Anyway you can set it manually:
http://pthree.org/2007/03/06/switching-caps-lock-and-backspace/

> These distros, along with OS X, try to remember a user's keyboard
> layout (once a non-defualt one has been activated) at the login screen and
> they have icons there that allow changing the layout.

AFAIR only GDM supports that, but we use KDM (and perhaps will switch to
LightDM in the future).
Anyway Qubes isn't intended to be multi-user system, so I see no reason to
have keyboard layout chooser at login screen; setting it system-wide should be
enough.

> Mice have no problems, but the internal pointing devices are lacking a bit.
> There is no way to adjust the Trackpoint from the control panel. Worse, the
> trackpad's speed cannot be adjusted from the control panel -- which is odd
> because it can be adjusted in several other ways. As it is, the trackpad
> seems too slow whereas in Windows it was fine. Also, the trackpad tapping
> defaults are bad: Tapping is 'enabled' by default but infuriatingly won't
> produce any clicks when tapping. The cause of the problem is slightly
> hidden under the Tapping/Buttons section where you must click on each
> desired action in the left column which then shows in the right column that
> they (one finger, two finger, etc) are all set to "None". At this point its
> simple to rectify the settings, but the defaults as they are don't make
> sense.

Looks like KDE (or kde-settings) bug. Anyway I'm preparing Fedora 18 based
dom0 with KDE 4.9, which hopefully will fix many problems like this (and
introduce new ones...).

> The trackpad remains active when the Trackpoint is being used and this
> can't be changed in the control panel.

What exactly do you want to achieve? Some automatic touchpad disable? Or just
Fn-F8 (or sth) to disable touchpad working?

> Mouse pointer "cues" (the symbols for "busy" and the hyperlink hand) do not
> appear. Not having the hyperlink hand appear over links is very
> disconcerting while browsing the web.

This is by design, to keep GUI protocol as simple as possible.

> Dual displays basically work with the internal screen plus one 1080p DVI.
> However, the management of the settings and other aspects of the
> arrangement are somewhat broken. For instance, I cannot disable the
> internal screen: sometimes it refuses to take the setting, other times it
> seems to "disable" the screen by shutting the backlight off while still
> putting important dialogue boxes there (e.g. password for unlocking the
> session).

Strange, do you have something in /var/log/Xorg.0.log? Does it happens on
other systems (especially baremetal Fedora)?

> Also, when a display is plugged in during a session, the running
> AppVMs do not fully understand this and some apps like Firefox cannot sense
> mouse activity everywhere on the larger screen -- hovers and clicks in the
> far right and bottom of web pages will either not be sensed or misread as
> the wrong coordinates. (Firefox has no problem expanding into and
> displaying content in the larger space, however.) The AppVM must be
> restarted manually while the additional display is connected in order for
> the coordinate anomalies to disappear.

I know, this is annoying. This is because VM only get screen layout at
startup, I haven't found any way to update it (xrandr doesn't look supported
by Xorg dummy driver).
I have this on my todo list, but low priority.

> No problems have been detected with performance or thermal management,
> although the settings for controlling related features is rather
> impoverished. I remain wary on this subject because Fedora in the past has
> overheated a couple of 2007 vintage Macbooks where other Linux distros
> performed responsibly. I generally consider Fedora terrible for laptops.
>
> Qubes VM Manager is working very well for its intended purpose so far. The
> only problems with it are that the keyboard layout selector only deals with
> languages and not specific layouts (hence Colemak and Dvorak cannot be
> selected)

Patches welcomed :)

> and it sometimes prompts me to Kill a VM after I have told it to
> shut the VM down (and then it does shut down as expected) and then I start
> the VM again less than 20 seconds after. Manager thinks the original
> instance of the VM never did shut down. The dialogue that appears only lets
> me 'Kill' or "Wait 20 seconds more", neither of which are good choices in
> this scenario; I can't simply dismiss it.

This is already fixed in my git repo, will be in the next version.

> Some added Audio lag is noticeable when watching videos of people speaking.
> There is also a very slight breakup that can be heard in the audio stream,
> though I am able to mentally tune it out thus far. As for the lag, which
> all devices add to the process, media apps already compensate for the lag
> of native sound chips under normal circumstances... So I wonder if its
> possible to add to the number of milliseconds that the sound system is
> already telling the media app to take into account during playback.

Maybe... Currently audio is sent as raw samples, without any metadata (for
security reasons - to keep it as simple as possible), so it would be hard to
measure delay. But perhaps some constant will do the work. You can experiment,
the relevant code is here:
http://git.qubes-os.org/gitweb/?p=marmarek/gui.git;a=tree;f=pulse

> The usual CPU meters are very inaccurate in Qubes. Its possible to see a VM
> in the Manager using a lot of CPU, but hardly anything shows up in the
> system monitor. I would like a way to easily read the entire CPU load in
> one place. I would also like (similar to Windows 7) a way to view network
> load and disk load listed by process (one can always wish).

System monitor (and such tools) shows you only dom0 resources usage, it
doesn't support monitoring of other VMs. Currently only Qubes Manager and
"xentop" can show you all VMs data.
I'm not aware of any other software capable of showing Xen VMs stats. Do you?

> One other thing that concerned me was the way a disposable VM Firefox keeps
> announcing itself to the Internet via the Qubes and Fedora startup pages.
> How can I change the Firefox startup to avoid this... run FF in the
> Template VM and change the prefs there?

http://wiki.qubes-os.org/trac/wiki/UserDoc/DispVMCustomization

> That's all for now and thanks for creating Qubes. :)

Thanks for thorough report :)

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

signature.asc

cprise

unread,
Feb 14, 2013, 10:14:31 PM2/14/13
to qubes...@googlegroups.com, cprise


On Tuesday, February 12, 2013 9:37:36 PM UTC-5, Marek Marczykowski wrote:
...

"xl info" in dom0 console. You should have "hvm" (for VT-x) and "hvm_directio" 
(for VT-d) in virt_caps field. 

OK, they are both present.
 
Not sure about Linux console (check /etc/sysconfig/keyboard in dom0), but in 
VM keyboard layout should be propagated from Dom0 at VM startup. So you need 
to reboot VM after layout change to have it applied. I see currently some 
problems when multiple layout are chosen (only the first one is working), so 
ensure you have only one layout. 

It was NetVM not taking the layout setting, as I had to use Qwerty to enter Wifi passwords. But I checked again and NetVM is using Colemak for both the networkmanager and the terminal. I think this was fixed by the updates.

Its just the bare console I have an issue with now, and that seems to be a Fedora problem. I would just like to adopt Qubes knowing I can go to RL1 or 3 without losing the layout, but its not critical for me.

> Worse, the 
> trackpad's speed cannot be adjusted from the control panel -- which is odd 
> because it can be adjusted in several other ways. As it is, the trackpad 
> seems too slow whereas in Windows it was fine. Also, the trackpad tapping 
> defaults are bad: Tapping is 'enabled' by default but infuriatingly won't 
> produce any clicks when tapping. The cause of the problem is slightly 
> hidden under the Tapping/Buttons section where you must click on each 
> desired action in the left column which then shows in the right column that 
> they (one finger, two finger, etc) are all set to "None". At this point its 
> simple to rectify the settings, but the defaults as they are don't make 
> sense. 

Looks like KDE (or kde-settings) bug. Anyway I'm preparing Fedora 18 based 
dom0 with KDE 4.9, which hopefully will fix many problems like this (and 
introduce new ones...). 
 
About the "slowness"... Spending a bit more time with it I realized its something worse. The DPI is distorted so that the Y axis yields half the cursor movement that the X axis does. I have to keep switching to the Trackpoint or a mouse. This flaw is bad.

Ubuntu 12.04 Live gets the tracking on the touchpad perfect.


> The trackpad remains active when the Trackpoint is being used and this 
> can't be changed in the control panel. 

What exactly do you want to achieve? Some automatic touchpad disable? Or just 
Fn-F8 (or sth) to disable touchpad working? 

Automatic disable is the expected behavior, but to be honest it isn't interfering with my use. Newer Thinkpad models are coming out with much larger touchpads, so that may be different for other people in future.
 
> Mouse pointer "cues" (the symbols for "busy" and the hyperlink hand) do not 
> appear. Not having the hyperlink hand appear over links is very 
> disconcerting while browsing the web. 

This is by design, to keep GUI protocol as simple as possible. 


This deserves its own topic, as it goes beyond shuffling features in the window manager or desktop layers.

 
> Dual displays basically work with the internal screen plus one 1080p DVI. 
> However, the management of the settings and other aspects of the 
> arrangement are somewhat broken. For instance, I cannot disable the 
> internal screen: sometimes it refuses to take the setting, other times it 
> seems to "disable" the screen by shutting the backlight off while still 
> putting important dialogue boxes there (e.g. password for unlocking the 
> session). 

Strange, do you have something in /var/log/Xorg.0.log? Does it happens on 
other systems (especially baremetal Fedora)? 

There seems to be no good way to get the logfile from Dom0. I checked the Qubes user guide and I guess I can only copy between AppVMs. Perhaps later when I get a chance I can use Ubuntu Live to unlock the Qubes partition and copy it that way. I can tell you already it seems pretty uninteresting-- didn't notice any errors or big omissions.

My initial report was before I did any updating. Now that I've updated both the VM and the template, the behavior is a little better and I can't get it put a password prompt on a disabled screen again. However there is still a lot of misbehavior: It forgets that I disabled the laptop screen when rebooting -- It doesn't matter if the lid is closed or not, although having the lid closed while booting can result in the laptop screen having a really fubar'ed display.

I don't have a recent Fedora handy to test, but with Ubuntu 12.04 Live USB the screen handling works near perfect. The only complaint I have about Ubuntu here is that it acts a little like Qubes when I close the laptop screen, everything goes dark but the system remains running. *IF* I do this after I have disabled the laptop screen, I can reactivate the external screen just by touching the USB keyboard or mouse; If the laptop screen is still on when I close the lid, the system is unresponsive until I open the lid again.

BTW, when I close the lid on Qubes it makes the "going to sleep" sound but never goes to sleep (the ext. screen goes black until I hit a key). If I tell it to sleep from the KDE menu, it makes the same sound but does go to sleep. It behaves this way whether or not there is an external display. However, this allows me to continue using the laptop with the lid closed as if it were docked.

If I have the lid open and disconnect the external screen, the laptop screen stays dark. It would be nice if I could just hook up the external USB and display and close the lid and have the system deal with the use case appropriately.

Also noticed when I have the extra screen NetVM's systray icon often stops responding and it puts an extra copy of itself near the middle of the laptop screen (the task panel/systray go to the external screen when its connected). If I click on the extra copy, it disappears, but the one in the systray doesn't come back to life.

Also, if I put the system to sleep, then disconnect the external display then wake it from sleep, the VM Manager is off-screen and the mouse pointer is still able to move offscreen into the area 'above' the laptop screen. Otherwise the laptop screen looks normal and the taskbar panel has moved to that display.

Finally (because I won't spend much more time struggling with chaotic multiple displays, at least until the next beta) I noticed Firefox and the AppVM itself have problems when I've got them on the extra display for a while. Sometimes the AppVM won't start and Manager just shows a yellow dot in the status column. Then I stop it, then restart it with Firefox. Then I move Firefox to the laptop screen so it can deal with the dimensions. Then when I start typing a URL Firefox's 'wonderbar' list shows up in the middle of the external screen, and the menus for the Extensions I have on the (bottom) status bar either won't show or appear mostly off-screen to the lower-right. Firefox usually stops responding soon after.

...

I know, this is annoying. This is because VM only get screen layout at 
startup, I haven't found any way to update it (xrandr doesn't look supported 
by Xorg dummy driver). 
I have this on my todo list, but low priority. 
 
This makes running apps on a second screen risky-- could easily activate the wrong functions, links, etc. If you can't prevent the apps from sizing beyond the original dimensions as a quick fix, it may be best to disable multi-screen support in the meantime.


System monitor (and such tools) shows you only dom0 resources usage, it 
doesn't support monitoring of other VMs. Currently only Qubes Manager and 
"xentop" can show you all VMs data. 
I'm not aware of any other software capable of showing Xen VMs stats. Do you? 

This is my first experience with Xen, so no... I would have assumed that Xen aggregate the CPU stats. Maybe that would be a good function to have in the VM Manager.
 

Abel Luck

unread,
Feb 15, 2013, 3:37:38 AM2/15/13
to qubes...@googlegroups.com
Marek Marczykowski:
> On 13.02.2013 01:07, cprise wrote:
>> Hello...
>>
>> Intel HD4000 (Optimus present but turned off in BIOS)
>> i5-3320M Ivy Bridge (supports VT-x and VT-d, turned on in BIOS)
>> QM77 chipset
>> BIOS version 2.05
>>
>> Other: TPM, vPro, WLAN Centrino 6300 Ultimate, Samsung 840 Pro SSD,
>> 1600x900 screen, finger scanner
>>
>> Notes:
>>
>> Everything except bluetooth works at least on a basic level, but I don't
>> see any indication from Qubes that the hardware virty features are being
>> employed. Is there a way to tell?
>
> "xl info" in dom0 console. You should have "hvm" (for VT-x) and "hvm_directio"
> (for VT-d) in virt_caps field.
>
I've a t430s, and I only have 'hvm' for virt_caps.

VT-d is enabled in the bios, any tips on debugging this?

Hakisho Nukama

unread,
Feb 15, 2013, 4:12:00 AM2/15/13
to qubes...@googlegroups.com, cprise
Hey,

you can cat-pipe documents to qvm-run --pass-io described in [1]

Best Regards,
Hakisho Nukama

[1] https://www.qubes-os.org/trac/wiki/CopyToDomZero
> --
> You received this message because you are subscribed to the Google Groups
> "qubes-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to qubes-devel...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

bradbury9

unread,
Feb 15, 2013, 5:09:23 AM2/15/13
to qubes...@googlegroups.com, cprise


El miércoles, 13 de febrero de 2013 03:37:36 UTC+1, Marek Marczykowski escribió:
On 13.02.2013 01:07, cprise wrote:
> Hello...
>
> Intel HD4000 (Optimus present but turned off in BIOS)
> i5-3320M Ivy Bridge (supports VT-x and VT-d, turned on in BIOS)
> QM77 chipset
> BIOS version 2.05
>
> Other: TPM, vPro, WLAN Centrino 6300 Ultimate, Samsung 840 Pro SSD,
> 1600x900 screen, finger scanner
>
> Notes:
>
> Everything except bluetooth works at least on a basic level, but I don't
> see any indication from Qubes that the hardware virty features are being
> employed. Is there a way to tell?

"xl info" in dom0 console. You should have "hvm" (for VT-x) and "hvm_directio"
(for VT-d) in virt_caps field.


I will test my new desktop computer whose main purpose will be gaming. I was searching in the mailing list for this info because didnt find it in the wiki so I can upload the results of the tests to the mailng list and get the info into the HCL. Already installed Qubes, with just some minor BIOS changes (gaming specific).

Maybe it should be noted this command in the HCL page or in the wiki? Maybe add also other commands for the HCL (Standard feautures checklists)
 

cprise

unread,
Feb 15, 2013, 11:58:16 AM2/15/13
to qubes...@googlegroups.com
On 2/15/13 3:37 AM, Abel Luck wrote:
> Marek Marczykowski
>> "xl info" in dom0 console. You should have "hvm" (for VT-x) and "hvm_directio"
>> (for VT-d) in virt_caps field.
>>
> I've a t430s, and I only have 'hvm' for virt_caps.
>
> VT-d is enabled in the bios, any tips on debugging this?
Make sure your model doesn't have the the i5-3210M processor. That one
doesn't support some virtual features.
http://ark.intel.com/products/67355/Intel-Core-i5-3210M-Processor-3M-Cache-up-to-3_10-GHz-rPGA

Also, update the VM (dom0) and make sure you have the same version BIOS
as me (2.05).

cprise

unread,
Feb 15, 2013, 1:30:52 PM2/15/13
to qubes...@googlegroups.com

On 2/14/13 10:14 PM, cprise wrote:
> About the "slowness"... Spending a bit more time with it I realized
> its something worse. The DPI is distorted so that the Y axis yields
> half the cursor movement that the X axis does. I have to keep
> switching to the Trackpoint or a mouse. This flaw is bad.
>
>

Update on the touchpad: When I first boot the system, at the login
screen the X&Y DPI seem good and proportional. Then when I login it is
distorted. THEN (interesting part) when I plug in external display the
DPI is good once again.

The login process is messing up the touchpad settings, I think.


cprise

unread,
Feb 15, 2013, 5:08:57 PM2/15/13
to qubes...@googlegroups.com, cprise
Thanks Hakisho!

Marek, I can't attach a file here in the web interface (an error results when I try to post). I'm trying to copy the file from Personal to a USB stick so I can send it from Thunderbird. I used Manager to attach the stick to Personal, but nothing is showing up in Personal nautilus except under 'Computer'-- clicking on the stick there results in error dialog "Unable to mount location. Can't mount file."

Marek Marczykowski

unread,
Feb 15, 2013, 6:05:47 PM2/15/13
to qubes...@googlegroups.com, cprise
Does your UST stick have partition table, or just filesystem from the
beginning of the device? In the later case nautilus doesn't support mounting
it and must be mounted from VM cmdline.
signature.asc

cprise

unread,
Feb 16, 2013, 5:57:24 AM2/16/13
to qubes...@googlegroups.com
On 2/15/13 6:05 PM, Marek Marczykowski wrote
> Does your UST stick have partition table, or just filesystem from the
> beginning of the device? In the later case nautilus doesn't support mounting
> it and must be mounted from VM cmdline.
>

That was it. Here is the Xorg log...

Xorg.0.log.bz2

cprise

unread,
Feb 16, 2013, 11:47:24 AM2/16/13
to qubes...@googlegroups.com

I reset my router earlier this AM and just now turned to my Thinkpad to
find 18 netvm dialog boxes tiling my screen saying "Authentication
required by wireless network". For each box it seems to have selected
the next available access point in its list, round-robing style. I guess
it stopped at 18 because it eventually found my router again and
reconnected.

Earlier in the session the Netvm and Personal VMs forgot my keyboard
mapping-- Reverting to Qwerty layout even though I had removed that
layout days ago in the KDE settings (leaving only Colemak). I don't know
what triggered it; I did mount a USB stick several times, created an HVM
then deleted it without running it, expanded the allowed disk space on
HVM and the Personal VM, and put the system to sleep a couple different
times. I did not plug in a second monitor. Untrusted was running all
this time but it (and Dom0) retained my intended keymap.

Ended up using a second HVM for Windows and ran into some limitations:
Can't do Ctrl-Alt-Del; Telling Windows to restart causes the VM to
simply shut down; Can't force HVM to halt... VM Manager says ERROR
command /usr/sbin/xl, shutdown, windows returned exit status 255.

Hope these reports are helpful in some way...

Marek Marczykowski

unread,
Feb 16, 2013, 2:18:26 PM2/16/13
to qubes...@googlegroups.com, cprise
On 16.02.2013 17:47, cprise wrote:
>
> I reset my router earlier this AM and just now turned to my Thinkpad to
> find 18 netvm dialog boxes tiling my screen saying "Authentication
> required by wireless network". For each box it seems to have selected
> the next available access point in its list, round-robing style. I guess
> it stopped at 18 because it eventually found my router again and
> reconnected.

Looks independent of Qubes, perhaps you should report it to Fedora or GNOME
(this is GNOME NetworkManager applet).

> Earlier in the session the Netvm and Personal VMs forgot my keyboard
> mapping-- Reverting to Qwerty layout even though I had removed that
> layout days ago in the KDE settings (leaving only Colemak). I don't know
> what triggered it; I did mount a USB stick several times, created an HVM
> then deleted it without running it, expanded the allowed disk space on
> HVM and the Personal VM, and put the system to sleep a couple different
> times. I did not plug in a second monitor. Untrusted was running all
> this time but it (and Dom0) retained my intended keymap.

Strange... Check 'setxkbmap -print' output next time.

> Ended up using a second HVM for Windows and ran into some limitations:
> Can't do Ctrl-Alt-Del;

I know, maybe will add some other shortcut remapped to Ctrl-Alt-Del. I though
of Ctrl-Alt-Ins, but this can conflict with RDP client. Any other ideas?

> Telling Windows to restart causes the VM to
> simply shut down;

Yes, this is know behavior (because of xen toolstack architecture) and
probably will not be changed.

> Can't force HVM to halt... VM Manager says ERROR
> command /usr/sbin/xl, shutdown, windows returned exit status 255.

Clean shutdown from VM Manager will be working when you install qubes tools
inside your HVM. Without this you can only shutdown HVM from inside, or kill
it (context menu on VM in manager or qvm-kill command).

> Hope these reports are helpful in some way...


signature.asc
Message has been deleted

cprise

unread,
Feb 17, 2013, 12:13:36 PM2/17/13
to qubes...@googlegroups.com

On 2/16/13 2:18 PM, Marek Marczykowski wrote:
> On 16.02.2013 17:47, cprise wrote:
>> Earlier in the session the Netvm and Personal VMs forgot my keyboard
>> mapping-- Reverting to Qwerty layout even though I had removed that
>> layout days ago in the KDE settings (leaving only Colemak). I don't know
>> what triggered it; I did mount a USB stick several times, created an HVM
>> then deleted it without running it, expanded the allowed disk space on
>> HVM and the Personal VM, and put the system to sleep a couple different
>> times. I did not plug in a second monitor. Untrusted was running all
>> this time but it (and Dom0) retained my intended keymap.
> Strange... Check 'setxkbmap -print' output next time.

OK, the netvm is now using Qwerty and untrusted is using Colemak but the
output from both domains is the same:

xkb_keymap {
xkb_keycodes { include "evdev+aliases(qwerty)" };
xkb_types { include "complete" };
xkb_compat { include "complete" };
xkb_symbols { include "pc+us+inet(evdev)" };
xkb_geometry { include "pc(pc105)" };
};

>> Ended up using a second HVM for Windows and ran into some limitations:
>> Can't do Ctrl-Alt-Del;
> I know, maybe will add some other shortcut remapped to Ctrl-Alt-Del. I though
> of Ctrl-Alt-Ins, but this can conflict with RDP client. Any other ideas?

For starters you could put a context menu item in VM Manager for the
HVMs. VirtualBox has a menu (but on the VM window) that lets you inject
certain key combos. It also defines a Host Key (or key combo) that you
can use to inject directly.

I would also guess that KDE is versatile enough to add widgets to the
titlebar of VM windows.


Unrelated suggestion: I turned on grouping by program name in the task
manager bar, hoping the windows might be grouped by VM. Instead they are
grouped by the color code so that a netvm terminal gets grouped with
apps in the untrusted domain. I would rather see the windows grouped
according to the name of the VM.


Joanna Rutkowska

unread,
Feb 17, 2013, 2:06:48 PM2/17/13
to qubes...@googlegroups.com, Marek Marczykowski, cprise
On 02/16/13 20:18, Marek Marczykowski wrote:

>> Ended up using a second HVM for Windows and ran into some limitations:
>> Can't do Ctrl-Alt-Del;
>
> I know, maybe will add some other shortcut remapped to Ctrl-Alt-Del. I though
> of Ctrl-Alt-Ins, but this can conflict with RDP client. Any other ideas?

I like the idea with having a menu in the manager that lets one send
select key combinations to the VM (VM->Send key
combination->Ctrl-Alt-Del, etc).

j.

signature.asc

Joanna Rutkowska

unread,
Feb 17, 2013, 2:07:13 PM2/17/13
to qubes...@googlegroups.com, Abel Luck
On 02/15/13 09:37, Abel Luck wrote:
> I've a t430s, and I only have 'hvm' for virt_caps.
>
> VT-d is enabled in the bios, any tips on debugging this?
>

Reading xl dmesg?

signature.asc

Marek Marczykowski

unread,
Feb 17, 2013, 4:34:14 PM2/17/13
to qubes...@googlegroups.com, cprise
On 17.02.2013 18:13, cprise wrote:
>
> On 2/16/13 2:18 PM, Marek Marczykowski wrote:
>> On 16.02.2013 17:47, cprise wrote:
>>> Earlier in the session the Netvm and Personal VMs forgot my keyboard
>>> mapping-- Reverting to Qwerty layout even though I had removed that
>>> layout days ago in the KDE settings (leaving only Colemak). I don't know
>>> what triggered it; I did mount a USB stick several times, created an HVM
>>> then deleted it without running it, expanded the allowed disk space on
>>> HVM and the Personal VM, and put the system to sleep a couple different
>>> times. I did not plug in a second monitor. Untrusted was running all
>>> this time but it (and Dom0) retained my intended keymap.
>> Strange... Check 'setxkbmap -print' output next time.
>
> OK, the netvm is now using Qwerty and untrusted is using Colemak but the
> output from both domains is the same:
>
> xkb_keymap {
> xkb_keycodes { include "evdev+aliases(qwerty)" };
> xkb_types { include "complete" };
> xkb_compat { include "complete" };
> xkb_symbols { include "pc+us+inet(evdev)" };
> xkb_geometry { include "pc(pc105)" };
> };

For the moment you can call "setxkbmap us -variant colemak" as a workaround. I
will look at it later.

>
>>> Ended up using a second HVM for Windows and ran into some limitations:
>>> Can't do Ctrl-Alt-Del;
>> I know, maybe will add some other shortcut remapped to Ctrl-Alt-Del. I though
>> of Ctrl-Alt-Ins, but this can conflict with RDP client. Any other ideas?
>
> For starters you could put a context menu item in VM Manager for the
> HVMs. VirtualBox has a menu (but on the VM window) that lets you inject
> certain key combos. It also defines a Host Key (or key combo) that you
> can use to inject directly.
>
> I would also guess that KDE is versatile enough to add widgets to the
> titlebar of VM windows.

Will try add something like this (VM Manager option or VM window menu).

> Unrelated suggestion: I turned on grouping by program name in the task
> manager bar, hoping the windows might be grouped by VM. Instead they are
> grouped by the color code so that a netvm terminal gets grouped with
> apps in the untrusted domain. I would rather see the windows grouped
> according to the name of the VM.

It is already known issue:
http://wiki.qubes-os.org/trac/ticket/375

Will try some window properties, maybe the fix is very simple.
signature.asc

Alex Dubois

unread,
Feb 18, 2013, 4:26:54 AM2/18/13
to qubes...@googlegroups.com, qubes...@googlegroups.com, cprise


Alex

On 16 Feb 2013, at 19:18, Marek Marczykowski <marm...@invisiblethingslab.com> wrote:

> On 16.02.2013 17:47, cprise wrote:
>>
>> I reset my router earlier this AM and just now turned to my Thinkpad to
>> find 18 netvm dialog boxes tiling my screen saying "Authentication
>> required by wireless network". For each box it seems to have selected
>> the next available access point in its list, round-robing style. I guess
>> it stopped at 18 because it eventually found my router again and
>> reconnected.
>
> Looks independent of Qubes, perhaps you should report it to Fedora or GNOME
> (this is GNOME NetworkManager applet).
>
>> Earlier in the session the Netvm and Personal VMs forgot my keyboard
>> mapping-- Reverting to Qwerty layout even though I had removed that
>> layout days ago in the KDE settings (leaving only Colemak). I don't know
>> what triggered it; I did mount a USB stick several times, created an HVM
>> then deleted it without running it, expanded the allowed disk space on
>> HVM and the Personal VM, and put the system to sleep a couple different
>> times. I did not plug in a second monitor. Untrusted was running all
>> this time but it (and Dom0) retained my intended keymap.
>
> Strange... Check 'setxkbmap -print' output next time.
>
>> Ended up using a second HVM for Windows and ran into some limitations:
>> Can't do Ctrl-Alt-Del;
>
> I know, maybe will add some other shortcut remapped to Ctrl-Alt-Del. I though
> of Ctrl-Alt-Ins, but this can conflict with RDP client. Any other ideas?

Ctrl-Shift-Alt-Del ? (In the same spirit as Ctrl-Shift-C)

Marek Marczykowski

unread,
Feb 18, 2013, 4:47:34 PM2/18/13
to qubes...@googlegroups.com, Alex Dubois, cprise, Joanna Rutkowska
For sure this will be the easiest way to implement. This can be even done to
have effect only in HVM screen window. Joanna, what do you think?
signature.asc

Joanna Rutkowska

unread,
Feb 18, 2013, 4:50:45 PM2/18/13
to Marek Marczykowski, qubes...@googlegroups.com, Alex Dubois, cprise
I think that 90% of users will never learn that such combination exists,
becuase users never do RFTM. That's why I think it's better to have a
menu in the manager that allows one to point and click.

signature.asc

Marek Marczykowski

unread,
Feb 18, 2013, 4:54:17 PM2/18/13
to Joanna Rutkowska, qubes...@googlegroups.com, Alex Dubois, cprise
Ctrl-Alt-Ins in RDP client works... Anyway will try to implement menu, or
maybe both solutions.
signature.asc

Marek Marczykowski

unread,
Feb 18, 2013, 7:15:24 PM2/18/13
to qubes...@googlegroups.com, cprise
Fixed :) Will be in the next beta release (very soon!).
signature.asc

cprise

unread,
Feb 26, 2013, 12:29:34 PM2/26/13
to qubes...@googlegroups.com
BTW, there is a problem with slow Wifi connections on Qubes. My wifi
card is Intel 6300 ultimate.

The connection info window in Qubes shows the link speed at 1Mb/s only
rarely rising to 9 or 11Mb/s for a few seconds at a time. The data flow
seems to stop now and then, but info never says that its disconnected.
Throughput is painfully slow and I'm only noticing it now because I
mostly used a wired link.

I think it is due to the staleness of the Intel Wifi driver in Qubes
2beta1. The router is only a few feet away and never gives me connection
problems.

Ubuntu 12.04 (which I am switching to temporarily) shows the link speed
anywhere from 1 to 54Mb/s, though rarely in-between. It goes to 1 when
the link is idle (power-saving feature?) and as soon as I start using
the net it jumps to 54 and stays there for a while afterwards. Data flow
seems continuous and very fast.

When I get back to Qubes with the next beta, I will include this issue
in my list of things to test.

Marek Marczykowski

unread,
Feb 26, 2013, 2:50:54 PM2/26/13
to qubes...@googlegroups.com, cprise
Perhaps you can try to disable this supposed power-saving feature. Some module
option, or sth...
signature.asc

David Schissler

unread,
Feb 26, 2013, 4:10:33 PM2/26/13
to qubes...@googlegroups.com
I've read that newer kernels have fixed something - although I have no idea what what was fixed.  Fedora 18 might include these changes or maybe not.  However, with Ubuntu:

I just installed Ubuntu 12.04.2 on my new x230t with the Intel 6205.  Out of the box the wireless was not connecting although I could see the networks.  I disabled 'n' support and it worked.  I was able to have wireless for the installation by typing the two modprobe commands and then I was able to make it permanent by adding the file to the modprobe.d directory.

You should still be rocking it pretty hard with the triple antenna when using 'g'.

Disable 802.11n wireless
http://ubuntuforums.org/showthread.php?t=2058500



sudo modprobe -r iwlwifi
sudo modprobe iwlwifi 11n_disable=1



sudo gedit /etc/modprobe.d/iwlwifi.conf

add

options iwlwifi 11n_disable=1

Abel Luck

unread,
Mar 9, 2013, 11:11:09 AM3/9/13
to qubes...@googlegroups.com
Abel Luck:
> Marek Marczykowski:
>> On 13.02.2013 01:07, cprise wrote:
>>> Hello...
>>>
>>> Intel HD4000 (Optimus present but turned off in BIOS)
>>> i5-3320M Ivy Bridge (supports VT-x and VT-d, turned on in BIOS)
>>> QM77 chipset
>>> BIOS version 2.05
>>>
>>> Other: TPM, vPro, WLAN Centrino 6300 Ultimate, Samsung 840 Pro SSD,
>>> 1600x900 screen, finger scanner
>>>
>>> Notes:
>>>
>>> Everything except bluetooth works at least on a basic level, but I don't
>>> see any indication from Qubes that the hardware virty features are being
>>> employed. Is there a way to tell?
>>
>> "xl info" in dom0 console. You should have "hvm" (for VT-x) and "hvm_directio"
>> (for VT-d) in virt_caps field.
>>
> I've a t430s, and I only have 'hvm' for virt_caps.
>
> VT-d is enabled in the bios, any tips on debugging this?

FYI for anyone else:

disabling VT-d in the bios, rebooting, then re-enabling it fixed this.
xl info now correctly has "hvm hvm_directio" indicating VT-d is enabled.

~abel

Reply all
Reply to author
Forward
0 new messages