Alex Smirnoff

Or could be someplace else! I checked the suspicious commit and now I am unsure it can affect the script behavior this way, but it was the only one that...

Interesting, interesting. I confirm exactly this patch breaks things. Before patch: conditions: there is no dnat-dns chain in qubes table, first run of the script: emits this error: Error: No...

> But ultimately post-boot `dnat-dns` does get created Does your minimal qube have systemd-resolved? Mine does not and I think it triggers the issue.

Hm hm interesting. However, something is still not right, and it is triggered exactly by this tiny patch (i imported the old script to the new system, and it works)....

I tried to check a few more things, found nothing. I have readonly root. With rw root, there is no difference. Are you sure you do not have systemd-resolved? My...

Indeed, when I created all the regular qubes-firewall tables the system went back to normal. The service was disabled (no idea why, it is some legacy code from abarinov@ )

Nothing! It just says "suspending" out of the blue and I found no way to inhibit it. There are weirdly high counters on gpe66 and gpe6E indeed, but if i...

Ha! But when I changed HandleLidSwitch=ignore in the rescue shell, it helped! A bit counterintuitive, since disabling acpi interrupts did not change this behavior.

Indeed! It is a weird machine and probably this is a malfunction. But I do not know where the sensor is. And why regular Ubuntu and Windows did not respond...

Interesting. I disabled "close lid" action in logind.conf. But when I _open_ it after manual suspend, it still wakes up properly!