OS operates flawless with a few exception. Ill list hardware first
Lenovo Slim 7 Pro X (82V2)
R4.2.1
Secure Boot Disabled
Outside of the issues below the system runs very well. Crisp and clean.
Issue 1: Upon install, there are no sys-net or sys network templates. Only 4 templates were installed.
debian-12-xfce
Also despite clicking - upon configuration when installing, it did not install default work, personal vault etc AppVMs
Issue 2 : when i attempt to start or change any setting of the actuallly installed templates, the System reboots immediately, allowing me to log back in just fine.
Doesnt seem to have any network access either. No networking options listed on system tray or file directory
Any help or pointers in the right direction would be greatly appreciated
Try to install Qubes OS 4.2.2-rc1 with kernel-latest option.
1 Like
Installing now. Thank you for the quick response.
Will keep you updated.
Unfortunately no luck. After configurations, booted up just fine. No network templates and also still
Did you enable AMD-V with RVI and AMD-Vi (also known as AMD IOMMU) in BIOS?
journalctl -f -n0
Then try to start one of the template and check the command output to see the errors.
Had to prepare myself for a quick snap since the sys reboots fairly quickly
These are all the VMs installed. Missing quite a few for a fresh install
Oh and yes, AMD V ™ in Bios is enabled.
Souldad:
BiOs: JVCN35Www
Is it the latest BIOS version?
I guess it’s an issue with either Xen or dom0 kernel, but without crash log I’m not sure what else can you try.
opened 04:58PM - 10 Aug 21 UTC
T: enhancement
C: installer
C: Xen
P: default
On laptops lacking physical serial console, collecting logs of a crashed Xen (or… dom0 kernel) is hard. One method is to use kexec to extract them from the RAM. Currently this requires several non-trivial changes to the system. This issue is to ease preparing system for such debugging.
Details from the original issue:
> > Isn't there tweaks that can be added from boot command line which would make logs saved synchronously and permit to troubleshoot this for everyone without a need of external additional devices @marmarek?
>
> Sadly, not. When Xen panic, dom0 has no chance to execute anything anymore. And it's dom0 who writes logs to the disk (or anything else for that matter).
@marmarek @fepitre
[From this comment](https://github.com/QubesOS/qubes-issues/issues/6066#issuecomment-891736396):
>As for collecting logs, I do have a method for that, but it's quite adventurous - make Xen kexec Linux on panic, to dump the memory content, and then to extract logs from there. It requires custom rebuilding Xen (because we have kexec disabled by default), kexec-tools (because the one in Fedora isn't built with Xen), build initramfs that dump the memory (kdump package helps with that, but requires few tweaks to make it work), and finally have some place to save the dump too - if using the main disk, you need to configure LUKS with a key file + allocate quite a lot of RAM for the crashkernel (because of memory-hard Argon2i in LUKS2). When having the dump, extracting messages is relatively easy - I use strings for that. Theoretically the crash utility can do that more conveniently, but it didn't work for me.
This exact QubesOS 4.1 ISO deployment (debug iso with all above dependencies preconfigured) would help to debug so many corner cases for QubesOS project, including this one? Instruct a willing [tester](https://forum.qubes-os.org/t/joining-the-testing-team/5190/1) to install QubesOS on spare drive and report results without having to go through the burden of customizing such testing testbed? Should that be discussed in a separate issue (with more details on doing this manual and then automate the process, maybe?)
> if using the main disk, you need to configure LUKS with a key file + allocate quite a lot of RAM for the crashkernel (because of memory-hard Argon2i in LUKS2)
@marmarek / @fepitre : Random thought, but if there is enough space affected to /boot in the default partitition scheme of that debug iso, dumping said logs from kexec'ed linux kernel to dump memory under /boot would work around a lot of the complexity added dumping needed logs and go faster into having what logs we need, easily, from an additioanl boot of said debug ISO in Read Only rescue mode from boot options.
_Originally posted by @tlaurion in https://github.com/QubesOS/qubes-issues/issues/6066#issuecomment-895447248_
Also the same issue with your laptop model:
I recently bought a system to run Qubes 4.2, but every time I boot a VM, the system hangs for a couple seconds, then immediately powers off and reboots. Originally I thought it was an issue handling PCI devices (some people seemed to have similar-ish problems relating to PCI passthrough with certain devices), but starting a VM with no passed-through devices results in the same behavior.
This results in a scenario where the Qubes initial setup consistently crashes. I can create qubes manually if…
So it’s not some hardware issue with only your laptop but for this laptop model in general.
There was a similar issue but it’s fixed already:
opened 10:43PM - 18 Jul 22 UTC
closed 01:06PM - 09 Sep 22 UTC
T: bug
C: other
P: default
hardware support
affects-4.1
### Qubes OS release
R4.1 (ISO built with kernel-latest - 5.18.9-1) - https://b… uilds.sr.ht/~dylanger/job/804051
### Brief summary
Following on from https://github.com/QubesOS/qubes-issues/issues/7570, in order to install and boot, I'm required to add `dom0_max_vcpus=1 dom0_vcpus_pin` to dom0's CMDLINE, this is [similar](https://github.com/QubesOS/qubes-issues/issues/6055#issuecomment-692946662) to what I had to do when Ryzen 4000 series laptops had just come out
When I attempt to start an appVM, any appVM, fedora-36 templateVM for example, the VM starts, then the entire device hangs and resets, I'm unable to view any logs because the entire device resets before I can read logs.
xen-devel mailing list thread: https://xen.markmail.org/search/?q=Dylanger#query:Dylanger+page:1+mid:svghzn57btjkwjax+state:results
### Steps to reproduce
- Create a Qubes ISO with kernel-latest
- Boot it on a Yoga Slim 7 ProX
### Expected behavior
- QubesOS working
### Actual behavior
- Limiting dom0 to 1 pinned vcore
- Starting any appVM results in the device resetting
Maybe your issue is somehow related.
1 Like
I want to thank you apparatus for taking the time to work on my inquiry.
I am happy to say that after reinstalling the latest version of Qubes as you had originally suggested…worked and Im a fully running Qubes on my device.
Im excited to be apart of this community and looking forward to continuing my education.
