Hi everyone, Thank you for all your help and discussion. I posted the HCL for the device I'm troubleshooting -- the latest Lenovo Flex 14 with the i5-10210U. You can find it here: https://groups.google.com/forum/#!topic/qubes-users/kamMImlGMNQ
I'm guessing the plan is to set up networking, update the templates and dom0, then troubleshoot the trackpad and external monitor. I plugged in the monitor with HDMI and it didn't show up under System Tools > Display, and my touchpad doesn't show up under System Tools > Mouse and Touchpad. . Here are the outputs of some of the suggested commands in my sys-net terminal. My sys-net is based of Fedora 29. > [user@sys-net ~]$ iwconfig > lo no wireless extensions. > > vif3.0 no wireless extensions. > > [user@sys-net ~]$ ifconfig > lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 > inet 127.0.0.1 netmask 255.0.0.0 > inet6 ::1 prefixlen 128 scopeid 0x10<host> > loop txqueuelen 1000 (Local Loopback) > RX packets 1606 bytes 129550 (126.5 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 1606 bytes 129550 (126.5 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > vif3.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 > inet 10.137.0.5 netmask 255.255.255.255 broadcast 0.0.0.0 > inet6 fe80::fcff:ffff:feff:ffff prefixlen 64 scopeid > 0x20<link> > ether fe:ff:ff:ff:ff:ff txqueuelen 32 (Ethernet) > RX packets 1093 bytes 67624 (66.0 KiB) > RX errors 0 dropped 0 overruns 0 frame 0 > TX packets 170 bytes 15418 (15.0 KiB) > TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 > > [user@sys-net ~]$ iwlist > Usage: iwlist [interface] scanning [essid NNN] [last] > [interface] frequency > [interface] channel > [interface] bitrate > [interface] rate > [interface] encryption > [interface] keys > [interface] power > [interface] txpower > [interface] retry > [interface] ap > [interface] accesspoints > [interface] peers > [interface] event > [interface] auth > [interface] wpakeys > [interface] genie > [interface] modulation > > [user@sys-net ~]$ lsusb -v > > Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd > Couldn't open device, some information will be missing > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 0 > bDeviceSubClass 0 > bDeviceProtocol 0 > bMaxPacketSize0 64 > idVendor 0x0627 Adomax Technology Co., Ltd > idProduct 0x0001 > bcdDevice 0.00 > iManufacturer 1 > iProduct 3 > iSerial 5 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x0022 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 7 > bmAttributes 0xa0 > (Bus Powered) > Remote Wakeup > MaxPower 100mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 3 Human Interface Device > bInterfaceSubClass 0 > bInterfaceProtocol 0 > iInterface 0 > HID Device Descriptor: > bLength 9 > bDescriptorType 33 > bcdHID 0.01 > bCountryCode 0 Not supported > bNumDescriptors 1 > bDescriptorType 34 Report > wDescriptorLength 74 > Report Descriptors: > ** UNAVAILABLE ** > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0008 1x 8 bytes > bInterval 4 > > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub > Couldn't open device, some information will be missing > Device Descriptor: > bLength 18 > bDescriptorType 1 > bcdUSB 2.00 > bDeviceClass 9 Hub > bDeviceSubClass 0 > bDeviceProtocol 0 Full speed (or root) hub > bMaxPacketSize0 64 > idVendor 0x1d6b Linux Foundation > idProduct 0x0002 2.0 root hub > bcdDevice 4.14 > iManufacturer 3 > iProduct 2 > iSerial 1 > bNumConfigurations 1 > Configuration Descriptor: > bLength 9 > bDescriptorType 2 > wTotalLength 0x0019 > bNumInterfaces 1 > bConfigurationValue 1 > iConfiguration 0 > bmAttributes 0xe0 > Self Powered > Remote Wakeup > MaxPower 0mA > Interface Descriptor: > bLength 9 > bDescriptorType 4 > bInterfaceNumber 0 > bAlternateSetting 0 > bNumEndpoints 1 > bInterfaceClass 9 Hub > bInterfaceSubClass 0 > bInterfaceProtocol 0 Full speed (or root) hub > iInterface 0 > Endpoint Descriptor: > bLength 7 > bDescriptorType 5 > bEndpointAddress 0x81 EP 1 IN > bmAttributes 3 > Transfer Type Interrupt > Synch Type None > Usage Type Data > wMaxPacketSize 0x0004 1x 4 bytes > bInterval 12 > > [user@sys-net ~]$ lspci > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev > 02) > 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] > 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton > II] > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev > 01) > 00:03.0 VGA compatible controller: Device 1234:1111 (rev 02) > 00:04.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 > EHCI Controller (rev 10) > 00:06.0 Network controller: Intel Corporation Device 02f0 > > [user@sys-net ~]$ lspci -k > 00:00.0 Host bridge: Intel Corporation 440FX - 82441FX PMC [Natoma] (rev > 02) > Subsystem: Red Hat, Inc. Qemu virtual machine > 00:01.0 ISA bridge: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] > Subsystem: Red Hat, Inc. Qemu virtual machine > 00:01.1 IDE interface: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton > II] > Subsystem: Red Hat, Inc. Qemu virtual machine > Kernel driver in use: ata_piix > Kernel modules: pata_acpi, ata_generic > 00:01.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 03) > Subsystem: Red Hat, Inc. Qemu virtual machine > Kernel modules: i2c_piix4 > 00:02.0 Unassigned class [ff80]: XenSource, Inc. Xen Platform Device (rev > 01) > Subsystem: XenSource, Inc. Xen Platform Device > Kernel driver in use: xen-platform-pci > 00:03.0 VGA compatible controller: Device 1234:1111 (rev 02) > Subsystem: Red Hat, Inc. Device 1100 > Kernel modules: bochs_drm > 00:04.0 USB controller: Intel Corporation 82801DB/DBM (ICH4/ICH4-M) USB2 > EHCI Controller (rev 10) > Subsystem: Red Hat, Inc. QEMU Virtual Machine > Kernel driver in use: ehci-pci > Kernel modules: ehci_pci > 00:06.0 Network controller: Intel Corporation Device 02f0 > Subsystem: Intel Corporation Device 0034 > There's no Kernel driver in use or Kernel modules as we would expect under the output for lspci -k (as seen on the wireless troubleshooting page <https://www.qubes-os.org/doc/wireless-troubleshooting/>). This happens also when I run lspci -k in dom0. Could this be related to the > [FAILED] Failed to start Load Kernel Modules. > that I'm getting on each start-up and shut-down? When I run lspci |grep -i wireless, I don't receive any output. When I run journalctl -k -b |grep -i input in dom0, I see: Lid Switch, Power Button, Power Button, AT Translated Set 2 keyboard, Ideapad extra buttons, PC Speaker, Integrated Camera: Integrated C, and my logitech receiver and mouses, but I don't see anything about my touchpad. Any suggestions on what to do next given these outputs? How can I check whether my firmware is installed correctly in my Fedora 29 template? I went back to the boot menu to look at my usb installer that I used to install 4.0.1 on my Flex. On the boot menu, I see two options for my usb installer. EFI USB Device (my USB) and USB HDD : my USB. When I go to the EFI option, I don't see the boot menu as shown on the installation guide <https://www.qubes-os.org/doc/installation-guide/>, but when go to the HDD option, I do. When enter the HDD option and run the test this media, the test fails, and the installation fails. When I run the EFI option, the installer boots and I can install Qubes. What does test media do and what does it mean when it fails? Could having a failed test media result in some of the problems I'm experiencing with my current installation? I used the Rufus tool on Windows and dd mode to create my installation USB. Should I first install something else (e.g., Fedora) then recreate my installation medium using dd from the command line? I'm pretty sure I properly verified my download of the iso (I'm not sure if it's related): > gpg -v --verify Qubes-R4.0.1-x86_64.iso.asc Qubes-R4.0.1-x86_64.iso > gpg: Signature made 01/05/19 19:05:39 Pacific Standard Time > gpg: using RSA key 5817A43B283DE5A9181A522E1848792F9E2795E9 > gpg: using pgp trust model > gpg: Good signature from "Qubes OS Release 4 Signing Key" [full] > gpg: binary signature, digest algorithm SHA256, key algorithm rsa4096 > Once again, thank you everyone for the questions, discussion, and suggestions. On Thursday, December 5, 2019 at 7:36:28 AM UTC-8, Claudia wrote: > Bernhard: > > > >>> By default network cards are assigned to sys-net and are not visible > >>> in dom0 (as far as I know). Open the Qubes Manager -> sys-net -> VM > >>> settings -> Devices tab, and make sure your network card is assigned > >>> to it. So you need to run lsusb or lspci from within sys-net, not > >>> dom0. You should also run `iw list`, `iwconfig`, and/or `ifconfig` in > >>> sys-net. > >> Let me clarify: PCI network cards are assigned to sys-net and not > >> visible in dom0 by default, regardless of USB Qube. Other PCI devices > >> remain in dom0. > > I can "see" they exist by typing lspci in dom0 (including network cards, > > and the usb controller). My understanding is that while dom0 can see > > them, they cannot see dom0 nor other qubes than the one they are > > attached to (and dom0 will not talk to them unless a game-over event > > occurred). > > Looks like you're right. They still show up in dom0 lspci even when > assigned to a VM. If you use 'lspci -k', you'll see that the kernel > driver in use for assigned devices is Xen 'pciback' instead of the > actual driver. > > I also think you're right that they cannot "see" dom0, in the sense that > they don't have DMA access to any memory owned by dom0 or any other VM. > On machines with working VT-d at least. On machines without VT-d, the VM > could in theory infect the device and gain access to all the machine's > physical memory. But it's still safer to have devices in their own VMs > such as sys-net and sys-usb, even on machines without VT-d. > > The last part, I think you're right, as long as you don't reattach the > device to dom0. When you un-assign a device from a VM it is not > automatically reattached to dom0, as a safety feature. You shouldn't > attach it to any other VMs either, or the device could infect that VM. > You have to reboot, and then un-assign the device without starting the > VM it was assigned to. However it should be safe to re-assign devices > that support the reset command, as long as it is implemented correctly > by the hardware/firmware. I don't know if I would trust it, personally. > > The recent QSB 52 fixed a vulnerability where un-assigned devices could > still carry out DMA attacks even without being reattached to dom0 by the > user. If I understand correctly. > > https://www.qubes-os.org/doc/pci-devices/ > https://www.qubes-os.org/doc/device-handling-security/#pci-security > https://www.qubes-os.org/news/2019/10/31/qsb-052/ > > > > >> You also have the option of combining > >> sys-net and sys-usb into the same Qube so no passthru is necessary. (Or > >> is that mandatory when using USB network cards and a USB Qube?) > > USB is one attack surface, network another. I would suggest to keep them > > apart. In fact, a USB qube does not need any networking at all (not even > > internet access). Imagine its becomes victim of a "bad-usb" then it > > still cannot 'break out' and phone home, for example. Actually my > > Yeah, it's definitely more secure to have them separate. I think the > option is there in case you run into trouble passing a USB network card > from sys-usb to sys-net. Combining them doesn't require any USB > passthru, just PCI passthru of the USB controllers, so it's simpler and > more likely to work. That would be my guess anyway. I don't really know > how USB passthru works. Also useful for machines that don't have much > ram to spare, maybe. > > > sys-usb is halted by default unless I really need it (consequence: if > > you plug any usb device, nothing happens. just nothing.). > > > > Just curious, when you plug in a flash drive while your sys-usb is off, > does the flash drive's LED turn on at all for you? I noticed on one of > my machines, when USB qube is enabled (hide_all_usb), my devices aren't > recognized, and when I plug in a flash drive the LED blinks very briefly > and then turns off. The same flash drive on other OSes, or with USB qube > disabled, the LED normally stays on, and blinks when you access the > drive. (I currently don't have a Qubes machine with a working USB qube I > could try this on.) > > ------------------------------------------------- > This free account was provided by VFEmail.net - report spam to > ab...@vfemail.net <javascript:> > > ONLY AT VFEmail! - Use our Metadata Mitigator to keep your email out of > the NSA's hands! > $24.95 ONETIME Lifetime accounts with Privacy Features! > 15GB disk! No bandwidth quotas! > Commercial and Bulk Mail Options! > -- 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/b0778fac-b757-4046-80aa-01bf8aef65c9%40googlegroups.com.
