Le 17 août 2018 à 14:33, awokd <aw...@danwin1210.me> a écrit :
> 
>> On Thu, August 16, 2018 11:28 pm, vsanchezleigh...@gmail.com wrote:
>> Hi,
>> 
>> 
>> I have been using qubes 3.2 for more than a year now on a Lenovo x250
>> thinkpad. Today after a qubes-dom0-update ( that appears in dnf history as
>> date: 2018-08-16 12:56 , Action: I,U , Modified: 11 E<) I turned off the
>> pc.
>> 
>> When I turned it on again a few hours later it simply wouldn’t finish
>> qubes boot and restarted every time before getting to the window manager.
>> So I got into grub from the splash screen to explore things and found an
>> empty xen.cfg file in qubes subdirectory : I replaced it with one found
>> in the qubes doc at the UEFI troubleshooting page (and tried out with the
>> three kernel versions present in the boot partition). It didn’t improve
>> things, boot still finished in restart. So I then chose the other items
>> in grub’s menu and suppressed the quiet option from the xen.cfg. In this
>> manner the subitem using kernel 4.14.57 could still not boot but the
>> other two could (partially) with 4.9.56 and 4.4.14. Partially, because in
>> both cases when the boot got through to the gui  neither sys-net nor
>> sys-firewall would start (the dom0 log indicates some crashing problems
>> after starting dom0, see pictures).
>> 
>> Any suggestions to help me get back to my previous stable situation ? How
>> difficult would it be to unroll completely the dom0 update that led to
>> this ? Thanks.
> 
> Invalid opcode in dom1 makes me think a template got updated and is trying
> to execute one of the new mitigations, but your microcode doesn't support
> it. Check for a firmware update for your system.
> 
> If there isn't one, try setting your VMs to not auto-start by editing
> /var/lib/qubes/qubes.xml, then seeing if you can get into Qubes and figure
> out which template is causing it. Then switch your VMs to use a different
> one.

Thanks for your reply. 
I tried upgrading the bios to the most recent version on Lenovo’s site that 
cites it mitigates variant 4 and 3a of spectre (1.32).

The problem remained the same in qubes though. And I noticed in dmesg for dom0 
a message during systemd[1] bring up that says ‘Failed to start Load Kernel 
Modules.’ (It’s the only message in red).

I tried -as you suggested- to boot with no vm in autoboot and changed their 
templates from fedora 27 to fedora 26. Then I tried to launch manually sys-net 
or templates or other vms. They all try to run sys-net (its state icon becomes 
yellow then disappears), then fail and -some time later- they report ‘Error 
starting VM: Cannot execute qrexec-daemon’. I also tried using debian-8 
template.

After each vm start failure dom0’s log (/var/log/xen/console/hypervisor.log 
attached) shows again a new iteration of the same ‘Unhandled invalid opcode 
fault/trap [#6, ec=0000]’ and a call to domain_crash_sync etc...

Any suggestions ?
Thanks again.

Vicente

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/86A44A27-4A9C-4604-9A49-BC0534D8509A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Attachment: hypervisor.log
Description: Binary data


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/86A44A27-4A9C-4604-9A49-BC0534D8509A%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to