I am a little confused because I thought that was your problem. I must have misunderstood your problem then. (Or the question mark is a typo).
Anyway, congratulations on your working AMD laptop!
Hm not yet, still quite a few issues, sys-usb doesn’t let me attach devices getting the error
No device info received, connection failed
Also it’ll randomly lock up at points, will need to iron these out before adding it to the HCL imo.
Cheers! 
1 Like
Woot!
You just made my Sunday not-awful. Do you have a suggested list of steps for building this?
Nevermind this, just be sure to use Kernel 5.4 specifically for sys-usb, USB Attachment/Detachment is now working perfectly.
Simply update all repos (make get-sources) confirm Xen = 4.14.0-2 and libvirt = 6.6.0-2
I set the LINUX Kernel Branch to 5.8.5, however it ended up compiling and using 5.8.7, not sure if this is a bug, I think the stable kernel (5.4) doesn’t have required AMD Drivers.
Compile an ISO and install.
Things to look out for:
The wizard at the end, after you’ve installed will fail, the result is you won’t have any TemplateVMs, Kernels or appVMs, to get around this I ended up downloading the required RPMs onto a USB and using dnf install to install them.
The specific RPMs I downloaded are:
- kernel-qubes-vm-5.4.55-1.qubes.x86_64.rpm
- qubes-template-fedora-32-4.0.1-202006110332.noarch.rpm
- kernel-latest-5.8.5-1.qubes.x86_64.rpm
- kernel-latest-qubes-vm-5.8.5-1.qubes.x86_64.rpm
I’m not sure why the Qubes Kernel & TemplateVM Packages don’t install as part of the Wizard, could be an existing bug?
After that, set the default Kernel to 5.8.5, then install the TemplateVM, do this in order because the RPM will start the appVM, it can’t do this without a Kernel installed.
Create your Service appVMs:
sudo qubesctl state.sls qvm.sys-usb
sudo qubesctl state.sls qvm.sys-net
sudo qubesctl state.sls qvm.sys-firewall
sys-net requires the PCI Devices be ‘strict’, also the Intel WiFi 6 card isn’t working so I just removed it for now (USB WiFi)
Set the defaults in Global Settings, make sure sys-usb is using Kernel 5.4, update TemplateVM and you should be golden.
By default you’ll only get 20GB on dom0, I booted a live Fedora 32 workstation instance to lvm expand the partition, you might be able to do this ‘live’, 20GB won’t cut it.
Be ready for random lockups sometimes, also when I start, the screen will just goto black, requires a power cycle, I haven’t located the reason behind this yet, but I assume some Xen Funkyness.
1 Like
Thanks again… Xen does appear to be the right version.
But the 4.1 current-testing branch has dom0 kernel 5.4 and I can’t find
builder instructions for setting it to 5.8.5. Am I supposed to install
it from an rpm after builder finishes with 5.4?
I’m happy to report Qubes 4.1 is running really, really smooth on this Lenovo X13 (AMD) device, it’s actually running Electron Applications (Element and Chromium for example) faster than 4.0.3 running on a 10th gen Intel CPU.
Smooth as 
!
As noted here:
- Add options
dom0_max_vcpus=1 dom0_vcpus_pintoGRUB_CMDLINE_XEN_DEFAULTin fileetc/default/grub. - Run
sudo grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg(assuming this is a Qubes 4.1 UEFI install). - Reboot.
After you’ve installed and everything will run absolutely smoothly, I’m going to find out what these options actually do.
To switch the branch for the Kernel simply change this line:
To the branch or tag name from GitHub - QubesOS/qubes-linux-kernel: Qubes component: linux-kernel
So v5.8.5-1 for example, however when I did this it compiled with 5.8.8, so I’m not fully sure what’s going on there.
BTW I wrote ^ on AMD 
As noted here:
- Add options
dom0_max_vcpus=1 dom0_vcpus_pintoGRUB_CMDLINE_XEN_DEFAULTin fileetc/default/grub.- Run
sudo grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg(assuming this is a Qubes 4.1 UEFI install).- Reboot.
After you’ve installed and everything will run absolutely smoothly, I’m going to find out what these options actually do.
dom0_max_vcpus sets the max number of vCPU cores which can be allocated
to Dom0. Setting it to 1 will result in everything done in dom0 being
run on a single virtual core.
dom0_vcpus_pin sets said single core to always be the same physical core.
For reference on xen commandline options:
https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html
This comes in quite useful when debugging.
Ah thank you.
Hm, I wonder if this is beneficial for Security anyway, limiting dom0 to 1 Core, could potentially limit side channel attack surface?
I haven’t noticed any performance issues.
Hm, I wonder if this is beneficial for Security anyway, limiting dom0 to 1 Core, could potentially limit side channel attack surface?
It may have some effect, but if you still have (for example)
hyperthreading enabled, Xen could still schedule another VM on the other
thread of dom0’s core.
From the link, I don’t think it restricts other VMs from being run on
the core. Just stops Dom0 from being run on others. Though someone with
some insight into the implementation may have more of an idea.
1 Like
[dylanger] dylanger https://forum.qubes-os.org/u/dylanger
September 16I’m happy to report Qubes 4.1 is running really, really smooth on this
Lenovo X13 (AMD) device, it’s actually running Electron Applications
(Element and Chromium for example) faster than 4.0.3 running on a 10th
gen Intel CPU.Smooth as
As noted here
https://github.com/QubesOS/qubes-issues/issues/6055#issuecomment-692946662:
- Add options |dom0_max_vcpus=1 dom0_vcpus_pin| to
GRUB_CMDLINE_XEN_DEFAULT| in file |etc/default/grub| .
- Run |sudo grub2-mkconfig -o /boot/efi/EFI/qubes/grub.cfg| (assuming
this is a Qubes 4.1 UEFI install).- Reboot.
After you’ve installed and everything will run absolutely smoothly, I’m
going to find out what these options actually do.tasket: I can’t find builder instructions for setting it to 5.8.5.To switch the branch for the Kernel simply change this line:
github.com
https://github.com/QubesOS/qubes-builder/blob/master/example-configs/qubes-os-master.conf#L116QubesOS/qubes-builder/blob/master/example-configs/qubes-os-master.conf#L116 <https://github.com/QubesOS/qubes-builder/blob/master/example-configs/qubes-os-master.conf#L116>
- gui-agent-windows \
- installer-qubes-os-windows-tools \
- builder-windows
Uncomment this to enable windows tools build
- #DISTS_VM += win7x64
- #COMPONENTS += $(WINDOWS_COMPONENTS)
- #BUILDER_PLUGINS += builder-windows
- BRANCH_vmm_xen = xen-4.14
- BRANCH_linux_kernel = stable-5.4
- TEMPLATE_ROOT_WITH_PARTITIONS = 1
- TEMPLATE_LABEL ?=
- TEMPLATE_LABEL += fc30:fedora-30
- TEMPLATE_LABEL += fc31:fedora-31
- TEMPLATE_LABEL += fc32:fedora-32
- TEMPLATE_LABEL += fc30+minimal:fedora-30-minimal
- TEMPLATE_LABEL += fc31+minimal:fedora-31-minimal
- TEMPLATE_LABEL += fc32+minimal:fedora-32-minimal
To the branch or tag name from GitHub - QubesOS/qubes-linux-kernel: Qubes component: linux-kernel
So |v5.8.5-1| for example, however when I did this it compiled with
5.8.8, so I’m not fully sure what’s going on there.BTW I wrote ^ on AMD
Thanks!
I didn’t notice a 5.8.x branch on github but noticed that master had
5.8.5 so I used ‘master’ for that value. It seems to have worked: the
fetched ‘version’ file says 5.8.5 and ‘make qubes’ completed.
But then ‘make iso’ failed with:
Copying builder-rpm RPMs…
make: *** No rule to make target ‘iso.copy-rpms.builder-rpm,’, needed
by ‘iso.copy-rpms’. Stop.
That’s after copying about 40 other components.
I think I remember having this, I ended up just cleaning everything, clean, clean-all, clean-rpms, clean-chroot
And it ended up rebuilding
BTW, I’m using an f30 template bc that’s what the builder docs show.
Should it be f32?
The only other thing I did to the config (besides disabling debian to
save space) was to add gcc to the exclusion list (this is recommended by
the builder docs).
I may just setup a fedora VM on the new laptop to do this bc trial and
error this way is too slow.
There’s an issue with dependencies (PyYAML) on 3.2 for 4.0 - don’t know
if that extends to 4.1
I’ve raised an issue on this - probably easy to resolve.
[dylanger] dylanger https://forum.qubes-os.org/u/dylanger
September 16I think I remember having this, I ended up just cleaning everything,
clean, clean-all, clean-rpms, clean-chrootAnd it ended up rebuilding
I’m getting a different error now from ‘make get-sources’:
→ Updating sources for builder…
→ Fetching from GitHub - QubesOS/qubes-builder: Qubes Builder master (options: --depth=1)…
→ Verifying tags…
→ Merging…
fatal: refusing to merge unrelated histories
make: *** [Makefile:208: builder.get-sources] Error 128
It doesn’t matter what I set the kernel branch to; putting it back to
‘stable-5.4’ has no effect.
[tasket] tasket https://forum.qubes-os.org/u/tasket
September 17[dylanger] dylanger https://forum.qubes-os.org/u/dylanger September 16 I think I remember having this, I ended up just cleaning everything, clean, clean-all, clean-rpms, clean-chroot And it ended up rebuildingI’m getting a different error now from ‘make get-sources’:
-> Updating sources for builder… –> Fetching from https://github.com/QubesOS/qubes-builder.git master (options: --depth=1)… –> Verifying tags… –> Merging… fatal: refusing to merge unrelated histories make: *** [Makefile:208: builder.get-sources] Error 128It doesn’t matter what I set the kernel branch to; putting it back to
‘stable-5.4’ has no effect.
Hmmm…
[user@qubes-builder qubes-builder]$ git log
commit 3a520654e6a0f5d848a349ef94d940db80ef504f (grafted, HEAD → master, tag: mm_3a520654, origin/master, origin/HEAD)
Author: Marek Marczykowski-Górecki marmarek@invisiblethingslab.com
Date: Wed Sep 16 00:18:15 2020 +0200Merge remote-tracking branch 'origin/pr/121' * origin/pr/121: travis-conf: use ALLOWED_COMPONENTS_* for builder-gentoo[user@qubes-builder qubes-builder]$ git pull
From git://github.com/QubesOS/qubes-builder
- 3a52065…a32e186 master → origin/master (forced update)
fatal: refusing to merge unrelated histories
[user@qubes-builder qubes-builder]$ git status
On branch master
Your branch and ‘origin/master’ have diverged,
and have 1 and 1 different commits each, respectively.
(use “git pull” to merge the remote branch into yours)nothing to commit, working tree clean
I expected to see the modified config files show up in status as
‘modified’. But it looks like one of the builder scripts added/committed
them.
So now its diverged and its looking like wiping the repo and ./setup,
then re-cloning and then changing configs again is the way to go.
The error was probably in using ‘setup’, as I had two different
qubes-builder guides open and that confused me. The way to do it is to
‘cp example-configs/qubes-os-master.conf builder.conf’ after cloning the
qubes-builder repo, then change the kernel version as mentioned before
running ‘make get-sources’ and the rest.
Now I have a ready iso I have to install. 
2 Likes
I ran into the same issue related to missing kernel packages and asked on qubes-devel. Marek responded with:
If you use master branch of linux-kernel, then the package names are
different: kernel-latest and kernel-latest-qubes-vm. There are few
places you need to change it:
- qubes-src/installer-qubes-os/meta-packages/comps/comps-dom0.xml
- qubes-src/lorax-templates/templates/runtime-install.tmpl
Making the changes worked for me in terms of getting the install completed successfully.
To get the AX200 wifi to work I added “iwlwifi.disable_rxq=1” to the kernelopts for sys-net (https://github.com/QubesOS/qubes-issues/issues/5615). I’ll probably try the kernel patch if I run into the same issues that tasket reported
A question for T14 users here. Currently I use an old Elitebook, most of the time connected to an external monitor and with USB keyboard and mouse. For better security, I have able been to setup 2 sys-usb VM’s. One USB controller(connected to 2 usb 3.0 ports on one side of the notebook) attached to one VM, and the other USB controller (connected to a USB 2 port and a USB 2/SATA port on the other side of the notebook) which is attached to the other sys-usb VM. So now I can connect my mouse and keyboard to a sys-usb vm with the dom0 input proxy enabled, and I can connect USB storage devices to the other sys-usb vm without having to worry that the devices could impersonate a keyboard, because that sys-usb doesn’t have the input proxy enabled.
I’m considering a T14 as future notebook, and naturally would like to continue with 2 sys-usb VM’s if possible, but this is of course dependent on the number and configuration of PCI devices for the USB ports.(And also the number of IOMMU groups to properly enforce the isolation.)
Does anyone know how many PCI devices there are for the USB ports/controllers and if it also works properly in practice when they’re divided between 2 VM’s instead of all attached to one VM?
Major update to anyone running on a Lenovo X13/T14, no need to pin cores/limited 2 cores per appVM!
3 Likes
Thanks for the update, @dylanger. This is a great development.
By the way, does anyone know whether with the latest thinkpads like these the Intel or AMD versions should be more energy efficient with Qubes?