search

Dasharo / dasharo-issues

The Dasharo issue tracker
https://dasharo.com/
24 stars 0 forks source link

QubesOS can't wake from suspend #656

Open filipleple opened 8 months ago

filipleple commented 8 months ago

Device

MSI Z690-A WiFi DDR4 ADL

Dasharo version

v1.1.3

Affected component(s) or functionality

Wake from suspend

Brief summary

QubesOS won't wake from suspend by keyboard key press. Using the power button delivers various results - from rebooting to none at all.

How reproducible

No response

How to reproduce

sudo systemctl suspend try to wake the platform by key press or power button push

Expected behavior

The platform should wake

Actual behavior

The platform ignores key presses, and the power button causes it to reboot or gets ignored as well

Screenshots

No response

Additional context

No response

Solutions you've tried

No response

miczyg1 commented 7 months ago

The problem is that the Qubes OS was installed in vanilla mode (with current kernel 5.15). If it was installed with kernel latest as suggested here: https://www.qubes-os.org/news/2023/03/15/dasharo-fidelisguard-z690-first-qubes-certified-desktop/#special-note-regarding-the-need-for-kernel-latest

When the kernel latest is installed as instructed here: https://forum.qubes-os.org/t/installing-linux-kernel-6-x-on-r4-1-2/17969/3 the resume worked without issues. The kernel-latest is required for the Qubes OS to operate properly on such new hardware. Especially when it comes to resume. The drivers have to properly reinitialize the devices, but first the drivers must know the devices (which is only possible with newest kernel).

pietrushnic commented 7 months ago

@macpijan @BeataZdunczyk, we are wasting time here if validation procedures do not consider the fact pointed out by @miczyg1. Can we suggest improvement which would avoid such a situation in future? Maybe there should be clear information on how a given OS should be installed on a given system or have some template that rarely diverges from the standard, but that would cover the above situation.

macpijan commented 7 months ago

Yes, we need public OS installation procedures. We have some parts on preparing automatic installers, still not public, and not covering all cases as shown above.

Ideally, we would close this issue with MR adding such documentation.

This particular case sounds like a necessary post-install step to be performed on this board. This can be documented as we have some post-install steps for laptops: https://docs.dasharo.com/unified/clevo/post-install/

The generic OS installation document can have a reminder to check for platform-specific post-install steps.

pietrushnic commented 7 months ago

I'm very happy there is a plan for that. Maybe instead of wasting time replying to issues that used incorrect installation procedures, @miczyg1 could start such documentation or maybe @filipleple could do that with @miczyg1 as reviewer.

miczyg1 commented 7 months ago

This particular case sounds like a necessary post-install step to be performed on this board. This can be documented as we have some post-install steps for laptops: https://docs.dasharo.com/unified/clevo/post-install/

Post-install step might not be enough. Even though I managed to install kernel-latest on already installed vanilla Qubes OS R4.1.2, the kernel-latest did not propagate to sys-* VMs. So the network qubes still did into work properly with WiFi. best way is to install using kernel-latest right from the start by selecting the right GRUB entry when booting Qubes OS installer.

filipleple commented 7 months ago

I can now confirm that after reinstalling Qubes with the latest kernel, the issue is resolved.