[bug] After upgrade to unstable, Qubes Manager won't launch

[Andrew B]

Hi,

After upgrading to qubes-dom0-unstable on my Thinkpad X230, qubes-manager refuses to launch. I actually experienced this before on my HP Chromebook 14, but some combination of switching display managers and rebooting seemed to fix it, and it now works just fine under both KDE and Xfce. My Thinkpad, on the other hand, only has one display manager, so I haven't tried switching. However, I did reboot, and Qubes Manager still won't launch.

If I open a python REPL and import qubesmanager.main, it works; when I call qubesmanager.main.main(), it exits. Looking into the Qubes Manager site package, I find that it 'hangs' in main.py right at the line, "manager_window = VmManagerWindow(qvm_collection, blk_manager)". I did not dig deeper to find the cause, but I did strace the process. I will send this strace log under separate cover.

Andrew

[Marek Marczykowski-Górecki]

This particular problem is because wrong permissions on xenstored socket. Not
sure why change of kernel caused this - perhaps something was really slow at
startup and some race condition occured. To fix permissions just execute:
sudo /usr/lib/qubes/fix-dir-perms.sh

Anyway I also see a lot of problems with 3.17.1 kernel in dom0. For me it is:
- Fn+sth keys not working at all
- suspend hungs
Additionally this kernel in firewallvm (when multiple VMs are connected there)
causes really strange memory errors.

The main reason for this kernel is much more mature USBIP supprt (see #531),
but generally I'd recommend to avoid this particular package until stability
issues will be fixed. Or just use in some selected VMs (where you want to use
USBIP).

--
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?

[Andrew B]

On 10/31/14 16:41, Marek Marczykowski-Górecki wrote:
> On 31.10.2014 14:35, Andrew B wrote:
>> Hi,
>>
>> After upgrading to qubes-dom0-unstable on my Thinkpad X230, qubes-manager refuses to launch. I actually experienced this before on my HP Chromebook 14, but some combination of switching display managers and rebooting seemed to fix it, and it now works just fine under both KDE and Xfce. My Thinkpad, on the other hand, only has one display manager, so I haven't tried switching. However, I did reboot, and Qubes Manager still won't launch.
>>
>> If I open a python REPL and import qubesmanager.main, it works; when I call qubesmanager.main.main(), it exits. Looking into the Qubes Manager site package, I find that it 'hangs' in main.py right at the line, "manager_window = VmManagerWindow(qvm_collection, blk_manager)". I did not dig deeper to find the cause, but I did strace the process. I will send this strace log under separate cover.
>>
>> Andrew
>
> This particular problem is because wrong permissions on xenstored socket. Not
> sure why change of kernel caused this - perhaps something was really slow at
> startup and some race condition occured. To fix permissions just execute:
> sudo /usr/lib/qubes/fix-dir-perms.sh

Great, that fixed it. Strange problem, though.

> Anyway I also see a lot of problems with 3.17.1 kernel in dom0. For me it is:
> - Fn+sth keys not working at all
> - suspend hungs
> Additionally this kernel in firewallvm (when multiple VMs are connected there)
> causes really strange memory errors.
>
> The main reason for this kernel is much more mature USBIP supprt (see #531),
> but generally I'd recommend to avoid this particular package until stability
> issues will be fixed. Or just use in some selected VMs (where you want to use
> USBIP).
>

I don't usually use suspend, but I just tested it and it works fine on my system. I'm not sure how to exercise these memory errors, but I haven't had any trouble with 3.17 as FirewallVM kernel yet (and yes, with multiple VMs attached). As far as I can tell, this issue and the Fn+[x] problems are the only two issues for my hardware with this kernel.

The main reason for me to use this kernel is for touchpad support on my Chromebook 14. But since the Fn+[x] issue isn't a big deal for me, I'll keep testing 3.17.
Looking forward to improved USB support!

Andrew

[Andrew B]

BTW, this problem recurs on every reboot. The plot thickens...

Andrew

[Marek Marczykowski-Górecki]

On Sun, Nov 02, 2014 at 08:51:13PM +0100, Andrew B wrote:
> On 10/31/14 18:10, Andrew B wrote:
> > On 10/31/14 16:41, Marek Marczykowski-Górecki wrote:
> >> On 31.10.2014 14:35, Andrew B wrote:
> >>> Hi,
> >>>
> >>> After upgrading to qubes-dom0-unstable on my Thinkpad X230, qubes-manager refuses to launch. I actually experienced this before on my HP Chromebook 14, but some combination of switching display managers and rebooting seemed to fix it, and it now works just fine under both KDE and Xfce. My Thinkpad, on the other hand, only has one display manager, so I haven't tried switching. However, I did reboot, and Qubes Manager still won't launch.
> >>>
> >>> If I open a python REPL and import qubesmanager.main, it works; when I call qubesmanager.main.main(), it exits. Looking into the Qubes Manager site package, I find that it 'hangs' in main.py right at the line, "manager_window = VmManagerWindow(qvm_collection, blk_manager)". I did not dig deeper to find the cause, but I did strace the process. I will send this strace log under separate cover.
> >>>
> >>> Andrew
> >>
> >> This particular problem is because wrong permissions on xenstored socket. Not
> >> sure why change of kernel caused this - perhaps something was really slow at
> >> startup and some race condition occured. To fix permissions just execute:
> >> sudo /usr/lib/qubes/fix-dir-perms.sh
> >
> > Great, that fixed it. Strange problem, though.
> >
> >> Anyway I also see a lot of problems with 3.17.1 kernel in dom0. For me it is:
> >> - Fn+sth keys not working at all

This isn't right diagnosis. The keys are working, but with incredible lag,
like 1h.

> >> - suspend hungs

Update: suspend now is working, don't know why, I haven't changed
anything...

[Andrew B]

I also noticed that the "lid closed" event appears to have the same delay as the Fn+[x] keys. At least, my screen does not turn off after closing the lid unless I leave it closed for ~30s.

Andrew