Re: Qubes 4.0rc2 install on corebooted Lenovo G505s (AMD)

[awokd]

On Wed, October 25, 2017 20:32, awokd wrote:
> Few issues on this attempt am hoping someone might have some insight into.
>
> 1) Installer warns "interrupt remapping" is not supported.
> qubes-hcl-report shows IOMMU as enabled but "Remapping" is not. What
> exactly are they looking for?
>
> 2) Install completes and reboots successfully after that but it only gets
> part way through the first default template installation (whonix-gw) then
> hard locks- no mouse or keyboard response. Is there a way to force these
> to install in compatible mode or something so I can work on fixing them
> later?
>
> 3) I can choose Do not configure anything and get logged in and to a
> terminal window, but without any templates or VMs am pretty lost on how to
> setup from scratch. qubes-template-fedora-25.noarch is listed in dnf but
> when I try to create an AppVM there's nothing in the template dropdown.
>
> When I boot debian stretch on the same machine, I see AMD-Vi enabling
> interrupt remapping. xl dmesg under 4.0 shows (Xen) enabling interrupt
> remapping. Qubes 3.2 worked fine on this too.
>
> Suggestions welcomed!

1) I found https://github.com/QubesOS/qubes-issues/issues/3208 which seems
to address this case and see "(XEN) Interrupt remapping enabled" [with
lowercase "r"] in my xl dmesg output too.

2) This might be related but I'm having trouble finding if this patch has
made it into the version of Xen Qubes uses.
http://xen.1045712.n5.nabble.com/Xen-4-6-0-Dom0-freezes-at-creation-of-HVM-domain-with-activated-IOMMU-td5731709.html

3) I see what seem to be partially installed templates under
/var/lib/qubes/vm-templates but fedora-25 for example has 4.5 1GB
root.img.part.0? files and no root.img.

[awokd]

Any suggestions where to begin troubleshooting 2 or 3? Is there a way to
repeat the initial template setup step (or any built in template
deployment) from the command line with logging enabled, for example?
I've used 3.2 since it shipped but have exhausted the search engines on
this one and am facing a blank wall with no toeholds.

[William Bormann]

I also experienced problems with item 2. The progress meter would simply stop and the system would appear to be locked up. I was installing RC2 to a USB stick.

Amazingly, the system was actually making progress despite what the meter was reporting. By coincidence, my attention was diverted and I had to walk away from the system. When I returned, it was ready for the next installation step.

[awokd]

On Tue, October 31, 2017 21:25, William Bormann wrote:
> I also experienced problems with item 2. The progress meter would simply
> stop and the system would appear to be locked up. I was installing RC2 to
> a USB stick.

Thanks for the suggestion. I tried again and let it sit for 6 hours but
sadly, never made it past the first template (which happened to be
fedora-25 this time around.) I think mine is a hard lockup because the
mouse pointer stops responding and caps and numlock lights on the keyboard
stop working too.

[Tai...@gmx.com]

Reposting in the other thread.

On 11/18/2017 03:30 PM, awokd wrote:

I have a Corebooted G505S and it's hard locking up on the RC2 install.
Still haven't figured out how to begin to troubleshoot it, but it's not
working for me. See the thread:
https://mail-archive.com/qubes...@googlegroups.com/msg15824.html

I will assist you with this, I provide free expert tech support for the free firmware owners (anyone who has a device with open source silicon init can email me off list for hardware/firmware/virt support)

> 1) Installer warns "interrupt remapping" is not supported.
> qubes-hcl-report shows IOMMU as enabled but "Remapping" is not. What
> exactly are they looking for?

IR is an additional security and performance measure, it is supported in the firmware so I don't understand as to why it isn't present. I would say that is a xen issue.

> 2) Install completes and reboots successfully after that but it only gets
> part way through the first default template installation (whonix-gw) then
> hard locks- no mouse or keyboard response. Is there a way to force these
> to install in compatible mode or something so I can work on fixing them
> later?

I would install qubes on different hardware on the same drive then swap the drive back so we can get a better shell and see what is happening.

> When I boot debian stretch on the same machine, I see AMD-Vi enabling
> interrupt remapping. xl dmesg under 4.0 shows (Xen) enabling interrupt
> remapping. Qubes 3.2 worked fine on this too.

I would take a guess and say this is probably a xen issue, if you do the above we can get more info maybe change the version/update to fix it.

[awokd]

On Sun, November 19, 2017 17:13, Tai...@gmx.com wrote:

> IR is an additional security and performance measure, it is supported in
> the firmware so I don't understand as to why it isn't present. I would
> say that is a xen issue.

This turned out to be a known bug but believe it's cosmetic only:
https://github.com/QubesOS/qubes-issues/issues/3208

> I would install qubes on different hardware on the same drive then swap
> the drive back so we can get a better shell and see what is happening.

Did this. Good news is my daily driver is going to work once I'm ready to
upgrade it to 4.0.

Bad news- Pulled the drive and put it back in the G505s. Successfully
booted once to the desktop because the NetVM still had the other machine's
NICs assigned to it which prevented it from starting. I "fixed" it by
assigning the G505s's wireless NIC to it and setting Autostart to No, but
starting the VM caused the hard lock again. Rebooted but now it's hard
locking up shortly after entering the disk password. Suppose it's trying
to autostart the NetVM anyways due to a time sync dependency or something.

I can boot Debian on the same machine from a USB drive and hopefully get
the right Qubes partition mounted so I'm going to try to figure out some
way to break the NetVM template again in qubes.xml. Then I should be able
to get back to the desktop again.

PS I tried to email you off-list but Barracuda bounced me with a bad
reputation. Anyways, your offer to assist is much appreciated.

[awokd]

For anyone following this thread, made some progress. The CPU microcode
wasn't getting updated under Coreboot; it was showing as patch level
0x00000000 instead of 0x06001119. Thanks to Taiidan for pointing this out.
I figured out how to get it updated under Coreboot which resolved my
freezing issue when starting HVMs. Now I'm working on turning it into a
commit so other Coreboot G505s owners will be able to run Qubes 4.0 too!