Re: [qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

[Vít Šesták]

Qubes123, that's an interesting finding. AFAIU, the CPUID check is rather a 
sanity check – it verifies that the microcode is loaded properly. I also, this 
should be no issue if Qubes provides a fresh microcode…

(And maybe it can cause crash if you suspend after BIOS update, provided that 
the BIOS contains a newer microcode.)

Regards,
Vít Šesták 'v6ak'

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/AE8C3618-A803-4AF8-A65B-B4252829A309%40v6ak.com.

[qubes-users] Re: HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

[qubes123]

On Thursday, December 19, 2019 at 12:13:57 AM UTC, Claudia wrote:
>
> This is R4.1 build 20191013
>
> It works pretty well, definitely better than 4.0, but there are some weird 
> boot issues. If I let it boot with everything as default, it will boot loop 
> before reaching the disk password screen. I found I can get it to boot 
> successfully if I add to the Xen commandline
> noreboot=1 loglvl=all
> and remove from the linux commandline
> rhgb quiet rd.qubes.hide_all_usb
>
> Still working on narrowing down which of those is/are responsible for 
> fixing the problem (I can't figure out why any of them would).
>
> Improvements since 4.0:
> Screen power management works - brightness controls, and screen poweroff 
> after inactivity (in 4.0
> it would just blank but not power off)
> Audio works, which it did not work in 4.0 even after many days of 
> troubleshooting
> amdgpu works correctly - doesn't freeze when booting without nomodeset
> Multimedia keys - not sure if they worked in 4.0 or not
>
> Still working:
> UEFI mode
> wifi
> touchpad
> keyboard
>
> Still NOT working:
> Suspend/resume
>
Suspend/resume problem is most likely caused by a recently added security 
feature in Xen, that checks CPUID after resume with the previously (at boot 
time) known CPUID. This is to ensure, that the CPU microcode level - along 
with the resulting Spectere/Meltdown etc. mitigations - still persist after 
system resume and there are no features missing.
For many AMD systems (eg. Trinity/Richland) CPUID changes after suspend 
(some of the high bits), resulting in Xen Panic (see 
xen/arch/x86/acpi/power.c). So, more investigation would be needed to check 
why the CPUID bits are changing after resume and whether it had any 
security implications or not.
For the time being - if you accept the possible security implications - you 
can disable that check eg. by commenting the panic line out after 
"recheck_cpu_features" in the above mentioned power.c file, compile xen for 
dom0 via qubes builder and test it in your system.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/dad273bd-6d25-4305-9458-b153405bbd62%40googlegroups.com.

[qubes-users] Building gui-agent-linux failed while building Archlinux template.

[Tae Hwan Kim]

Hello guys I need a help.
I am working on building archlinux template 
. 
I am using Qubes 4.0 and trying to make archlinux template.
But while building gui-agent-linux. got some errors like this.
-> Building gui-agent-linux (archlinux) for archlinux vm (logfile: 
build-logs/gui-agent-linux-vm-archlinux.log)
--> build failed!
 ==> Updating trust database...
gpg: next trustdb check due at 2020-05-31
:: Running post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...
:: Synchronizing package databases...
 core is up to date
 extra is up to date
 community is up to date
 multilib is up to date
 qubes is up to date
:: Starting full system upgrade...
 there is nothing to do
--> Archlinux dist-package (makefile)
  --> Building package in /home/user/qubes-src/gui-agent-linux
sudo BACKEND_VMM=xen  chroot "/home/user/qubes-builder/chroot-vm-archlinux" 
su user -c 'cd "/home/user/qubes-src/gui-agent-linux" && cp 
archlinux/PKGBUILD* ./ && env http_proxy="" makepkg --syncdeps --noconfirm 
--skipinteg'
==> Making package: qubes-vm-gui 4.0.27-9 (Sun Dec 22 22:53:06 2019)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Installing missing dependencies...
error: target not found: xf86dgaproto
==> ERROR: 'pacman' failed to install missing dependencies.
==> Missing dependencies:
  -> pulseaudio
  -> xorg-server-devel
  -> xorg-util-macros
  -> xf86dgaproto
  -> libxcomposite
  -> libxt
  -> qubes-vm-gui-common
==> ERROR: Could not resolve all dependencies.
make[2]: *** 
[/home/user/qubes-builder/qubes-src/builder-archlinux/Makefile.archlinux:121: 
dist-package] Error 8
make[1]: *** [Makefile.generic:180: packages] Error 1
make: *** [Makefile:226: gui-agent-linux-vm] Error 1

And I am researching for this problem, but I can't find.
What am I missing?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c72d1dbc-7b89-4658-bafb-f193a12aaf05%40googlegroups.com.

Re: [qubes-users] Installation Failure of Sagemath - More space needed on the filesystem

['Jackie' via qubes-users]

Ray Joseph:


I am trying to install Sagemath using:

sudo dnf install sagemath

which failed.

Template: fedora-30

This vm was started with default private/system storage 7 GB/10 GB.

Initial memory 400 MB

Max memory 4000 MB

VCPUs no.: 2

Mode:  PVH

The installation transaction summary reports:

Install 893 packages

Total download size:  1.1 G

Installed size: 4.1 G

I answer yes to install.

The system progresses through a portion of the installation and ends with:

Error Summary

Disk Requirements:

   At least 1506GB more space needed for the / filesystem

The second to the last report line is the installation of sagetwx which
needs 1504MB.  Then

the last entry is sagemath which needs 1506MB.

The last entry memory requirement matches the error report for 1506MB.
More may be required.

Qube Manager showed Disk usage for the VM to be zero.  I closed the manager
and reopened.  It then showed 216.78 MiB.  [Is there a way to make this
update in realtime?]

The system storage is (10 GB) is grayed out.  I don't see how to change it
but I don't expect that to be a solution.


Hi,

It sounds like you just need to increase the template's root filesystem 
size ("system storage"). You should be able to change this in the qube 
settings window. (Only for the template, in a template based VM it will 
be grayed out.)


https://www.qubes-os.org/doc/resize-disk-image/

These instructions are for Qubes 4.0. If you're using 3.2 the process is 
different.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e1cc71e3-0098-ea53-e22f-5103aa6e287e%40danwin1210.me.

[qubes-users] Qubes/Xen doesn't comply with IOMMU grouping rules for PCI passthru

[Claudia]

I'm very new to all this iommu stuff, but as I understand it, devices in the 
same iommu group are
supposed to be treated as a single unit, meaning if any of them are assigned to 
a VM then they all
must be assigned to the same VM. This is because those devices cannot be 
isolated from each other
-- they can communicate directly without going through the IOMMU at all, for 
example.

This not only creates obvious security holes, but can also cause compatibility 
problems. For
example, devices in different VMs will have different perspectives of system 
memory. [3] Or 
something like that. Like I said, I'm still trying to wrap my head around it.

Point is, the entire group is supposed to be treated as a single unit. 
Linux/KVM enforces this, Xen
does not, I'm not sure about any other platforms. [1]

This caused a very sneaky problem on my machine. My USB controllers are in the 
same group as my
GPU, sound card, and SATA controller. So when sys-usb (or 
rd.qubes.hide_all_usb) takes over those
two USB controllers, everything stops working. [4] It was quite difficult to 
trace. It would have
been much easier to diagnose if grouping was enforced somewhere. I would much 
rather have an error
in my logs about being unable to assign USB controllers, than have my whole 
screen freeze up with
no indication why. (I got lucky that it just crashed; if something interferes 
with your SATA 
controller's address space it can cause disk corruption. [5])

I don't really know who's at fault here. Qubes? Xen? AMD? Dell?

Unfortunately, Qubes has no way of knowing anything about iommu grouping 
because Xen takes over the
IOMMU (and therefore grouping is not visible in dom0). [2] So probably the only 
way Qubes could
enforce grouping is by some kind of heuristic. For example, assume all 
functions of a device are 
grouped. Or, assume all devices on a hub are grouped. Or just disable the USB 
Qube option on AMD 
systems entirely, or warn the user that it may cause serious problems that are 
hard to diagnose.

As for fixing the actual problem, that is, grouping them in a more sensible way 
so that the GPU and
USB controllers can be isolated for example, can only be done in a firmware (or 
microcode?) update
by the vendor, if at all. There are some hacks for KVM to spoof the grouping 
restrictions (which
Xen doesn't enforce in the first place), but they don't solve the underlying 
problem. VFIO seems
like it could work (by emulating some IOMMU functionality in software), but I 
don't know if it's
supported by Xen.

I'm guessing part of the reason this problem doesn't usually come up on Intel 
systems is because of
the Xen option iommu=no-igfx. This means that the integrated GPU is always 
exempt from IOMMU
control altogether, but this option is Intel-specific and has no AMD 
equivalent. However, that 
doesn't do anything about other devices such as sound cards or SATA 
controllers. Intel systems
seem to just to have better grouping usually (or, are less likely to crash when 
grouping rules are
violated). [6]

At least that's my understanding so far. 

Thoughts? Is there anything Qubes can do to do avoid splitting up IOMMU groups? 
Is there anything
Qubes *should* do? Should Qubes attempt to guess the IOMMU groups before taking 
over devices?
Should the USB Qube option be disabled on AMD systems (you can still manually 
set up sys-usb of
course)? Should we just blame Xen for not enforcing IOMMU groups in the first 
place? 

[1] https://lists.gt.net/xen/devel/345279#345279
[2] http://xen.1045712.n5.nabble.com/IOMMU-group-dissapear-in-XEN-td5737357.html
[3] https://vfio.blogspot.com/2014/08/iommu-groups-inside-and-out.html
[4] https://www.mail-archive.com/qubes-users@googlegroups.com/msg31494.html
[5] 
http://xen.1045712.n5.nabble.com/VGA-passthrough-with-USB-passthrough-td5738340.html
[6] 
https://hardforum.com/threads/ryzen-and-iommu-groups-is-this-ever-going-to-get-fixed.1944064

---

Dell Inspiron 5575, AMD Ryzen 5 2500U, Qubes R4.1 booted without Xen: 

# lspci
00:00.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Root 
Complex
00:00.2 IOMMU: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 IOMMU
00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 
00h-1fh) PCIe Dummy Host
Bridge
00:01.6 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP 
Bridge [6:0]
00:01.7 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 PCIe GPP 
Bridge [6:0]
00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Family 17h (Models 
00h-1fh) PCIe Dummy Host
Bridge
00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal 
PCIe GPP Bridge 0 to
Bus A
00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2 Internal 
PCIe GPP Bridge 0 to
Bus B
00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61)
00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)
00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Raven/Raven2

[qubes-users] AppVms being killed on resume due to clock skew too large

[mmoris]

Hello,

I've been struggle with this for months now.
Whenever there's a resume from suspend some random AppVms are killed. Although 
this doesn't happen all the time it happens often enough on resume sufficiently 
to indicate an issue.
It seems that the clock skew is too large resulting in a kernel panic that 
kills the AppVM as the error below shows.

Is anyone experiencing the same issue? Is there any solution to this?

Thank you in advance.

[38009.358471] clocksource: timekeeping watchdog on CPU0: Marking clocksource 
'tsc' as unstable because the skew is too large:
[38009.358521] clocksource: 'xen' wd_now: 2697b2c28a19 wd_last: 2696858155d9 
mask: 
[38009.358558] clocksource: 'tsc' cs_now: ff40e6dd060e cs_last: 
4900d58115e2 mask: 
[38009.358594] tsc: Marking TSC unstable due to clocksource watchdog
[79151.795501] borgmatic[2418]: segfault at 6060cafd8549 ip 6060ca2ae054 sp 
7ffe9d9bbad8 error 4 in python3.5[6060ca158000+3f]
[79151.795535] Code: 08 4c 8b 5e 08 4c 89 5b f0 4c 89 4e 08 4d 89 0b 48 89 73 
e8 4c 89 43 f8 eb 92 66 90 66 2e 0f 1f 84 00 00 00 00 00 48 8b 47 08  80 a9 
00 00 00 40 75 03 31 c0 c3 53 48 8b 80 48 01 00 00 48 89
[79152.712396] general protection fault:  [#1] SMP PTI
[79152.712416] CPU: 1 PID: 2425 Comm: systemctl Tainted: G O 
4.19.84-1.pvops.qubes.x86_64 #1
[79152.712444] RIP: 0010:__pv_queued_spin_lock_slowpath+0x199/0x270
[79152.712462] Code: eb bd 83 e0 03 c1 ea 12 4c 8d 6d 44 48 c1 e0 04 41 be 01 
00 00 00 4c 8d a0 80 10 02 00 8d 42 ff 48 98 4c 03 24 c5 20 77 17 82 <49> 89 2c 
24 b8 00 80 00 00 eb 15 84 c0 75 0a 41 0f b6 54 24 44 84
[79152.712509] RSP: 0018:c96c7b60 EFLAGS: 00010002
[79152.712524] RAX: 3ffe RBX: 8880f47b0764 RCX: 0001
[79152.712544] RDX: 3fff RSI:  RDI: 8880f47b0764
[79152.712565] RBP: 8880f5b21080 R08:  R09: c9637e90
[79152.712585] R10: c96c7e20 R11: 0001 R12: 64616f6c00708019
[79152.712605] R13: 8880f5b210c4 R14: 0001 R15: 0008
[79152.712626] FS: () GS:8880f5b0() 
knlGS:
[79152.712647] CS: 0010 DS:  ES:  CR0: 80050033
[79152.712664] CR2: 7f088e3efab4 CR3: 0220a004 CR4: 003606e0
[79152.712687] DR0:  DR1:  DR2: 
[79152.712707] DR3:  DR6: fffe0ff0 DR7: 0400
[79152.712727] Call Trace:
[79152.712739] _raw_spin_lock_irqsave+0x32/0x40
[79152.712755] try_to_wake_up+0x3d/0x490
[79152.712767] __wake_up_common+0x96/0x180
[79152.712780] ep_poll_callback+0x1ac/0x2f0
[79152.712791] __wake_up_common+0x96/0x180
[79152.712803] __wake_up_common_lock+0x7c/0xc0
[79152.712819] sock_def_wakeup+0x32/0x40
[79152.712831] unix_release_sock+0x288/0x2d0
[79152.712844] unix_release+0x19/0x30
[79152.712855] __sock_release+0x3d/0xc0
[79152.712866] sock_close+0x11/0x20
[79152.712878] __fput+0xe2/0x210
[79152.712891] task_work_run+0x8a/0xb0
[79152.712903] do_exit+0x2eb/0xc30
[79152.712915] ? __do_page_fault+0x278/0x4f0
[79152.712926] do_group_exit+0x3a/0xa0
[79152.712938] __x64_sys_exit_group+0x14/0x20
[79152.716375] do_syscall_64+0x5b/0x190
[79152.716391] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[79152.716407] RIP: 0033:0x7f088fac8618
[79152.716422] Code: Bad RIP value.
[79152.716433] RSP: 002b:7fffd239eba8 EFLAGS: 0246 ORIG_RAX: 
00e7
[79152.716455] RAX: ffda RBX:  RCX: 7f088fac8618
[79152.716475] RDX:  RSI: 003c RDI: 
[79152.716496] RBP: 7f088fda58e0 R08: 00e7 R09: fee8
[79152.716516] R10: 7f088df83158 R11: 0246 R12: 7f088fda58e0
[79152.716537] R13: 7f088fdaac20 R14:  R15: 
[79152.716558] Modules linked in: ip6table_filter ip6_tables xt_conntrack 
ipt_MASQUERADE iptable_nat nf_nat_ipv4 nf_nat nf_conntrack nf_defrag_ipv6 
nf_defrag_ipv4 libcrc32c binfmt_misc intel_rapl crct10dif_pclmul crc32_pclmul 
crc32c_intel ghash_clmulni_intel xen_netfront intel_rapl_perf snd_pcm snd_timer 
snd soundcore pcspkr xen_netback u2mfn(O) xen_gntdev xen_gntalloc xen_blkback 
xen_evtchn parport_pc xenfs ppdev xen_privcmd lp parport overlay xen_blkfront
[79152.716680] ---[ end trace 1f4d28c382e93215 ]---
[79152.716703] RIP: 0010:__pv_queued_spin_lock_slowpath+0x199/0x270
[79152.716721] Code: eb bd 83 e0 03 c1 ea 12 4c 8d 6d 44 48 c1 e0 04 41 be 01 
00 00 00 4c 8d a0 80 10 02 00 8d 42 ff 48 98 4c 03 24 c5 20 77 17 82 <49> 89 2c 
24 b8 00 80 00 00 eb 15 84 c0 75 0a 41 0f b6 54 24 44 84
[79152.716768] RSP: 0018:c96c7b60 EFLAGS: 00010002
[79152.716782] RAX: 3ffe RBX: 8880f47b0764 RCX: 0001
[79152.716803] RDX: 3fff RSI:  RDI: 8880f47b0764
[79152.716823] RBP: 8880f5b21080 R08:  R09: c9

Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

[Claudia]

December 22, 2019 5:45 PM, "Vít Šesták"  wrote:

> Helllo,
> 
> Dec 22, 2019 15:17:27 Claudia :
> 
> 
>> I don't know which step -- unbinding xhci_pci, or binding pciback -- 
>> actually causes the crash in
> this case. I can say, however, that one of them does cause an immediate 
> crash, before sys-usb ever
> starts or has a chance to take over the USB controllers.
> 
> That (and the specific script) is an interesting finding. Maybe it would be 
> possible to run the
> commands one-by-one to see which one crashes the system.
> 

I think I might try that sometime, just out of curiosity. 

> BTW, could you confirm that the USB Controller is an AMD one? This could be 
> helpful for anyone
> wanting a Qubes laptop with AMD.
> 

Yes, as far as I can tell.

03:00.3 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 
[1022:15e0]
03:00.4 USB controller [0c03]: Advanced Micro Devices, Inc. [AMD] Raven USB 3.1 
[1022:15e1]

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bdc095fbe5db7ccce547c6d1e09c%40disroot.org.

Re: [qubes-users] Ghost in the machine?

['Chökie Gyaltsen' via qubes-users]

Thank you for your answers awokd,

Some of the issues were solved, below in bold the errors still happening.

Dec 15 20:52:30 dom0 kernel: Linux version 4.19.86-1.pvops.qubes.x86_64 
(user@build-fedora4) (gcc version 6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)) #1 
SMP Sun Dec 1 07:16:00 UTC 2019

> > Dec 15 20:52:30 dom0 kernel: Command line: placeholder 
> > root=/dev/mapper/qubes_dom0-root ro rd.lvm.lv=qubes_dom0/root 
> > rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 plymouth.ignore-serial-con
> > ( is it possible to disable alpha support? i Have a skylake 9th gen ) - 
> > later there is an entry stating that it taints the kernel
> 

> Possibly. Keep in mind dom0 runs Fedora 25, so does not have newer
> drivers. In most cases, it does not matter. You could try to remove it
> and see what happens. On this and your other hardware related questions,
> you could also try booting a newer version of Qubes (i.e. 4.0.2rc3) or
> another distribution like Debian 10 on the same hardware and
> cross-referencing logs.>

Thank you, i removed the alpha_support and with that the gtk errors i was 
having vanished along with the tainted kernel messages.
Also noticed improvement of the speed of the graphics. Things appear to move 
smoother and faster screen. Does that make sense?
The machine is a librem 13v3

> > Dec 15 20:52:30 dom0 systemd-modules-load[195]: Failed to find module 
> > 'uinput'
> > ( found info on kernel.org stating this module is for user input, is it 
> > normal that the module is not present? )
> 

> No, it is present on mine.

i do not know how to solve this, i have seen some answers on github related to 
permissions, are these permissions correct? This is the second reinstal of 
Qubes 4.0.2-preview3
cd /dev
ls -ltra uinput
crw-rw 1 root qubes 10, 223 Dec 22 16:29 uinput

The module seems to be running
lsmod | grep uinput
uinput 20480  0

The status of the module load service is this:

● systemd-modules-load.service - Load Kernel Modules
   Loaded: loaded (/usr/lib/systemd/system/systemd-modules-load.service; 
static; vendor preset: disabled)
   Active: active (exited) since Sun 2019-12-22 16:29:16 WET; 6min ago
 Docs: man:systemd-modules-load.service(8)
   man:modules-load.d(5)
  Process: 540 ExecStart=/usr/lib/systemd/systemd-modules-load (code=exited, 
status=0/SUCCESS)
Main PID: 540 (code=exited, status=0/SUCCESS)
    Tasks: 0 (limit: 4915)
   CGroup: /system.slice/systemd-modules-load.service

Dec 22 16:29:16 dom0 systemd-modules-load[540]: Inserted module 'uinput'
Dec 22 16:29:16 dom0 systemd[1]: Started Load Kernel Modules.

More info from journalctl
journalctl -aex --unit systemd-modules-load.service
Dec 22 16:29:12 dom0 systemd-modules-load[199]: Inserted module 'xen_gntalloc'

Dec 22 16:29:12 dom0 systemd-modules-load[199]: Inserted module 'xen_blkback'

Dec 22 16:29:12 dom0 systemd-modules-load[199]: Inserted module 'xen_pciback'

Dec 22 16:29:12 dom0 systemd[1]: systemd-modules-load.service: Main process 
exited, code=exited, status=1/FAILURE
Dec 22 16:29:12 dom0 systemd[1]: Failed to start Load Kernel Modules.

-- Subject: Unit systemd-modules-load.service has failed

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit systemd-modules-load.service has failed.

--

-- The result is failed.

Dec 22 16:29:12 dom0 systemd[1]: systemd-modules-load.service: Unit entered 
failed state.
Dec 22 16:29:12 dom0 systemd[1]: systemd-modules-load.service: Failed with 
resul 'exit-code'.Dec 22 16:29:16 dom0 systemd-modules-load[540]: Inserted 
module 'uinput'

Dec 22 16:29:16 dom0 systemd[1]: Started Load Kernel Modules.

-- Subject: Unit systemd-modules-load.service has finished start-up

-- Defined-By: systemd

-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel

--

-- Unit systemd-modules-load.service has finished starting up.

--

-- The start-up result is done.

These messages are not so detailed on the causes on which the error ocurred. Is 
there a way to get more info, like turning on a debug mode on boot or something?
Is there a way on qubes to check the signature of uinput module?

> > Dec 15 20:52:37 dom0 xenstored[1267]: Checking store complete.

> > Dec 15 20:52:38 dom0 udisksd[1497]: Acquired the name 
> > org.freedesktop.UDisks2 on the system message bus
> > Dec 15 20:52:38 dom0 udisksd[1497]: Error loading modules: Error opening 
> > directory '/usr/lib64/udisks2/modules': No such file or directory
> 

> Did you install something in dom0? Generally, you should not. Uninstall
> it or reinstall Qubes and the error should go away.

I did not install anything on dom0 ( how do i find what was supposedly 
installed, is there a way? )
This are the logs from installing the latest preview3 of 4.0.2. I installed it 
twice, the logs are the same, do you think reinstalling it will solve?

Thank you for your patience. Sorry for so many questions.
Merry Christmas everyone.

-- 
You received this m

[qubes-users] Re: Has anybody gotten increased scrutiny at an international checkpoint because of having qubes installed?

[244clarendonst]

On Friday, 13 December 2019 19:37:30 UTC, bill...@gmail.com wrote:
>
>
> Yeah, there are ways to fake an OS, but that really wasn't my question.  I 
> was wondering whether or not folk have noticed that having an OS like Qubes 
> would result in greater scrutiny than Windows or MacOS.  I'm not trying to 
> sneak anything across the border; I just don't want to spend an extra two 
> hours at the airport.
>

No, but do think carefully about any suggestions to hide Qubes (in a USB 
stick or on the hard disk). They are likely to work well ALMOST all the 
time, but in the unlikely even that that the covert qubes is spotted, the 
delay could be A LOT longer...



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/078b95a6-f80f-450e-bc77-530fac4d489f%40googlegroups.com.

Re: [qubes-users] Re: How do I attach a hard drive to a VM on boot?

[244clarendonst]

> The only remaining problem here might be that /dev/sda3 doesn't 
> reference the same drive on each dom0 boot process... 
>
> So you'd have to write ... Alternatively  you could  ...
>

Another option is to label the filesystem, say with 

tune2fs -L foo /dev/sda3

Then, instead of the /dev/xxx entry in fstab, use LABEL=foo like this


LABEL=foo   /mnt/tmpauto user,rw 0 0

That way it will find the relevant partition, even if it moves around in 
the partition table on the real disk, or if it appears on a different 
virtual disk.(not yet tested on Qubes, but this is my normal way of making 
fstab entries persist)

You can also do the same using UUIDs, but I prefer to use meaningful 
identifiers. I am old-school in that respect.

R~~

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8767cb3e-335e-4585-8691-bb0795c4a0e0%40googlegroups.com.

Re: [qubes-users] equivalent of grub kernel parameters on qubes?

[244clarendonst]

On Wednesday, 30 October 2019 12:53:47 UTC, unman wrote:
>
> On Mon, Oct 28, 2019 at 09:36:50AM -0700, Guerlan wrote: 
> > ...
> > 
> > 
> I'm starting to think you are ideologically wedded to top-posting. 
> Believe me, once you've tried bottom posting you will never understand 
> why you did this. 
> I guess your mail software outs the cursor at the top of the message 
> when you h=it "Reply". ... 
>


On some packages & web interfaces it is worse than that :(

For example on the gmail app for Android, it hides the quoted text, so it is
far too easy for a newcomer to this forum to not even realise what you meant
when you said "scroll to the bottom of the text."

To be able to bottom post on such platforms, you need to enable the quoted 
text,
typically and confusingly Google calls this "Respond in line". Having done 
that,
the user can then follow your advice to scroll past deleting on the way.

I know this is off topic, but we can help ppl do things the Qubes way if we 
all
try to give them the most detailed advice.

Bottom posting reads better, but so many other forums use top posting, and 
too
many apps nudge this behaviour, so we are likely to have to go on 
explaining this.

R~~

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/01b9c1c4-d5aa-47b1-ac14-266ba72a2647%40googlegroups.com.

[qubes-users] Installation Failure of Sagemath - More space needed on the filesystem

[Ray Joseph]

I am trying to install Sagemath using:

sudo dnf install sagemath

which failed.

 

Template: fedora-30

This vm was started with default private/system storage 7 GB/10 GB.

Initial memory 400 MB

Max memory 4000 MB

VCPUs no.: 2

Mode:  PVH

 

The installation transaction summary reports:

Install 893 packages

Total download size:  1.1 G

Installed size: 4.1 G

I answer yes to install.

 

The system progresses through a portion of the installation and ends with:

Error Summary

Disk Requirements:

  At least 1506GB more space needed for the / filesystem

 

The second to the last report line is the installation of sagetwx which 
needs 1504MB.  Then

the last entry is sagemath which needs 1506MB.

 

The last entry memory requirement matches the error report for 1506MB.  
More may be required.  

 

Qube Manager showed Disk usage for the VM to be zero.  I closed the manager 
and reopened.  It then showed 216.78 MiB.  [Is there a way to make this 
update in realtime?]

 

The system storage is (10 GB) is grayed out.  I don't see how to change it 
but I don't expect that to be a solution.  

I stopped the VM, increased the private storage to 9.2 GB, restarted the 
VM, repeated the installation command, and received a similar error.  

 

Error Summary

Disk Requirements:

  At least 1480GB more space needed for the / filesystem

 

The second to the last report line is the installation of sagetwx which 
needs 1477MB.  Then

the last entry is sagemath which needs 1480MB.

 

The last entry memory requirement matches the error report for 1480MB.  It 
is curious the space requirements were not the same between the two runs, 
the failure occurred at the same point even though the memory was increased 
by about 2 GB.

 

I closed the manager and reopened.  It again showed 216.78 MiB.

  

Can I expect that the installation report on storage sizes is accurate?

 

The system storage is (10 GB) is grayed out.  I don't see how to change it 
but I don't expect that to be a solution.  

 

How might I progress?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/43aca8b5-427c-43a3-b4b0-0a57b4a11381%40googlegroups.com.

[qubes-users] HOWTO: Enable screen poweroff (instead of blanking)

[Claudia]

I just wanted to drop a note here before I forget. Out of the box, Qubes blanks 
the screen after a few minutes, but never powers off the screen, even though 
it's configured to do so in the XFCE Power Manager. I've had this problem on 
several machines, all the way back to R3.2, and I always blamed it on lack of 
hardware support.

Turns out, it's because Qubes comes with Xscreensaver enabled which overrides 
the XFCE Power Manager settings. Xscreensaver is only configured to blank the 
screen; I'm not sure if it even supports powering it off. To return control to 
XFCE, go to Menu > System Tools > Session and Startup > Application Autostart, 
and uncheck "Screensaver". Then you can logout, reboot, or go to Menu > System 
Tools > Screensaver > File > Kill Daemon. You may have to also open Menu > 
System Tools > Power Manager > Display, and switch "Display power management" 
to off and then on again.

Note this will disable the lockscreen. This is not recommended if you use a USB 
keyboard or mouse and a USB Qube, or if someone has physical access to your 
computer while it's on. Otherwise, I recommend enabling screen poweroff in 
order to conserve energy and lengthen the lifespan of your screen's backlight.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bbc604dc7a210432fe6f418a6eaa0834%40disroot.org.

Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

[Claudia]

December 22, 2019 10:33 AM, "Vít Šesták"
 wrote:

> As far as I know/understand:
> 
> * At start, all the PCI devices are assigned to dom0.
> * When a qube with an attached PCI device starts, dom0 assigns the PCI device 
> to the qube, so it is
> no longer attached to dom0. It never gets actually attached to dom0 
> automatically (until reboot).
> If it was, a malicious qube could for example flash a malicious firmware to a 
> USB device and shut
> down in order to connect the malicious device to dom0.
> * In order to have some additional protection, rd.qubes.hide_all_usb hides 
> all USB devices. That
> is, the USB PCI device is attached to dom0, but Linux ignores it, maybe it 
> blacklists related
> kernel modules.
> 
> The behavior you have observed suggests that both detached USB controller and 
> ignored USB
> controller cause an issue. So, maybe the problem is not in the process of 
> detaching a controller
> that is being used, but rather in not having the controller available.
> 
> Intel includes some USB controller in CPU and quick Googling suggests that so 
> does AMD. Maybe there
> is some AMD-specific code in Linux kernel that expects the USB controller to 
> be available for
> whatever weird reason. Yes, it sounds strange, but it is the least 
> implausible explanation I was
> able to find.
> 
> Regards,
> Vít Šesták 'v6ak'

Thanks for the info. Yes, that sounds correct from what I could tell, too. More 
specifically, what rd.qubes.hide_all_usb actually does is looks for USB 
controllers device files in /sys/bus/pci, and then calls their driver/unbind, 
driver/new_slot, and driver/bind functions. So basically, it forces the Linux 
USB driver (xhci_pci, in my case) to detach from the USB controller, and then 
attaches it to Xen's pciback driver so that it can be used by sys-usb later 
(although I don't know if this step is actually necessary, since starting 
sys-usb without hide_all_usb works just fine). I'm assuming this step happens 
before udev trigger, which probes devices including USB devices. Maybe that's 
why the hook assigns pciback instead of just unbinding the USB driver - so udev 
doesn't see that the device has no driver and attempt to bind the USB driver to 
it again. Or maybe the act of binding pciback is what actually places the USB 
controller under IOMMU isolation by Xen (otherwise the USB controller could 
still perform a DMA attack even with no driver bound to it). 

I don't know which step -- unbinding xhci_pci, or binding pciback -- actually 
causes the crash in this case. I can say, however, that one of them does cause 
an immediate crash, before sys-usb ever starts or has a chance to take over the 
USB controllers.

The same hook does the same thing for networking devices as well, so that those 
are never exposed. In my case this doesn't cause a problem because both network 
cards are their own devices on their own busses and have their own IOMMU 
groups, unlike my USB controllers.

Here's the actual code from 
/usr/lib/dracut/modules.d/99qubes-pciback/qubes-pciback.sh

#!/usr/bin/sh

type getarg >/dev/null 2>&1 || . /lib/dracut-lib.sh

# Find all networking devices currenly installed...
HIDE_PCI="`lspci -mm -n | grep '^[^ ]* "02'|awk '{print $1}'`"

# ... and optionally all USB controllers...
if getargbool 0 rd.qubes.hide_all_usb; then
HIDE_PCI="$HIDE_PCI `lspci -mm -n | grep '^[^ ]* "0c03'|awk '{print $1}'`"
fi

HIDE_PCI="$HIDE_PCI `getarg rd.qubes.hide_pci | tr ',' ' '`"

modprobe xen-pciback 2>/dev/null || :

# ... and hide them so that Dom0 doesn't load drivers for them
for dev in $HIDE_PCI; do
BDF=:$dev
if [ -e /sys/bus/pci/devices/$BDF/driver ]; then
echo -n $BDF > /sys/bus/pci/devices/$BDF/driver/unbind
fi
echo -n $BDF > /sys/bus/pci/drivers/pciback/new_slot
echo -n $BDF > /sys/bus/pci/drivers/pciback/bind
done



As for USB controllers being on the CPU, yes that's what I found as well; all 
current CPUs bundle their integrated USB controllers right on the chip. I don't 
think code in the Linux kernel expects the USB controllers to be available. 
Rather I think it has to do with IOMMU grouping, which tends to be structured 
differently for AMD than Intel. I'm going to start a new thread about that here 
soon.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7b07608331097f1747144fff3291f423%40disroot.org.

Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics

[Vít Šesták]

As far as I know/understand:

* At start, all the PCI devices are assigned to dom0.
* When a qube with an attached PCI device starts, dom0 assigns the PCI device 
to the qube, so it is no longer attached to dom0. It never gets actually 
attached to dom0 automatically (until reboot). If it was, a malicious qube 
could for example flash a malicious firmware to a USB device and shut down in 
order to connect the malicious device to dom0.
* In order to have some additional protection, rd.qubes.hide_all_usb hides all 
USB devices. That is, the USB PCI device is attached to dom0, but Linux ignores 
it, maybe it blacklists related kernel modules.

The behavior you have observed suggests that both detached USB controller and 
ignored USB controller cause an issue. So, maybe the problem is not in the 
process of detaching a controller that is being used, but rather in not having 
the controller available.

Intel includes some USB controller in CPU and quick Googling suggests that so 
does AMD. Maybe there is some AMD-specific code in Linux kernel that expects 
the USB controller to be available for whatever weird reason. Yes, it sounds 
strange, but it is the least implausible explanation I was able to find.

Regards,
Vít Šesták 'v6ak'

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/744c4e79-efef-475a-a3dd-41fd3ded10b3%40googlegroups.com.