I had a topic about DNS and Ethernet detach/attach, and I was asking even from PFSense, and they said that 1.1.1.2 and 1.0.0.2 are not verified for certificates I was not sure if I should put the URL,
The website is not displayed, even though it is allowed on the PFSense side. | Netgate Forum 1700367724944
This one is actually verified.
So I changed the DNS address on the PFSense side to 1.1.1.1.1 and 1.0.0.0.1 and I was able to communicate again without problems, but now my PC freezes. I waited for about 10 minutes and it didn’t get better, so I pressed and held the power button to force a shutdown, but I’m wondering if the dom0 has been hacked, both in terms of the DNS issue and the freezing (I don’t communicate(but apt install i used) with the template and I don’t touch the dom0 nearly as much).
Perhaps others are perfectly fine with the default nameserver settings, but is there somewhere I can get a log of the freeze, etc.? However, after booting and putting in the password for the disk, I think I got a message saying something about USB (I’ve been given a device that QubesOS won’t run without USB).
Your Qubes OS freeze shouldn’t be related to DNS settings.
You can check the logs in dom0 terminal to search for the reason of the freeze:
sudo journalctl
1 Like
Thanks. I entered the command and logged the 19th when the problem occurred. There seems to be a lot of EXCEPTION errors of some sort.
freeze.log (57.0 KB)
Aug 19 23:22:09
Are you sure that you’ve copied the correct part of log? It seems to me that it’s an old part of log and it seems to be shutdown correctly and not with hard reset.
Check the log from the end of file to the date and time when your Qubes OS froze.
1 Like
Ah! I was too unfamiliar with the English month and made a mistake - I extracted the error log as of Nov 19. Hopefully this will tell you something…
fr.log (106.2 KB)
I don’t see any freeze on Nov 19, maybe you had it on Nov 18 in the log because of system timezone?
1 Like
Extracted Nov18 logs. Hmmm nothing happened…
nov18.log (106.6 KB)
DVM
November 22, 2023, 2:06pm
8
I think it might be better to get logs based on boot time. In dom0, do journalctl --list-boot
, check the dates in “first entry”, take note of the IDX and then run journalctl -b <IDX> > boot.log
1 Like
Sorry, I was busy around this time of year and it is possible that the freeze was on a date other than the one I posted, I had 7 boots on the 15th, so this would be the one where I had to reboot many times due to DNS issues. The next time it was booted was at 6:42:03 on 11-17, so this may be the date.
So the DX BOOT ID is the time when the switch button was pressed to boot or the screen came on after rebooting? If so, the problem occurred between 2023-11-15 17:44:11 and 2023-11-17 06:42:03.
11-15last.log (435.3 KB)
Seems to be some problem with suspend:
opened 02:22AM - 30 Mar 22 UTC
closed 12:37PM - 07 Aug 22 UTC
T: bug
R: duplicate
P: default
hardware support
C: power management
### Qubes OS release
4.1
### Brief summary
Basically, the machine can't suc… cessfully resume from S3 sleep under Qubes OS. ```amdgpu``` (I think...) cannot successfully resume VGA controller from S3 sleep, causing Xorg to coredump, and machine needs to be hard reset.
### Steps to reproduce
1. Boot machine
2. Initiate S3 sleep
3. Resume from S3 sleep.
### Expected behavior
The machine wakes up, and doesn't implode.
### Actual behavior
1. The display successfully resumes to ```xscreensaver``` for 2-3 seconds.
a. If audio was playing before S3 suspend, it now continues playing fine for 2-3 seconds.
2. The screen flashes like it is changing resolution.
a. If audio was playing before S3 suspend, it now becomes incredibly choppy and stutters.
3. The screen shows whatever was on the screen at Step 1, but the cursor cannot be moved.
4. Steps 2 & 3 repeat 4-6 times.
5. The screen flashes again.
6. The screen backlight stays on, but every pixel is black.
a. If audio is playing before S3 suspend, it now stops.
7. Cannot switch to a TTY (Ctrl + Alt + F2).
8. The machine appears to have imploded, and a hard reset is needed.
### Additional information
- Hardware: GPD Win Max 2021 - AMD Ryzen 7 4800U with AMD Radeon Vega 8 (4000) Integrated Graphics
-
- S3 sleep/resume works perfectly in the Mainline Kernel, as well as on every single other Linux distro I have tried (even the obscure ones) that are not based on Xen.
* I'm not saying Xen is the issue, but it's worth noting that the machine is actually capable of resuming successfully from S3 sleep, so it is definitely not a hardware issue...
- Videos of machine sleeping and resuming:
* kernel-latest-5.16.15: https://user-images.githubusercontent.com/66879804/160737835-d93608a4-ecdf-4b99-aa1c-eaa7e79c0db5.mp4
* Audio does not resume because audio hardware is in ```sys-usb```, and it doesn't seem to get passed through before ```Xorg``` implodes.
* Mainline Kernel 5.17.1 built with Qubes OS config and patches added in: https://user-images.githubusercontent.com/66879804/160737859-b2c086ab-f641-4b82-a55d-62fd0cc9f4eb.mp4
* Audio does not resume because audio hardware is in ```sys-usb```, and it doesn't seem to get passed through before ```Xorg``` implodes.
- The machine is currently not used for anything other than Qubes OS testing. Happy to provide:
- Logs
- Output of any commands
### Final Word
A massive thank you to all the Qubes OS team. Your work is endlessly appreciated!
opened 07:47AM - 02 Aug 22 UTC
T: bug
C: desktop-linux-xfce4
P: default
hardware support
needs diagnosis
C: power management
affects-4.1
[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/)
#… ## Qubes OS release
R4.1 kernel 5.18.9
### Brief summary
After I have tried logging out in dom0 in #7602, I found that each time I suspend, the screen goes to early booting screen.
When I inspect in dom0 log I found out that Xfce4-session crashes.
```
dom0 systemd-coredump[42813]: Process 42261 (xfce4-session) of user 1000 dumped core.
Stack trace of thread 42261:
#0 0x0000599648a8b9d9 xfsm_manager_dbus_suspend (xfce4-session + 0x279d9)
#1 0x00007ce2d3630af0 ffi_call_unix64 (libffi.so.6 + 0x6af0)
#2 0x00007ce2d36302ab ffi_call (libffi.so.6 + 0x62ab)
#3 0x00007ce2d421438d g_cclosure_marshal_generic (libgobject-2.0.so.0 + 0x1438d)
#4 0x00007ce2d421388a g_closure_invoke (libgobject-2.0.so.0 + 0x1388a)
#5 0x00007ce2d4225e7e signal_emit_unlocked_R.isra.0 (libgobject-2.0.so.0 + 0x25e7e)
#6 0x0000599648a80a5c _xfsm_dbus_manager_skeleton_handle_method_call (xfce4-session + 0x1ca5c)
#7 0x00007ce2d4384ff1 g_dbus_interface_method_dispatch_helper (libgio-2.0.so.0 + 0x12bff1)
#8 0x00007ce2d436abe2 call_in_idle_cb (libgio-2.0.so.0 + 0x111be2)
#9 0x00007ce2d412345b g_idle_dispatch (libglib-2.0.so.0 + 0x4e45b)
#10 0x00007ce2d412778f g_main_context_dispatch (libglib-2.0.so.0 + 0x5278f)
#11 0x00007ce2d4127b18 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52b18)
#12 0x00007ce2d4127e33 g_main_loop_run (libglib-2.0.so.0 + 0x52e33)
#13 0x00007ce2d485c99d gtk_main (libgtk-3.so.0 + 0x25c99d)
#14 0x0000599648a7a7e1 main (xfce4-session + 0x167e1)
#15 0x00007ce2d3f0e082 __libc_start_main (libc.so.6 + 0x27082)
#16 0x0000599648a7aa6e _start (xfce4-session + 0x16a6e)
Stack trace of thread 42311:
#0 0x00007ce2d3fdd86f __poll (libc.so.6 + 0xf686f)
#1 0x00007ce2d4127aae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae)
#2 0x00007ce2d4127be3 g_main_context_iteration (libglib-2.0.so.0 + 0x52be3)
#3 0x00007ce2d4127c31 glib_worker_main (libglib-2.0.so.0 + 0x52c31)
#4 0x00007ce2d41517f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2)
#5 0x00007ce2d40bc432 start_thread (libpthread.so.0 + 0x9432)
#6 0x00007ce2d3fe86d3 __clone (libc.so.6 + 0x1016d3)
Stack trace of thread 42312:
#0 0x00007ce2d3fdd86f __poll (libc.so.6 + 0xf686f)
#1 0x00007ce2d4127aae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae)
#2 0x00007ce2d4127e33 g_main_loop_run (libglib-2.0.so.0 + 0x52e33)
#3 0x00007ce2d437b6aa gdbus_shared_thread_func (libgio-2.0.so.0 + 0x1226aa)
#4 0x00007ce2d41517f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2)
#5 0x00007ce2d40bc432 start_thread (libpthread.so.0 + 0x9432)
#6 0x00007ce2d3fe86d3 __clone (libc.so.6 + 0x1016d3)
Stack trace of thread 42313:
#0 0x00007ce2d3fe313d syscall (libc.so.6 + 0xfc13d)
#1 0x00007ce2d4176616 g_cond_wait_until (libglib-2.0.so.0 + 0xa1616)
#2 0x00007ce2d40f74a1 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x224a1)
#3 0x00007ce2d40f7ae6 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x22ae6)
#4 0x00007ce2d4152199 g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7d199)
#5 0x00007ce2d41517f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2)
#6 0x00007ce2d40bc432 start_thread (libpthread.so.0 + 0x9432)
#7 0x00007ce2d3fe86d3 __clone (libc.so.6 + 0x1016d3)
```
Also core from xss-lock
```
dom0 systemd-coredump[42826]: Process 42604 (xss-lock) of user 1000 dumped core.
Stack trace of thread 42604:
#0 0x00007731255dcfc2 g_logv (libglib-2.0.so.0 + 0x59fc2)
#1 0x00007731255dd233 g_log (libglib-2.0.so.0 + 0x5a233)
#2 0x0000646ff4771be5 screensaver_event_cb (xss-lock + 0x4be5)
#3 0x0000646ff4771cdf xcb_event_dispatch (xss-lock + 0x4cdf)
#4 0x00007731255d578f g_main_context_dispatch (libglib-2.0.so.0 + 0x5278f)
#5 0x00007731255d5b18 g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52b18)
#6 0x00007731255d5e33 g_main_loop_run (libglib-2.0.so.0 + 0x52e33)
#7 0x0000646ff4770ecd main (xss-lock + 0x3ecd)
#8 0x00007731253a3082 __libc_start_main (libc.so.6 + 0x27082)
#9 0x0000646ff477102e _start (xss-lock + 0x402e)
Stack trace of thread 42623:
#0 0x000077312547286f __poll (libc.so.6 + 0xf686f)
#1 0x00007731255d5aae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae)
#2 0x00007731255d5e33 g_main_loop_run (libglib-2.0.so.0 + 0x52e33)
#3 0x00007731258296aa gdbus_shared_thread_func (libgio-2.0.so.0 + 0x1226aa)
#4 0x00007731255ff7f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2)
#5 0x000077312529a432 start_thread (libpthread.so.0 + 0x9432)
#6 0x000077312547d6d3 __clone (libc.so.6 + 0x1016d3)
Stack trace of thread 42614:
#0 0x000077312547286f __poll (libc.so.6 + 0xf686f)
#1 0x00007731255d5aae g_main_context_iterate.constprop.0 (libglib-2.0.so.0 + 0x52aae)
#2 0x00007731255d5be3 g_main_context_iteration (libglib-2.0.so.0 + 0x52be3)
#3 0x00007731255d5c31 glib_worker_main (libglib-2.0.so.0 + 0x52c31)
#4 0x00007731255ff7f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2)
#5 0x000077312529a432 start_thread (libpthread.so.0 + 0x9432)
#6 0x000077312547d6d3 __clone (libc.so.6 + 0x1016d3)
Stack trace of thread 42616:
#0 0x000077312547813d syscall (libc.so.6 + 0xfc13d)
#1 0x0000773125624616 g_cond_wait_until (libglib-2.0.so.0 + 0xa1616)
#2 0x00007731255a54a1 g_async_queue_pop_intern_unlocked (libglib-2.0.so.0 + 0x224a1)
#3 0x00007731255a5ae6 g_async_queue_timeout_pop (libglib-2.0.so.0 + 0x22ae6)
#4 0x0000773125600199 g_thread_pool_thread_proxy (libglib-2.0.so.0 + 0x7d199)
#5 0x00007731255ff7f2 g_thread_proxy (libglib-2.0.so.0 + 0x7c7f2)
#6 0x000077312529a432 start_thread (libpthread.so.0 + 0x9432)
#7 0x000077312547d6d3 __clone (libc.so.6 + 0x1016d3)
```
### Steps to reproduce
1. log out in dom0 after booting up machine
2. suspend
### Expected behavior
suspension does not make any process in dom0 crash
### Actual behavior
xfce4-session and sometimes xss-lock crashes.
1 Like
Thanks. I can’t read the logs completely, but yes, I always put QubesOS in suspend mode and went to bed, so it may have been something wrong with it as it kept doing that.
As I recall, the screen behaved in such a way that it went off once and then came back on. Also, at this time, they were trying to start the task manager in windows, but I did not know the shortcut key for this, so I will try to start the task manager next time (TTY (Ctrl + Alt + F2)).
So, if I can start the task manager, I will try to hit some commands to collect the logs immediately, but I would like to know if there is something better.
I don’t know of a better way.
If the issue happens again you can collect the logs and post them in the existing github issue if it looks to be the same as your own or create a new one so Qubes OS developers can look into it.
1 Like
Thank you. If the same problem recurs again, I will report the situation and error to the github issue above.