Edit: This issue was caused due to a plaintext file accidentally created in the policy directory. Still an interesting read as does bring question to the ability to easily break major QubesOS functions and perhaps a need for additional self resolve and mitigation mechanisms.
Global Paste function is no longer working as I can copy into the clipboard and the notification displays the bytes however once attempting to paste in another Qube no notification is displayed and no paste occurs.
All keys work, no issue with keyboard. Attempted to adjust clipboard function for testing however unable due to error â/user/lib/qubes0-rpc-multiplexerâ,âpolicy.Replace+50-config-clipboardâ,âdom0â]â returned non-zero exit status 1.â
All configs are set to default, no changes were made.
Clipboard policies:
All Qubes will always be allowed to paste into clipboard of All Qubes.
TYPE:ADMINVM will always be allowed to paste into clipboard of ALLQUBES
So many issues suddenly after this recent update.
When trying to copy or move my files, etc to other vms it no longer prompts up to select the vm, opening or editing in another dispo vm option does nothing anymore and of course the whole issues with the clipboard function.
Been using Qubes for quiet a while now and have never had these issues until these recent updates.
Most probably you have an error in one of your policy files in /etc/qubes/policy.d/ in dom0.
Did you edit any policy files?
Run this command in dom0 terminal:
journalctl -f -n0
Then try to paste the text from the Global Clipboard to any qube and see if itâll give you an error about qrexec policy in the journalctl output.
Hi, thanks for the constant swift assistance.
I tried the cmd requested and no log is displayed when attempting to copy and paste as requested. Copy function works, doesnât log anything however paste function simply does nothing.
Attempted with the file access stuff and same thing doesnât log anything.
I did try and close a qube as a precaution and it then logged the shutdown.
Regarding the config adjustment I had only adjusted the default policy to allow per the link you had provided me previously. Prior to changing the policy I had noticed that this was occurring so thought it would help if I just powered off and then powered on the device.
Not certain how the Whonix policy couldâve affected this at all.
I had also noticed that upon logging in I had 9 tabs of the screenshot function open in dom0 which was also strange.
Had changed to the following:
whonix.SdwdateStatus + @tag:anon-gateway @default allow notify=no
Output for the qvm-copy cmd states Request Refused.
In-regards to the logs from the jounralctl -f -n0 cmd doesnât causes anything to display.
However I keep seeing logs related to Tor appearing.
Tor[790] : New Control connect opened. (repeated 3 times)
sdwate-start-anondate-set-file-watcher and just repeated stuff about Tor consensus.
Would do this with a start log, attempt a few times and then proceed with exiting and then exits and just repeats.
I would try to display the entire log but canât as cant even attach external devices anymore.(To copy over)
The above is the only log and its repeats, which if correct is not related.
I changed the allow back to deny and restarted the device.
Issues still persistent with the file access, clipboard and device attach issue and still having that weird thing with the spam screenshot application populating at the start of login.
Still not getting denied error(Newstatus issue) notif even after reverting the change and restarting the device.
I just donât understand how and I canât see anything that would be considered âbreakingâ.
Journalctl -b I can see a firmware bug : TSC doesnt count with P0 frequency.
ACPI BIOS Warning bug: Incorrect checksum in table [BRGT] -xF8, shouble be 0x6B
Fireware Bug : ACPI MWAIT C-state 0x0 not supported by HW (0x0)
âusb3-1: Device is not authorized for usuageâ
Just an insane amount to go throught and I cant specifically tell what is a major issue that could be cause this and to many issues through hundreds of lime to type out all
PAM unable to dlopen(/user/security/pam_sss.so): cannot open shared objects file
kaudit_printk_skb: 88 callbacks suppressed.
i2c_designware AMDI0010:01 ctroller timeout
GetManagedObjects( ) failed: org.freedesktop.DBus.Error.NameHasNoOwner
dom â5â still hold more memry than have assigned.
Rest mainly seem to be repeats.
My primary issue is why would an entire update break the entire OS, been using it for months without major issues to this degree. Granted there are issues but they minor however this is just breaking and one needs to beable to functionally use the OS without it suddenly not working to this degree. Having the time to resolve is very difficult,
I have even tried to restore to a backup and that just shows error which would mean if I cannot find the point of why all the cross functionality of the OS is not work then will have to do everything from scratch which isnât ideal. Im just confised to why I am specifically having this as i dont do major changes especially with global functions and the most Ive done has morphed a cloned template of Debian to Knicksecure which was done significant time ago while still constantly updating and suddenly now issues with denied notif which hopefully is fix now but these odd behaviours and broken features with dom just from it is beyond me.
You need to check the messages related to Qubes services in the log. Search for the err and fail strings.
I guess something in dom0 could break if the dom0 update was interrupted or maybe there was not enough free space in dom0 root to install some of the updates.
If youâve reverted the polices back to the default, check the policy GUI to make sure there are no errors. Also, check the status of systemctl status qubesd
Are you refer to the policy editor GUI?
Status shows active. Only issue seen which I did print out in my reply is "PAM unable to delopen(user/lib64/security/pam_ss.so): /user/ib64/security/pam_sss.so: cannot open shared object file: No such file or directory. " & âPAM adding faulty moduel /user.lib64/security/pam_sss.soâ
Yes the one policy I changed relating to 80-Whonix policy I change the @default back to deny as previously it start displaying and spamming this notification since yesterday however did seem to resolve that specific issue and has not persisted after reverting the change and restarting the device.
Since your copy&paste doesnât work, I assume you had to type these rules in the forum, but please double check if youâre actually missing a dot in the second one:
Can confirm there is more than enough storage and the update was interupted. Not atleast to my knowledge.
/var/log/dnf.log:
* DDEBUG Errors occured during transaction.
* DEBUG Failed: Kernel-qubes-vm-100:6.6.29-1.qubes.fc37.x86_64
* Crtitcal error: Transaction failed (initialized logs after.)
/var/log/dnf.rpm.log:
* file modules.devname: removed failed : No such file or directory
* file modules.builtin.bin: remove failed : No such file or directory
* file modules.builtin.alias.bin: remove failed : No such file or directory
* This kernal version is used by atleast one VM, cannot remove error: preun(kernel-ques-vm-1000:6.6.29-1.qubes.fc37.x86_64) scriptlet failed, exit status 1
* ERROR in PREUN scriptlet in rpm pakage kernel qubes vm.
* another error saying remove of kernel failed.
So the obvious just shows that one or more vms using an older kernel which will give a look as the global is for the latest kernel to be used. However this shouldnt be causing this issues either.
When looking at logs(journalctl -b) for usbguard it does state that the permission check on policy files is turned off.
* qubes-qrexec-policy-daemon.serice: Failed with result 'exit-code'.(before dom0 startup)
*
Apologies for the difficult quality of the image. I had to use my cloud server in order to import it onto this VM.
Easier than typing it out. May be cause of some issue relating to the ones faced.
Fix the error in /etc/qubes-rpc/policy/whonic.NewStatus file on line 2.
Also why is it named whonic.NewStatus and not whonix.NewStatus?
Did you create this file yourself?
