Re: [qubes-users] Has anybody gotten increased scrutiny at an international checkpoint because of having qubes installed?
billol...@gmail.com: > > >> >> Is there actually anyone working on the hidden OS option for the >> linux? Would be very much appreciated. >> >> > > Hah. I actually did something like this by accident the first time I > installed Qubes. I had KDE neon installed, and I couldn't get it to dual > boot correctly. It turned out that the order in which I installed the OSes > made a difference. > > In any case, my laptop has two drives -- a 256G SSD and a 1 TB conventional > hard drive. I got frustrated trying to get it to work, so simply installed > one OS on the SSD and one on the hard drive, each with it's own MBR, UEFI > setup and grub. So, if you turned the machine on, it defaulted to booting > into KDE neon, and booted from the hard drive. If I wanted to boot from > Qubes, I had to frantically hit the escape key and choose to boot from the > MBR on the SSD in the BIOS/startup menu. > > I thought it was kind of cool, but decided I was wasting disk space so > deleted everything when rc2 came out and just use Qubes now -- though I > wish KDE worked better... > > billo > If you're travelling to the US, then there's /some/ good news: https://www.eff.org/deeplinks/2019/11/federal-judge-issues-historic-opinion-digital-privacy-border -- 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/8a8dd6e6-2e95-34d6-5743-e4aaa958d79b%40disroot.org.
Re: [qubes-users] R4.0.1 Initial Setup wizard didn't run
'awokd' via qubes-users: > duc...@disroot.org: >> Hi, >> >> Just installed R4.0.1 onto a friend's PC and the Initial Setup wizard >> didn't run on first boot into the fresh installation, so we have no VMs. >> How do we initiate this manually? > > https://www.mail-archive.com/qubes-users@googlegroups.com/msg28168.html > Crap, sorry, I did do a search but I missed that post. 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/065b7512-47c7-3918-6707-cdb9f6f52d38%40disroot.org. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Copying text to/from Dom0
unman: > On Thu, Sep 26, 2019 at 09:28:00AM +, duc...@disroot.org wrote: >> 799: >>> Hello >>> >>> schrieb am So., 22. Sep. 2019, 13:40: >>> In the official documentation "Copying from (and to) dom0", there is no mention at all of how to copy text via the clipboard from a domain to dom0. What is the method to use? >>> >>> >>> Copying from dom0 to an AppVM is ok, as dom0 has to be trusted. >> >> But how is this done? Like I say, the official documentation references >> a **Qubes Clipboard** widget, but I can't seem to locate it in practice. >> Sorry if I'm overlooking something very simple. >> > > Look in panel - there should be qui-clipboard widget. (icon in KDE is > usual "copy" icon.) > Click and there is option to "Copy dom0 clipboard" > > If you don't see it check that qui-clipboard is running in dom0 > I've just booted Qubes and for the _first time ever_ I have a clipboard icon sitting between the drive widget and the network widget. I know for a fact this wasn't present on any other boot occasion... Spooky isn't the word for it. Murphy's Law: A problem will be reproducible up until the point you attempt to demonstrate it to, or elicit help from, support personnel. But it's there now. Hopefully it'll be there on every subsequent boot. 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/0a4a447f-dbe1-0c4f-b6f2-e03acbbddda3%40disroot.org. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Copying text to/from Dom0
799: > Hello > > schrieb am So., 22. Sep. 2019, 13:40: > >> >> In the official documentation "Copying from (and to) dom0", there is no >> mention at all of how to copy text via the clipboard from a domain to >> dom0. What is the method to use? > > > Copying from dom0 to an AppVM is ok, as dom0 has to be trusted. But how is this done? Like I say, the official documentation references a **Qubes Clipboard** widget, but I can't seem to locate it in practice. Sorry if I'm overlooking something very simple. -- 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/cdc3edcb-a54b-5706-9210-820b6a4fc208%40disroot.org. signature.asc Description: OpenPGP digital signature
[qubes-users] R4.0.1 Initial Setup wizard didn't run
Hi, Just installed R4.0.1 onto a friend's PC and the Initial Setup wizard didn't run on first boot into the fresh installation, so we have no VMs. How do we initiate this manually? 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/e74fe441-72ba-a647-5eff-1476ed7da1c6%40disroot.org. signature.asc Description: OpenPGP digital signature
[qubes-users] Re: Copying text to/from Dom0
Andrew David Wong: > On 9/22/19 6:39 AM, duc...@disroot.org wrote: >> In the official documentation "Copying from (and to) dom0", there >> is no mention at all of how to copy text via the clipboard from a >> domain to dom0. What is the method to use? > > > https://www.qubes-os.org/doc/copy-from-dom0/#copying-to-dom0 > > Hi, That's the document I was referencing, but it doesn't mention using the clipboard, only files. It seemed to me that passing plain text by the clipboard to dom0 was going to be more secure than passing a complete file, so assumed that would be the preferred method. Does such a mechanism not exist then? 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/bb3a1465-397f-f16b-0c3c-c8e1649f7e60%40disroot.org. signature.asc Description: OpenPGP digital signature
[qubes-users] Copying text to/from Dom0
Sorry guys, another couple of questions! I was trying to manually correct the .onion addresses in the dom0 repos at qubes-dom0.repo and qubes-templates.repo. I had the new address in a text file on a flash drive. I think the advice is not to connect flash drives directly to dom0 so I attached it to the Vault domain instead. Then I discovered I didn't know how to copy/paste the text from that domain's clipboard to dom0. In the official documentation "Copying from (and to) dom0", there is no mention at all of how to copy text via the clipboard from a domain to dom0. What is the method to use? Later, when I was trying to copy text from dom0 Console via clipboard to the Vault domain, I read the same article and it says: > 1. Use the **Qubes Clipboard** widget: > - Copy text to the clipboard normally in dom0. > - Click the **Qubes Clipboard** icon in the Notification Area But I can't find a Qubes Clipboard icon in the Notification Area. I'm not even sure where the Notification Area is - is it the Task Bar at the top of the screen? All notifications seem to cascade down the right side of the screen, and there's definitely no icon there. -- 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/63f8d6b1-1e7f-06a6--e5a2d774feb2%40disroot.org. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] System and Template updates over Tor
'awokd' via qubes-users: > duc...@disroot.org: > >> I followed the Onionizing Repos guide, commented out the metalinks and >> uncommented the onion lines. On first test (sudo qubes-dom0-update) I >> got a 404 error: >> >>> HTTP Error 404 - Not Found >> >>> http://yum.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/r4.0/current/dom0/fc25/repodata/repomd.xml >>> "Error: Cannot retrieve repository metadata for (repomd.xml) for >>> repository: qubes-dom0-current" > > I think that's the old onion. If you hadn't ran dom0 updates since > installing, it might not have been corrected. Should now be showing this > one in your qubes-dom0.repo & qubes-templates.repo: > > http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion > Fixed it now. 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/4ce9559e-16d9-a696-d380-c1366212d226%40disroot.org. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] R4.0.1 installer rejects 32GB flash drive as too small at default settings
duc...@disroot.org: > R4.0.1, all checksums verified, GPG sig verified, GPG fingerprint > reasonably well confirmed through online searches. Installing from a > bootable USB flash drive created using /dd/. I couldn't find anything > relating to this issue after searching. > > I've just spent some time confirming this issue before posting. Here's > what I discovered. In a nutshell: R4.0.1 rejects my 32 GB flash drive as > needing 1.55 GiB additional space at default settings and after > reclaiming all available drive space. I double-checked, and all the > system requirements list 32GB (not GiB) as the minimum drive size. > > *All options were left at their defaults unless specified* > > 1) Boot Installer, click Done to confirm default language and location > options and reach the Installation Summary screen. > > 2) Enter the "Installation Destination" screen by following the > on-screen prompts. > > 3) Select the 32GB flash drive and de-select all others. This screen > reports the drive space in Base-2, so 28.9 GiB for the 32GB flash drive. > > 4) Click Done to reach the Installation Options window. It reports: >> Your current Qubes software selection requires 22.91GiB, including > 19.39GiB for software and 3.52 GiB for swap space. > > This looks positive. I have to reclaim disk space on the drive, so > choose to Reclaim Space (or words to that effect). > > 5) On the Reclaim Disk Space screen, it now reports: >> Installation requires a total of 24.23GiB for system data. > > This is weird. Now I need 24.32 GiB instead of 22.91 GiB - an increase > of 1.41 GiB. I still have enough space though, so I re-claim all drive > space with the Delete All button, then click Done. > > 6) This brings me back to the Installation Summary screen, where a > warning banner at the foot of the screen reports: >> Not enough space in file systems for the current software selection. >> An additional 1.55 GiB is needed. > > Right. Okay. Now I'm 1.55 GiB short, so the total install is 30.45 GiB - > an increase of 6.13 GiB from the Reclaim Disk Space Screen, and now I > can't install to the 32GB flash drive. > > Troubleshooting steps: > > I repeated the process over several boots of the installer with no change. > I tried disabling Encryption on the Installation Destination screen, but > the error remains. > I tried using the "I will configure partitioning" option to reach the > Manual Partitioning screen. I used the "click here to create > [partitions] automatically" option, and it successfully creates the > root, swap and EFI partitions with 21.26 GiB, 2.89 GiB and 500 MiB > respectively. On completion, it reports available space as 1.97MiB, so > that looks positive. But when I save the settings and return to the > Installation Summary screen, the same error message appears, and I'm > 1.55 GiB short again. > > Is this PEBKAC or a genuine bug? No feedback available on this issue? Am I the only one encountering it? I was hoping not to have to buy a 64GB flash drive just to work around it, as I have no need for that anything larger than 32GB generally. If I don't hear anything I'll assume it's a bug and file a report. -- 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/08e661b7-534c-0ef7-2f99-7fe506ebdd75%40disroot.org.
Re: [qubes-users] System and Template updates over Tor
duc...@disroot.org: > 'awokd' via qubes-users: >> duc...@disroot.org: >> >>> Based on the settings I chose, should I have expected the >>> qubes-dom0-update commands to leverage a Tor connection? >> >> Yes. >> >>> Does it seem >>> likely that they did in this case? >> >> No; agree it doesn't sound like it. Did you "sudo qubesctl state.sls >> qvm.updates-via-whonix" as part of upgrading the Whonix templates? Seems >> like it should have been unnecessary, though. >> > > The only CLI tool I used was qubes-dom0-update, once for each template. > >>> In future, what steps can I take to >>> verify that performing similar updates will use Tor? >> >> Check Qubes Global Settings to make sure Dom0's UpdateVM is set to >> sys-whonix. Also, double-check /etc/qubes-rpc/policy/qubes.UpdatesProxy >> and make sure the first line says "$type:TemplateVM $default >> allow,target=sys-whonix". > > I'll check this and post back. > You were right, these were incorrectly set. I had to manually change the Dom0 UpdateVM to Sys-Whonix, and uncomment the $type:TemplateVM $default allow,target=sys-whonix line. I'll be performing a fresh install of Qubes R4.0.1 on a friend's device with the same settings, if this happens with hers too I'll report a bug. >> You might want to >> https://www.whonix.org/wiki/Onionizing_Repositories while you are at it. >> > > Thanks. I'll pull all the Whonix docs for reference, seems like a good idea. > I followed the Onionizing Repos guide, commented out the metalinks and uncommented the onion lines. On first test (sudo qubes-dom0-update) I got a 404 error: > HTTP Error 404 - Not Found > http://yum.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/r4.0/current/dom0/fc25/repodata/repomd.xml > "Error: Cannot retrieve repository metadata for (repomd.xml) for repository: > qubes-dom0-current" The following text was in white instead of red, so it's possible the other repos were successfully updated, but I'm not sure. > Qubes OS Repository for Dom0 12 MB/s | 26kB 00:00 That was the end of the text echoed to the Console. Has that particular file been moved and the yum.repos.d/qubes-dom0.repo file not been updated? -- 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/b732a25b-5218-feac-b145-be0f79d43943%40disroot.org.
[qubes-users] ProxyVM 'Radio Button'?
Hi. R4.0.1 The official documentation for creating a VPN AppVM (/docs/vpn) makes mention of a ProxyVM radio button: > 1. Create a new VM, name it, click the _ProxyVM radio button_, and choose a color and template. I understand what a ProxyVM is, but there doesn't seem to be a way of specifying a new VM as one. Is this just some legacy text for an old version of Qubes? Can someone confirm that choosing AppVM from the drop-down menu is the correct thing to do now? Are there any others steps I should take that aren't mentioned in the VPN doc? 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/53f1aaa6-e705-9ea6-501e-9e4042559097%40disroot.org.
Re: [qubes-users] System and Template updates over Tor
'awokd' via qubes-users: > duc...@disroot.org: > >> Based on the settings I chose, should I have expected the >> qubes-dom0-update commands to leverage a Tor connection? > > Yes. > >> Does it seem >> likely that they did in this case? > > No; agree it doesn't sound like it. Did you "sudo qubesctl state.sls > qvm.updates-via-whonix" as part of upgrading the Whonix templates? Seems > like it should have been unnecessary, though. > The only CLI tool I used was qubes-dom0-update, once for each template. >> In future, what steps can I take to >> verify that performing similar updates will use Tor? > > Check Qubes Global Settings to make sure Dom0's UpdateVM is set to > sys-whonix. Also, double-check /etc/qubes-rpc/policy/qubes.UpdatesProxy > and make sure the first line says "$type:TemplateVM $default > allow,target=sys-whonix". I'll check this and post back. > You might want to > https://www.whonix.org/wiki/Onionizing_Repositories while you are at it. > Thanks. I'll pull all the Whonix docs for reference, seems like a good idea. -- 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/b27e251d-b8e8-527a-48f5-fc15623825bd%40disroot.org.
[qubes-users] System and Template updates over Tor
During the first-boot setup of R4.0.1, I chose to "Enable system and template updates over the Tor anonymity network using Whonix". I left all other settings at their defaults. I rebooted, obtained an Internet connection and followed the prompts to Configure Tor, which completed successfully. Afterwards, I followed the advice on the Installation Guide page and upgraded all the Debian and Whonix templateVMs using the supplied commands in a Dom0 console. During the download process, I noticed two things: first, the updates were performed using sys-firewall as a template for an UpdateVM (as described in the documentation); and the download speeds were much quicker than I normally expect from a Tor connection (over 1.5Mbps). This gave me some concern because sys-firewall is the last step before sys-net, and from there to the Internet - where was the Whonix/Tor stage? The download speeds also suggested I wasn't using Tor at all for these updates. Based on the settings I chose, should I have expected the qubes-dom0-update commands to leverage a Tor connection? Does it seem likely that they did in this case? In future, what steps can I take to verify that performing similar updates will use Tor? -- 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/d2e22242-eeaa-7ae5-e756-9d9a332e0bad%40disroot.org.
Re: [qubes-users] R4.0.1 UEFI black screen after boot [SOLVED]
'awokd' via qubes-users: > duc...@disroot.org: >> 'awokd' via qubes-users: > >>> Intel integrated GPU usually works well as is. Are you getting the black >>> screen when you boot the installer, or after it completes and reboots? >>> >> The installer boots just fine, no issues at all. It's only after it >> completes and I try to boot Qubes OS proper that I've just installed >> that I get this problem. >> > OK, you should be pretty close then. If you still have Qubes installed > on your HDD, try this: > > - > https://www.qubes-os.org/doc/uefi-troubleshooting/#accessing-installer-rescue-mode-on-uefi > - it will tell you where it mounted your HDD, think it's /mnt/sysimage > - cd /mnt/sysimage/boot/efi/EFI/qubes > - ls should list xen.cfg, nano it > - do steps 11 & 12 in > https://www.qubes-os.org/doc/uefi-troubleshooting/#cannot-start-installation-installation-completes-successfully-but-then-bios-loops-at-boot-device-selection-hangs-at-four-penguins-after-choosing-test-media-and-install-qubes-os-in-grub-menu > > If that doesn't help, reboot into Rescue mode and nano xen.cfg again. > Remove those mapbs and noexitboot lines, then add efi=attr=uc to the end > of each options line (step 5 for "3.2" in > https://www.qubes-os.org/doc/uefi-troubleshooting/#system-crashrestart-when-booting-installer). > Thanks, applying steps 11 and 12 as suggested was the answer. The hardest part was figuring out how to reach a GRUB menu from UEFI, as it turns out. I might suggest a change to the webpage you linked so that the "Accessing installer Rescue mode on UEFI" section is elevated to an NB: at the top rather than the bottom of the page. -- 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/94ba99e2-f7cb-fb01-7f96-5dd78447386b%40disroot.org.
Re: [qubes-users] R4.0.1 UEFI black screen after boot
Claudia: > 'awokd' via qubes-users: >> duc...@disroot.org: >>> This is an issue that's been reported before, and some solutions appear >>> to be out there, including re-installing with Legacy boot. However, they >>> all seem to involve modifying the installer prior to installation or >>> making changes via a GRUB menu. I'm never presented with a GRUB menu >>> with either (I suspect that's a UEFI issue), so I'm not quite sure how >>> to proceed with troubleshooting. I want to stick with UEFI-only boot as >>> far as possible. >>> >>> The last messages echoed before the black screen are: >>> [VT-D]Passed iommu=no-igfx option. Disabling IGD VT-d engine. Scrubbing Free RAM on 1 nodes using 2 CPUs .done. Initial low memory virq threshold set at 0x4000 pages. Std. Loglevel: All Guest Loglevel: Nothing (Rate-limited: Errors and warnings) Xen is relinquishing VGA console. >>> >>> The screen goes black indefinitely at this point. >>> >>> This is a device with only integrated GPU so I suspected this might be a >>> problem. >>> >>> How should I proceed? >>> >> Intel integrated GPU usually works well as is. Are you getting the black >> screen when you boot the installer, or after it completes and reboots? >> > > For what it's worth, yesterday I updated dom0 on a previously working > Qubes 4.0.1 installation, rebooted, and ran into this exact problem. I > have absolutely no idea if it's related. > > Also, re: grub, from my experience it appears to me that it only uses > grub.efi if you have more than one OS installed, such as R4.0.1 and > R4.1, otherwise xen.efi is used which does not have any boot menu or > command line capabilities. I imagine you could change this from rescue > media using some kind of UEFI boot config utility, or perhaps by running > grub-install? With rescue media, you also can modify boot parameters in > /boot/xen.cfg directly. > > In my case, changing xen.cfg back to 4.14 kernel seems to solve the > issue, but I know I had a 4.19 kernel working on this same machine > before. I haven't tried legacy boot at all. > > Anyway, point is that it may not be strictly due to UEFI, per se. For > me, 4.14 worked fine under UEFI, and then the 4.19 update caused the > same symptoms you're seeing, which is just like any other > update-gone-wrong, UEFI or not. Also, I don't even know if it was the > kernel update that caused it. It could have been caused by a dracut > update, Xen, or anything else, I assume. > > It's on a currently non-production system so I'm probably not going to > troubleshoot it. Most likely I'll wait around for the next kernel update > and see if that fixes it, or wait around for 4.0.2 and reinstall and see > if that fixes it. > > - > This free account was provided by VFEmail.net - report spam to > ab...@vfemail.net > > 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! Think I'll put 4.0.1 out to pasture and wait for 4.0.2 then. Glad to get your 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/764aea2a-a1e1-45ff-8db6-4d39cdc183e5%40disroot.org.
Re: [qubes-users] R4.0.1 UEFI black screen after boot
'awokd' via qubes-users: > duc...@disroot.org: >> This is an issue that's been reported before, and some solutions appear >> to be out there, including re-installing with Legacy boot. However, they >> all seem to involve modifying the installer prior to installation or >> making changes via a GRUB menu. I'm never presented with a GRUB menu >> with either (I suspect that's a UEFI issue), so I'm not quite sure how >> to proceed with troubleshooting. I want to stick with UEFI-only boot as >> far as possible. >> >> The last messages echoed before the black screen are: >> >>> [VT-D]Passed iommu=no-igfx option. Disabling IGD VT-d engine. >>> Scrubbing Free RAM on 1 nodes using 2 CPUs >>> .done. >>> Initial low memory virq threshold set at 0x4000 pages. >>> Std. Loglevel: All >>> Guest Loglevel: Nothing (Rate-limited: Errors and warnings) >>> Xen is relinquishing VGA console. >> >> The screen goes black indefinitely at this point. >> >> This is a device with only integrated GPU so I suspected this might be a >> problem. >> >> How should I proceed? >> > Intel integrated GPU usually works well as is. Are you getting the black > screen when you boot the installer, or after it completes and reboots? > The installer boots just fine, no issues at all. It's only after it completes and I try to boot Qubes OS proper that I've just installed that I get this problem. -- 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/999a21f7-3cbb-1db8-d6fb-65ee50a55ff4%40disroot.org.
[qubes-users] R4.0.1 UEFI black screen after boot
This is an issue that's been reported before, and some solutions appear to be out there, including re-installing with Legacy boot. However, they all seem to involve modifying the installer prior to installation or making changes via a GRUB menu. I'm never presented with a GRUB menu with either (I suspect that's a UEFI issue), so I'm not quite sure how to proceed with troubleshooting. I want to stick with UEFI-only boot as far as possible. The last messages echoed before the black screen are: >[VT-D]Passed iommu=no-igfx option. Disabling IGD VT-d engine. >Scrubbing Free RAM on 1 nodes using 2 CPUs >.done. >Initial low memory virq threshold set at 0x4000 pages. >Std. Loglevel: All >Guest Loglevel: Nothing (Rate-limited: Errors and warnings) >Xen is relinquishing VGA console. The screen goes black indefinitely at this point. This is a device with only integrated GPU so I suspected this might be a problem. How should I proceed? -- 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/531bddd7-ecc8-95ff-9203-bbe8b3923df6%40disroot.org.
[qubes-users] R4.0.1 installer adds extra 10 GiB to Manual Partition schemes
R4.0.1, all checksums verified, GPG sig verified, GPG fingerprint reasonably well confirmed through online searches. Installing from a bootable USB flash drive created using /dd/. I couldn't find anything relating to this issue after searching. This issue is similar to the one I reported earlier but for sanity I've posted it separately. As before, boot Installer to the Installation Summary screen, accepting all default options along the way. Follow on-screen prompt to Installation Destination screen. Then: 1) Select internal 128 GB SATA SSD as sole destination drive. 2) Check "I will configure partitioning", and proceed. 3) On the Manual Partitioning screen, the Available and Total Space both report as 111.79 GiB. 4) Create an EFI partition manually, with a size of 500MiB. Available space now drops to 111.3 GiB, which is correct. 5) Create / (root) partition with a size of 50 GiB. Available space drops to 51.3 GiB, which is not correct - this is a drop of 60 GiB, not 50 GiB. So, where did the extra 10 GiB go? As before, this behavior can be replicated across boots of the Installer. I didn't proceed with the installation so can't advise if this is a cosmetic issue or functional issue. -- 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/0cbc4c83-30be-753e-9c38-e9de9970b266%40disroot.org.
[qubes-users] R4.0.1 installer rejects 32GB flash drive as too small at default settings
R4.0.1, all checksums verified, GPG sig verified, GPG fingerprint reasonably well confirmed through online searches. Installing from a bootable USB flash drive created using /dd/. I couldn't find anything relating to this issue after searching. I've just spent some time confirming this issue before posting. Here's what I discovered. In a nutshell: R4.0.1 rejects my 32 GB flash drive as needing 1.55 GiB additional space at default settings and after reclaiming all available drive space. I double-checked, and all the system requirements list 32GB (not GiB) as the minimum drive size. *All options were left at their defaults unless specified* 1) Boot Installer, click Done to confirm default language and location options and reach the Installation Summary screen. 2) Enter the "Installation Destination" screen by following the on-screen prompts. 3) Select the 32GB flash drive and de-select all others. This screen reports the drive space in Base-2, so 28.9 GiB for the 32GB flash drive. 4) Click Done to reach the Installation Options window. It reports: >Your current Qubes software selection requires 22.91GiB, including 19.39GiB for software and 3.52 GiB for swap space. This looks positive. I have to reclaim disk space on the drive, so choose to Reclaim Space (or words to that effect). 5) On the Reclaim Disk Space screen, it now reports: > Installation requires a total of 24.23GiB for system data. This is weird. Now I need 24.32 GiB instead of 22.91 GiB - an increase of 1.41 GiB. I still have enough space though, so I re-claim all drive space with the Delete All button, then click Done. 6) This brings me back to the Installation Summary screen, where a warning banner at the foot of the screen reports: > Not enough space in file systems for the current software selection. An additional 1.55 GiB is needed. Right. Okay. Now I'm 1.55 GiB short, so the total install is 30.45 GiB - an increase of 6.13 GiB from the Reclaim Disk Space Screen, and now I can't install to the 32GB flash drive. Troubleshooting steps: I repeated the process over several boots of the installer with no change. I tried disabling Encryption on the Installation Destination screen, but the error remains. I tried using the "I will configure partitioning" option to reach the Manual Partitioning screen. I used the "click here to create [partitions] automatically" option, and it successfully creates the root, swap and EFI partitions with 21.26 GiB, 2.89 GiB and 500 MiB respectively. On completion, it reports available space as 1.97MiB, so that looks positive. But when I save the settings and return to the Installation Summary screen, the same error message appears, and I'm 1.55 GiB short again. Is this PEBKAC or a genuine bug? -- 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/f16cacc2-d98a-6f15-918c-a38e539da5ab%40disroot.org.
