[qubes-users] Things to do in Qubes before a BIOS update
Hello. I'm attempting to flash a new BIOS (ie. upgrade) and I am greeted by the BIOS with the following message: "Important Notice!!! Please back up your Bitlocker recovery key and suspend Bitlocker encryption in the operating system before updating your BIOS or ME firmware." Is there something that I need to do in Qubes (R4.0) before updating BIOS assuming either of the following: 1. I don't have Anti Evil Maid installed 2. I do have AEM installed. while Secure Boot is Enabled in BIOS and so is TPM (1.3) ? In the case of point 2 the following info exists: "Xen/kernel/BIOS/firmware upgrades == After Xen, kernel, BIOS, or firmware upgrades, you will need to reboot and enter your disk decryption passphrase even though you can't see your secret. Please note that you will see a `Freshness toekn unsealing failed!` error. It (along with your AEM secrets) will be resealed again automatically later in the boot process (see step 4.a). Some additional things that can cause AEM secrets and freshness token to fail to unseal (non-exhaustive list): * changing the LUKS header of the encrypted root partition * modifying the initrd (adding/removing files or just re-generating it) * changing kernel commandline parameters in GRUB" that is from https://github.com/QubesOS/qubes-antievilmaid/blob/af4f6160dfd89d126b923c183b5a9cea18b4b1b9/anti-evil-maid/README#L344-L358 In the case of point 1, what I want to know is whether or not I will still be able to boot my existing Qubes R4.0 installation after the BIOS update and if not how can it be fixed? This is the reason for this post. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e8dcafbf-8820-498b-b5b9-a0664ba083d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: HCL - Thinkpad X1 Carbon 6th gen - Qubes 4.0
Using the instructions in the post you referenced, I was able to apply the kernel patch successfully, and it finally started responding to power button presses from sleep! But it would immediately freeze up on wake at either a black screen or at XScreenSaver password prompt. I had to remove the USB-C Thunderbolt 3 controller from the devices list of the sys-usb vm in order to prevent this freeze, and now it works very well, with the minor annoyance of it taking a few seconds to fully recover and wake the display or respond to input. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4febfd85-afec-49e8-a0cb-2cfb10f0d33d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
Success! By process of elimination, I was able to pinpoint the wakeup issue to sys-usb. With further testing, I found that removing the USB-C Thunderbolt 3 Controller from sys-usb's device list resolved the issue. Will test further to see if fiddling with Thunderbolt BIOS assist mode will help. Might a BIOS update might fix this? (The BIOS is on N23ET40W v1.15 from 2018-04-13). Is there a way to update the BIOS without a Windows 10 utility? Side notes: 1. Despite dmidecode reporting back the proper magic LENOVO and X1 Carbon magic strings, I still need to manually specify acpi_force_s3=5 into my xen.cfg, otherwise the kernel patch does not appear to work. 2. My aside about needing the LiveCD Lenovo trick was irrelevant. I can install from an install disk created with dd, so I don't know what I was doing wrong the first time. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c57c198f-d566-4b77-b1d8-74dbe051d898%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: X1 Carbon again; Qubes DSDT override?
Success! By process of elimination, I was able to pinpoint the wakeup issue to sys-usb. With further testing, I found that removing the USB-C Thunderbolt 3 Controller from sys-usb's device list resolved the issue. Will test further to see if fiddling with Thunderbolt BIOS assist mode will help. Might a BIOS update might fix this? (The BIOS is on N23ET40W v1.15 from 2018-04-13). Is there a way to update the BIOS without a Windows 10 utility? Side notes: 1. Despite dmidecode reporting back the proper magic LENOVO and X1 Carbon magic strings, I still need to manually specify acpi_force_s3=5 into my xen.cfg, otherwise the kernel patch does not appear to work. 2. My aside about needing the LiveCD Lenovo trick was irrelevant. I can install from an install disk created with dd, so I don't know what I was doing wrong the first time. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/30f2ccdf-eb0c-4cef-aa4b-5acb9cc8ae80%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Network not working until several minutes after login
Hi! For the last couple of months, my Qubes 4.0 install has suffered from a weird bug. When I login to Qubes, my network icon shows, that I'm connected to my wifi: No matter what VM i'm using, I cannot connect to anything online. However, if I wait a short while, perhaps 3-4 minutes, I can open any VM and connect to whatever I want. When Qubes is booting, I get a short errormessage, that Qubes is trying to start a nonexisting VM (which I deleted). Then it starts sys-net without problems. I don't know if this might be relevant for the problem? best regards, Andreas -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7310d0f3-9027-421f-8714-92556c4935bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Any way to attach a USB drive to a VM by label?
суббота, 19 мая 2018 г., 16:37:55 UTC+3 пользователь Qubes Guy написал: > On Saturday, May 19, 2018 at 4:23:09 AM UTC-4, David Hobach wrote: > > On 05/19/2018 01:04 AM, Qubes Guy wrote: > > > On Friday, May 18, 2018 at 5:59:09 PM UTC-4, David Hobach wrote: > > >> On 05/18/2018 08:19 PM, Marek Marczykowski-Górecki wrote: > > >>> -BEGIN PGP SIGNED MESSAGE- > > >>> Hash: SHA256 > > >>> > > >>> On Thu, May 17, 2018 at 05:57:09PM -0700, Qubes Guy wrote: > > I've successfully used qvm-block (in Dom0) to attach USB drives to > > different VMs (persistently), but I've noticed that Qubes (or Linux) > > sometimes gives them to different devices over time. In other words, > > on Monday, my BIG_TOSHIBA drive will be on /dev/sda, but it'll be > > assigned to /dev/sdj when I boot up on Wednesday. This is throwing off > > my VeraCrypt / FreeFileSync backup routine. (Another way of saying > > this is if I say "qvm-block attach MyVM sys-usb:sda --persistent" when > > one of the three drives I use for MyVM is currently attached to that, > > this will fail if Qubes moves that drive to a different device-name > > (during boot) that isn't one of the three I previously attached (when > > I go to start up that VM). > > > > I thought about persistently attaching all 10 of my USB drives to the > > VM (some HDs, some flash, one SSD - I never use all of them at once - > > don't ask!) because that would certainly fix this problem, but I get > > the following error when I try to start the VM: "ERROR: Start failed: > > XML error: target 'xvdi' duplicated for disk sources '/dev/sdc' and > > '/dev/sde', see /var/log/libvirt/libxl/libxl-driver.log for details". > > > > Note that I did all the persistent attachment commands while the VM > > was not running. If I detach all those, start the VM, do the > > persistent attachments, shut down the VM and then restart it, I get an > > error along the lines of "qrexec process failed to respond in 60 > > seconds". > > > > So, I guess I'm asking if there's a way to just persistently attach 2 > > or 3 external USB drives and have them consistently available on the > > same device names when I start the VM so VeraCrypt doesn't balk? > > (VeraCrypt ultimately doesn't care what device a drive is attached to > > (it could be sda - sdj on my system) because it shows the attached > > drive as "/media/user/BIG_TOSHIBA, but if a drive isn't where it's > > supposed to be, that'll fail. > > > > In case you're curious, the error messages in > > /var/log/libvirt/libxl/libxl-driver.log are meaningless to me, but if > > you want me to post it, I can. > > > > Any help you guys can give me would be greatly appreciated! Thanks... > > >>> > > >>> It isn't available yet, related issue: > > >>> https://github.com/QubesOS/qubes-issues/issues/3437 > > >> > > >> As a workaround you could mount the device via uuid or file system label > > >> in sys-usb, create a loop device from the container you want to pass to > > >> another VM and use qvm-block on that loop device (for which you can > > >> define the name yourself). > > >> > > >> Of course that's only convenient if you script it... > > > > > > Thanks, but how do you do create a loop device? I'm (mostly) a Linux > > > newbie (and, as of 5 weeks ago, I was a Qubes newbie) - I'm your worst > > > nightmare :) I tried the UUID mount thing described in the article I > > > mentioned above, but it just prevents sys-net from starting, but maybe > > > with this loop thing you mention? Can you give me the actual commands > > > required, or direct me to an article showing this? I'm not even sure what > > > to search for. Thanks much! > > > > Honestly you'll probably be off better by waiting for the feature to be > > implemented then. > > > > Anyway for reference I was talking about something like > > > > in your sys-usb: > > 1. mount -U [uuid] [mount point] > > 2. losetup -f --show [your veracrypt file on the mounted file system] > > > > in dom0: > > 3. qvm-block a [target VM] "sys-usb:[output of 2]" > > 4. Open the veracrypt block device now attached to [target VM]. (luks > > supports that, not sure about veracrypt) > > > > You can script all of that from dom0 using qvm-run. Essentially the idea > > was to attach the Veracrypt file to [target VM] instead of attaching the > > USB device itself. > > > > qvm-block also supported files itself in 3.2 (i.e. 1. & 2. could be done > > with qvm-block), but from my experience that didn't work so well in the > > past. > > In 4.0 it was then removed I think; qvm-block -p [target VM] [some file] > > would have made for some really interesting applications such as the one > > described above without much need for scripting. > > Thank you. You might be right about waiting. I've already wasted too much
[qubes-users] how to connect USB to standalone HVM Kali
how to connect USB to standalone HVM Kali? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/06ed8527-13d0-49c5-a349-41b3106e8f25%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
