Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 20, 2019 6:05 PM, brendan.h...@gmail.com (mailto:brendan.h...@gmail.com) wrote: On Friday, December 20, 2019 at 9:29:55 AM UTC-5, Claudia wrote: December 19, 2019 12:13 AM, "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 ...Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I remove it, it boots fine with the graphical splash and passphrase prompt. Another AMD Ryzen user mentioned having the same problem a while back. Something about AMD's IOMMU grouping of USB controllers, or something. Unfortunately, (my understanding is) that exposes the dom0 to the USB ports. Even if you have a sys-usb, dom0 is still exposed temporarily on boot. Thanks for the tip. I actually thought removing that parameter just simply disabled USB Qube functionality and attached all devices to dom0, but I guess that's only when sys-usb is not running. Once sys-usb is running, it takes over the USB controllers from dom0, I guess. It's just that they're exposed before sys-usb starts, in that case. It would be nice to have working, but I've never had a USB Qube before, even on my old machine, so I haven't lost anything. I don't use a lot of USB devices, and it's not a big part of my threat model. I'll play around with it when I have a chance. -- 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/de0f6b78201db24d5474eeb050e09650%40disroot.org.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
On Friday, December 20, 2019 at 9:29:55 AM UTC-5, Claudia wrote: > > December 19, 2019 12:13 AM, "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 > ...Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I > remove it, it boots fine with the graphical splash and passphrase prompt. > Another AMD Ryzen user mentioned having the same problem a while back. > Something about AMD's IOMMU grouping of USB controllers, or something. > Unfortunately, (my understanding is) that exposes the dom0 to the USB ports. Even if you have a sys-usb, dom0 is still exposed temporarily on boot. B -- 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/6269800c-11c5-4907-a63e-eca2ca5dfbf2%40googlegroups.com.
[qubes-users] Re: VM won't start if Realtek PCI card reader is assigned to it (even if removing conflicting Ethernet controller)
On Wednesday, October 23, 2019 at 2:15:45 AM UTC-4, Davide wrote: > Qubes version > > Qubes-R4.0.1-x86_64 > > > > > > Affected component(s) or functionality > > 02.00.0: Realtek PCI Express Card Reader RTL8411B vs. > > > > 02.00.1: Realtek PCI Express Gigabit Ethernet controller > RTL8111/8168/8411 Having this exact same issue with my new System76 Darter Pro with coreboot. Did you manage to resolve it? -- 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/054afa5e-dae0-431e-8085-dfbb351f3b35%40googlegroups.com.
Re: [qubes-users] Ghost in the machine?
'Chökie Gyaltsen' via qubes-users: > Hello all, > > > I've just installed Qubes latest preview 3. Installed it offline, so all the > logs you will see are from a disconnected system. There are some services > disabled related to security that worry me ( listed below ). Also some > entries that i have some doubts on sys logs ( written below also ). I had a > critical warning just after the install, related to gtk before the login > screen. Attached are all the logs found, complete. If you need some other > info please just let me know. > > output of systemctl -al showing inactive services only ( full list of > services attached ) > > - > UNIT > LOAD ACTIVE SUB > DESCRIPTION > boot.automount >loadedinactive dead boot.automount > The question here is if it is normal that these services are disabled on > first login just after a disconnected install? Yes; most of those only fire once on boot and are no longer needed afterwards. > > > > output of journalctl -ax --merge ( full journalctl output attached ) below > the messages i have some comments on my doubts > - > 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.> > 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. > Dec 15 20:52:31 dom0 kernel: nvme nvme0: missing or invalid SUBNQN field. > Dec 15 20:52:31 dom0 kernel: nvme nvme0: Shutdown timeout set to 8 seconds > Dec 15 20:52:31 dom0 kernel: nvme0n1: p1 p2 > ( after some searching i found that this message is related to the boot disk > Samsung V-NAND SSD 970 PRO NVMe M.2, just installed. The hardware is pretty > new but Samsung has made available the source code for 'magician' ( if i > remember correctly, ( i am still offline ), software under request. The linux > version is old and does not recognize any of the disks present on the > machine. Do you know of any opensource project ongoing to port the tool to > linux? ) No, but I am not aware of any functionality the software provides that can't be accomplished some other way. Not really Qubes related, though. > Dec 15 20:52:34 dom0 kernel: platform regulatory.0: Direct firmware load for > regulatory.db failed with error -2 > ( is it normal this error? ) Yes, Xen/Qubes blocks some direct hardware access. > Dec 15 20:52:35 dom0 systemd[1]: tmp.mount: Directory /tmp to mount over is > not empty, mounting anyway. > ( this always happened in previous installations, strange no? ) Typical on a remount. > Dec 15 20:52:36 dom0 systemd-tmpfiles[1180]: Cannot set file attribute for > '/var/log/journal', value=0x0080, mask=0x0080: Operation not supported > Dec 15 20:52:36 dom0 systemd-tmpfiles[1180]: Cannot set file attribute for > '/var/log/journal/2f474aa11eba4b1394708823e685bcd8', value=0x0080, > mask=0x0080: Operation not supported > ( is this normal? ) My logs show it too. > Dec 15 20:52:36 dom0 xenstored[1267]: TDB: tdb_open_ex: could not open file > /var/lib/xenstored/tdb: No such file or directory > Dec 15 20:52:36 dom0 xenstored[1267]: Checking store ... > ( this message happens at every boot ) Same. > 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. > Dec 15 22:29:02
Re: [qubes-users] How to point(connect) to App VM from external?
Tae Hwan Kim:
> Hi all!
> I am trying to use Qubes OS as a mobile development machine.
>
> My backend server is running in work vm at localhost:4000
> And I am testing my app in real device that is connected using USB cable.
>
> The frontend client should send request to my backend server
> (localhost:4000).
> For testing in real device, localhost address must be changed to real ip
> address(work vm).
> So in my client.js(frontend code),
>
> const HTTP_ENDPOINT = "http://10.137.0.15:4000/api;;
>>
> const httpLink = createHttpLink({ uri: HTTP_ENDPOINT});
>>
> const client = new ApolloClient({ link: httpLink });
>>
> ,
> Unfortunately that address doesn't respond. I tried real ip address which
> is 192.168.1.8, But doesn't work neither.
>
> How can I do this?
>
> Thanks in advance.
>
You'd want to use the 192.168.1.8 address in your client, and port
forward to the VM using
https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world.
--
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots
--
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/6fbffe45-713f-a5fb-4499-64a4d6d36e1e%40danwin1210.me.
Re: [qubes-users] equivalent of grub kernel parameters on qubes?
Guerlan: > Am I doing things rigth now? Pretty much, thank you. It's also considerate to trim parts of the prior thread that are no longer under active discussion, or needed for context. > So, xen.cfg contains things like > > default=4.19.71-1.pvops.qubes.x86_64 > > [4.14.74-1.pvops.qubes.x86_64] > options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx > ucode=scan smt=off > kernel=vmlinuz-4.14.74-1.pvops.qubes.x86_64 > root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-39... > rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 > rhgb quiet plymouth.ignore-serial-consoles > ramdisk=initramfs-4.14.74-1.pvops.qubes.x86_64.img > [4.19.71-1.pvops.qubes.x86_64] > > which seem to be configuratioons to xen. That's correct, but the kernel= line also passes along kernel configuration options. For example, i915.alpha_support=1 is a kernel option, not Xen. Add your custom options at the end of that line. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- 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/62f92b4e-ffbd-d427-3c43-806f2d8dbc81%40danwin1210.me.
Re: [qubes-users] HCL - Dell Inspiron 15 5000 (5575) AMD Ryzen 5 2500U w/ Vega 8 Graphics
December 19, 2019 12:13 AM, "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). Looks like rd.qubes.hide_all_usb is what's causing it to crash. When I remove it, it boots fine with the graphical splash and passphrase prompt. Another AMD Ryzen user mentioned having the same problem a while back. Something about AMD's IOMMU grouping of USB controllers, or something. I'm planning on installing kernel-latest and I'll test it again when I do. -- 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/0b276a64d383722c4057879b527f261c%40disroot.org.
Re: [qubes-users] Dual booting Qubes and Qubes?
December 19, 2019 3:44 PM, "awokd' via qubes-users"
wrote:
> Claudia:
>
>> My original thought was to just give each one its own directory in
>> /boot/efi/EFI/, but the /boot/efi/EFI/qubes/ path seems to be hard coded
>> somewhere, probably either in the grub2-efi package (which installs a
>> precompiled efi binary to that directory) or in a grub2-install hook
>> somewhere. Not sure which of those methods Qubes uses. At least, I
>> couldn't figure out any way to persistently change the name of the EFI
>> directory. Of course you could make your own directories by copying the
>> files. e.g. /boot/efi/EFI/qubes{0,1}/, but when it updates (or you
>> reinstall one of them), they would both try to install to
>> /boot/efi/EFI/qubes/ again. And you'd have to manually change the path
>> each time with efibootmgr.
>
> This is partly what I need to do anyways on an older UEFI system. I
> wrote a script that copies the updated files over to BOOTX64, and run it
> after every update that touches EFI. Shouldn't be too hard to add
> efibootmgr to it, and an edit to the .cfg file pointing at the
> appropriate root=. Ignore the redundant .efi copies at the end; I'm
> still not entirely sure which one my half broken UEFI implementation uses.
>
> rm /boot/efi/EFI/BOOT/init*
> rm /boot/efi/EFI/BOOT/vmlinuz*
> cp /boot/efi/EFI/qubes/init* /boot/efi/EFI/BOOT/
> cp /boot/efi/EFI/qubes/vmlinuz* /boot/efi/EFI/BOOT/
> cp /boot/efi/EFI/qubes/xen.cfg /boot/efi/EFI/BOOT/BOOTX64.cfg
> ls /boot/efi/EFI/qubes/xen-*.efi
> cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/
> cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/EFI/BOOT/
> cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/EFI/BOOT/BOOTX64.efi
>
I see. I'm guessing your firmware only attempts to read from
/boot/efi/EFI/BOOT/BOOTX64.efi, even if the menu entry has a different path? I
think an approach like this could work for managing EFI directories manually.
Automated by a script of course, but still manual in the sense it's not handled
by the OS.
I was really hoping there was a config setting or variable somewhere that could
change the EFI directory, e.g. to /boot/efi/EFI//. On systems that
use grub-install, this is specified by --bootloader-id= argument. So in that
case you may be able replace /usr/bin/grub-install with a wrapper script that
forces your desired --bootloader-id argument. However Fedora doesn't use
grub-install, it uses a package which installs a prebaked grubx64.efi binary
which is installed to the hardcoded path /boot/efi/EFI/fedora. This is in order
to support Secure Boot. I'm assuming Qubes does it the same way. I'm also
assuming that "fedora" gets changed to "qubes" by a patch or a compile-time
variable but is not configurable at runtime. Maybe there's an option in Yum/dnf
similar to apt's redirect option, to configure a file to be installed at a
different path than what it's packaged as. I have no idea.
I did some research, and apparently this is a very common flaw. In fact, Mint
uses the hardcoded directory /boot/efi/EFI/ubuntu/, meaning you can't dual boot
Mint and Ubuntu from the same ESP. But the good news is that you can use more
than one ESP, as long as your firmware supports it (it sounds like most of them
do). So that's also an option. I was originally worried it would cause problems
that they're using the same UUID, but actually they don't. I was confusing the
filesystem UUID, which is unique, with the GPT partition identifier (GUID),
which is a magic value. And I remembered you could also mount them by label
anyway.
https://www.zdnet.com/article/hands-on-linux-uefi-multi-boot-part-three-problem-solving/
So I guess I could use /boot/efi/EFI/qubes/ as a sort of staging area for both
instances of Qubes, and then religiously after every update, run a script to
move the directory to /boot/efi/EFI/qubes{0,1,...}, and then delete the
newly-created efibootmgr entry for \EFI\qubes\grubx64.efi and (if necessary)
re-create the one for \EFI\qubesN\grubx64.efi. Or, perhaps there's some way to
prevent modification of efibootmgr entries so the package install hook (or
whatever) can't mess with it.
I decided I'm going to try the dual-ESP approach first and see if it works. If
not, then I'll try the EFI directory hack.
I formatted my disk like: ESP, /boot, root, ESP, /boot, root, (swap); and
installed Qubes into the first "slot". I still have to install another Qubes
instance into the second "slot" and make sure they both work. I'll follow up
when I do.
--
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/f5c224eda7a05920ab205a2224c58b64%40disroot.org.
