Please help with 8th Generation Intel i5

[Krišjānis Gross]

Hi,

Was using Qubes 3.2 on 4th generation i5 processor when decided to upgrade my hardware.

Purchased 8th gen i5 processor and MB. Now when I start my Qubes only dom0 is started. no other VM is started unfortunately.

Here is the hardware details:
MB: ASRock Z370 Pro4 https://www.asrock.com/MB/Intel/Z370%20Pro4/index.asp
CPU: Intel® Core™ i5-8600K https://ark.intel.com/products/126685/Intel-Core-i5-8600K-Processor-9M-Cache-up-to-4_30-GHz
RAM: 16 GB DDR4


Qubes 3.2. boots but feels very slow. e.g. when I type the characters appear with considerable delay. Mouse is not working. I can only do something with PS2 keyboard.

I tried to run Qubes installation but failed to do that. 3.2 did not start the installation at all.
Qubes 4.0rc3 installation did get to some point and resulted in error.
I have attached some screen shots of 4.0 installation.

Not sure what to do next. Read in some other topics that others had an issue with new hardware.

Please help to resolve this. I really really want to continue using Qubes. it is such an awesome system!

[donoban]

Try to switch to log or shell with alt+tab or ctrl+alt+F2 / ctrl+alt+F3

If you get a shell look in /tmp for log files

Did you try another Linux distribution?

[Krišjānis Gross]

Thank You for the answer, donaban!

I did navigate to /tmp and looked at some logs. Unfortunately I do not know what to look for there. Took some screen shots (attached). Does that ring any bells?

A side question- how can I copy the logs in /tmp to a flash drive or something in order to post those here?

Which Linux distribution should I try to run in order to do a reasonable comparison?

[donoban]

On 01/18/2018 11:15 AM, Krišjānis Gross wrote:> I did navigate to /tmp

and looked at some logs. Unfortunately I do not know what to look for
there. Took some screen shots (attached). Does that ring any bells?

I think the problem is:

(EE) VESA(0): V_BIOS address 0xaa7a0 out of range

I've searched a little but I didn't find anything useful. I hope someone
could help you on this.

>
> A side question- how can I copy the logs in /tmp to a flash drive or something in order to post those here?
>
> Which Linux distribution should I try to run in order to do a reasonable comparison?
>

Ideally same as dom0, fedora-24?? I would try to guess what kernel
version starts to work fine with it and compare with built-in the qubes iso.

[Krišjānis Gross]

Thank You for the suggestion! Will check that out.
I tried to install Debian 9 on this hardware and all went fine. Only thing that I noticed when installation was finished was that there was a notification that system is running a " software emulated graphics" and therefore CPU usage might be considerably higher. Not sure whether that is relevant though.

[Foppe de Haan]

Most likely due to lacking hardware support (in the kernel) for the CL graphics chip (even though it's little more than a rebrand of KL's). Try installing a more recent (ideally 4.14-based) kernel. Iow, it's sort of related, because the issues you ran into while installing qubes were most likely also related to that.

[awokd]

On Fri, January 19, 2018 11:32 am, Krišjānis Gross wrote:
> On Thursday, 18 January 2018 20:56:10 UTC, donoban wrote:

>>
>> (EE) VESA(0): V_BIOS address 0xaa7a0 out of range

>>> A side question- how can I copy the logs in /tmp to a flash drive or
>>> something in order to post those here?

Can you get sys-usb started? If so, use qvm-copy-to-vm in dom0 to copy the
logs to a VM, then to the flash drive. Otherwise, you could boot with a
live image of some type, mount the hard drive and copy out the logs.

> Thank You for the suggestion! Will check that out.
> I tried to install Debian 9 on this hardware and all went fine. Only thing
> that I noticed when installation was finished was that there was a
> notification that system is running a " software emulated graphics" and
> therefore CPU usage might be considerably higher. Not sure whether that
> is relevant though.

Both seem unhappy with your video card. What's in that laptop? Please post
Debian's boot log (redact hardware serial numbers & MAC addresses), and
Qubes' xl dmesg log if you can get it.

[Krišjānis Gross]

@ Foppe de Haan

>Most likely due to lacking hardware support (in the kernel) for the CL >graphics chip (even though it's little more than a rebrand of KL's). Try >installing a more recent (ideally 4.14-based) kernel. Iow, it's sort of >related, because the issues you

Please suggest how to install Qubes with different Kernel version. I have not idea how that can be done :)

>Can you get sys-usb started? If so, use qvm-copy-to-vm in dom0 to copy the
>logs to a VM, then to the flash drive. Otherwise, you could boot with a
>live image of some type, mount the hard drive and copy out the logs.

This was a /tmp log of installation process. Not sure that dom0 as such is available during the installation.

>Both seem unhappy with your video card. What's in that laptop? Please post
>Debian's boot log (redact hardware serial numbers & MAC addresses), and
>Qubes' xl dmesg log if you can get it.

The setup is not a laptop. It is a desktop see HW details below. Will try to get the Debian's boot log.

[Krišjānis Gross]

Managed to install Fedora on this hardware and here is the boot.log that I can find in /var/log

Does that help to understand the issue?

[donoban]

On 01/23/2018 06:11 PM, Krišjānis Gross wrote:
>
> Managed to install Fedora on this hardware and here is the boot.log that I can find in /var/log
>
> Does that help to understand the issue?
>

It does not seem a very useful log. Send something like kern.log or
dmesg. Also Xorg.X.log since your problem is starting Xorg during the
installation.

[Krišjānis Gross]

On Wednesday, 17 January 2018 21:24:05 UTC+2, Krišjānis Gross wrote:

Thank You for the help, donban!

I can not find a kern.log or dmesg. I did find the Xorg log files. (This is all on the Fedora that I recently installed on this same hardware). Xorg Log files attached.

Here is what I have in /var/log foder:
[krish@localhost ~]$ ls /var/log/ -la
total 2412
drwxr-xr-x. 17 root root 4096 Jan 24 20:34 .
drwxr-xr-x. 22 root root 4096 Nov 5 09:35 ..
drwxrwxr-x. 2 root root 4096 Jan 19 17:43 anaconda
drwx------. 2 root root 4096 Dec 14 19:23 audit
drwxr-xr-x. 2 root root 4096 Sep 19 10:54 blivet-gui
-rw-r--r--. 1 root root 10155 Jan 24 20:33 boot.log
-rw-------. 1 root utmp 384 Jan 23 20:18 btmp
drwxr-xr-x. 2 chrony chrony 4096 Sep 15 13:19 chrony
drwxr-xr-x. 2 root root 4096 Oct 26 09:49 cluster
drwxr-xr-x. 2 lp sys 4096 Jan 12 13:28 cups
-rw-r--r--. 1 root root 1722708 Jan 24 20:43 dnf.librepo.log
-rw-r--r--. 1 root root 127175 Jan 24 20:43 dnf.log
-rw-r--r--. 1 root root 10304 Jan 24 20:43 dnf.rpm.log
-rw-r--r--. 1 root root 0 Jan 19 17:47 dpkg.log
-rw-r--r--. 1 root root 544 Jan 24 20:33 firewalld
drwx--x--x. 2 root gdm 4096 Nov 30 16:21 gdm
drwxr-xr-x. 2 root root 4096 Jan 12 17:06 glusterfs
-rw-------. 1 root root 1294 Jan 19 21:30 grubby
-rw-r--r--. 1 root root 23421 Jan 24 20:43 hawkey.log
drwx------. 2 root root 4096 Oct 25 15:35 httpd
drwxr-sr-x+ 3 root systemd-journal 4096 Jan 19 17:43 journal
-rw-rw-r--. 1 root utmp 292292 Jan 24 20:34 lastlog
drwx------. 3 root root 4096 Dec 4 19:15 libvirt
drwx------. 2 root root 4096 Aug 4 14:35 ppp
-rw-r--r--. 1 root root 1040 Oct 26 13:30 README
drwx------. 3 root root 4096 Jan 8 17:10 samba
drwx------. 2 root root 4096 Nov 8 12:25 speech-dispatcher
drwxr-x---. 2 root root 4096 Dec 4 22:57 sssd
-rw-------. 1 root root 64064 Jan 19 17:42 tallylog
-rw-r--r--. 1 root root 772 Jan 19 18:39 vmware-vmusr.log
-rw-rw-r--. 1 root utmp 14976 Jan 24 20:34 wtmp
-rw-r--r--. 1 root gdm 17416 Jan 24 20:34 Xorg.0.log
-rw-r--r--. 1 root gdm 18210 Jan 23 22:32 Xorg.0.log.old
-rw-r--r--. 1 root krish 16760 Jan 24 20:34 Xorg.1.log
-rw-r--r--. 1 root krish 18099 Jan 23 22:32 Xorg.1.log.old

[awokd]

On Wed, January 24, 2018 7:09 pm, Krišjānis Gross wrote:

>
> I can not find a kern.log or dmesg. I did find the Xorg log files. (This
> is all on the Fedora that I recently installed on this same hardware).
> Xorg Log files attached.

Try "sudo journalctl -b > journal.log". Review and redact any sensitive
information (serial numbers, usernames, etc.) then reply here with it
attached.

[Krišjānis Gross]

On Wednesday, 17 January 2018 21:24:05 UTC+2, Krišjānis Gross wrote:

here it is (attached). Hope that helps!

[awokd]

On Thu, January 25, 2018 7:19 pm, Krišjānis Gross wrote:

>
> here it is (attached). Hope that helps!

From the journal:
Jan 25 20:53:15 localhost.localdomain kernel: [drm] The driver support for
your hardware in this kernel version is alpha quality
See
CONFIG_DRM_I915_ALPHA_SUPPORT
or i915.alpha_support module
parameter
to enable support in this
kernel version, or check for
kernel updates.

This is enabled by default on Qubes 4.0, but I'm not sure if that's the
case for 3.2. That could be why video was so slow on 3.2. (On a side note,
why is this Linux driver still alpha after it's been around for years?)
Everything else looks fine. I see DMAR gets set up so hardware
virtualization should work. Didn't notice any obvious problems in the Xorg
logs.

Look for the "i915.preliminary_hw_support=1" entries in
https://pastebin.com/u8z6nWV5 for an example of where you should add them
to 3.2 if they aren't there. I agree with the other suggestion made
earlier, wait for rc4 then try 4.0 again too.

[Krišjānis Gross]

Thank You for the recommendation, awokd!

I did not find the time to try that out. Will try everything again with the most recent release. And if there will be issues will post a new question thread.