[qubes-users] HCL - Dell Latitude E6430
Hi, I was forgetting to send the HCL for my Dell Latitude. I have been using Qubes 3.2 since last March, and everything works great so far. I still need to test the cdrom drive and bluetooth though. Thanks for this splendid OS, Santiago -- 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/20170831050827.eykb5ea3u3uy7mxq%40riseup.net. For more options, visit https://groups.google.com/d/optout. --- layout: 'hcl' type: 'laptop' hvm: 'yes' iommu: 'no' slat: 'yes' tpm: 'unknown' remap: 'no' brand: | Dell Inc. model: | Latitude E6430 bios: | A09 cpu: | Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz cpu-short: | FIXME chipset: | Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) chipset-short: | FIXME gpu: | Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation 82579LM Gigabit Network Connection (rev 04) Intel Corporation Centrino Ultimate-N 6300 (rev 35) memory: | 8063 scsi: | TOSHIBA Q300.Rev: 12.3 DVD+-RW UJ8E2Rev: 1.01 usb: | 3 versions: - works: 'FIXME:yes|no|partial' qubes: | R3.2 xen: | 4.6.6 kernel: | 4.9.35-20 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK ---
[qubes-users] HCL - custom build with GIGABYTE Z270N-WIFI and Core i5-7600k
Hello! I have not done too much testing, but I have found some issues/things of note: Qubes doesn't even boot to the LUKS password screen unless I have VT-d disabled This is resolved by removing "iommu=no-igfx" from "/boot/efi/EFI/qubes/xen.cfg" and re-enabling VT-d qubesd would not start after the initial boot until I updated to "qubes-dom0-current-testing" The video keeps flickering/stuttering occasionally while using Firefox in the personal domain This may occur at other times, but I have not noticed it yet The "current-testing" updates did install an updated kernel but I think I need to manually activate it to see if that resolves this issue Wifi works flawlessly on the 2.4 GHz band I have not tested 5.0 GHz Unrelated to Qubes, the BIOS reports it supports a TPM but there is no header on the motherboard to actually install one. -- 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/15e362d8583.ed83fbbc109675.7793274384461679328%40dansage.co. For more options, visit https://groups.google.com/d/optout. qubes-hcl-gigabyte_technology_co___ltd_-z270n_wifi-20170830-231239.yml Description: Binary data
[qubes-users] Re: strange dual display mouse issue
even the scrollbar on the side doesnt work on the laptop screen. as with the wheel, works fine on the tv -- 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/d0571629-b74c-4634-9714-6115b300e765%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] strange dual display mouse issue
qubes is always "quirky" :) this time, i was having trouble with a monitor that was randomly blanking for 2-3 seconds at a time, so now im using a tv to see if the issue is that monitor. with the second monitor, when using gnome-terminal on a fedora-25 appvm, on the laptop, the mouse scrollwheel doesnt work. when the terminal is dragged up to the tv, the wheel works. on a debian-9 appvm, the wheel works in either terminal. dont remember having this issue with the real monitor. -- 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/8c97b721-9bdd-4378-8f41-ac6edb310486%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: to firejail or not to firejail
On 08/29/2017 03:54 AM, pixel fairy wrote: On Monday, August 28, 2017 at 10:46:22 PM UTC-7, Eric wrote: The question as always is, what are you protecting? If it's your user data, compartmentalize differently. If it's some kind of root privilege escalation, that's a lost cause, as the vm sudo page explains. If it's some kind of malware that could get written with root privileges, well, that gets erased by rebooting the VM, unless it's persistent in your user data, but if it is, it's incredibly unlikely to be runable (at least not without explicit user action). I raise these questions because the answer to many of the "OMGWTFBBQ passwordless sudo" threads that appear every so often, come back down to either "whatever you're proposing wouldn't make a difference read the doc again" and "are you sure you read the doc and understood why the decision was made the way it was?" I believe the direction of the recurring discussion has been following a somewhat different arc. Joanna and Marek have lately been receptive (even supportive) to internal domU security... at least ways to enable it. I think the impetus for the shift boils down to these points: 1. VMs shouldn't passively amass malware, even if its not a threat to Xen isolation; its a nuisance at best that can affect other computers/devices. DispVMs help in prevention, but not for many normal PC usage scenarios. 2. DomU OS's have unobtrusive security features ready for use with little or no burden to us: With 'vmsudo' auth prompts configured, using basic domU security is very easy: Say yes/no to the prompt shown in dom0. This is not about passwords in AppVMs. 3. Such domU defenses, while judged to be inferior in general, do receive patches and could allow Qubes systems to thwart attacks ultimately aimed at the hypervisor. This matters even if Linux, etc. remains "swiss cheese" and saves our bacon in only a small percentage of scenarios. 4. Qubes' read-only templates provide a basis for anti-threat persistence measures like 'Qubes-VM-hardening'[1], but only if domU auth is enabled. 5. Xen security was not quite as good as was hoped. Guest OS's supposedly compete on the basis of security, so its probably best to let them do their job in this regard. Especially if all that requires from us is to not switch off security or a little bit of PAM configuration. this wasnt specifically because of the passwordless sudo. its a general access control and hardening thing. i see firejail as complementary to qubes-os. ssh shouldnt access the x server. firefox shouldnt write outside of its own folder and Downloads. neither should shell out and call sudo. when they do, or try to, id really like to know about it. firejail can log such access, and you can have another process follow that log to alert you. but having firejail do that, and watching that log, are more processes, more attack surface. to add to extremely unlikely, ive only known of one ssh client exploit in the wild, and i think it was over 10 years ago. FWIW, AppArmor does work with Qubes VMs and doesn't revolve around a special launcher. [1] https://github.com/tasket/Qubes-VM-hardening/tree/systemd -- Chris Laprise, tas...@posteo.net https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/378ae919-6e19-16bd-58de-205093399c27%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On 08/30/2017 11:49 AM, wordswithn...@gmail.com wrote: On Tuesday, August 29, 2017 at 7:16:16 PM UTC-4, steve.coleman wrote: If your laptop contains an active TPM and a TCG Opal 2.0 compliant SED (SSD or spinning platter) drive, then you can create a range, install the bootstrap/OS, and then mark that range as read-only. After doing that *nothing* will be able to write to that area without the password unlocking that range first, even Dom0 root user, but then it will also need to be unlocked using that same password at the appropriate moment during any update to the bootstrap/Xen code during appropriate Dom0 updates. This same range can also protect the partition table, MBR, and boot menu, etc. Multiple ranges can be set with different attributes/encryption keys. The tool you would need for doing this is "msed" (name given in my fedora distro) or "sedutil" (from the drive trust alliance) which allows you to talk to the drive via sata (not usb afaik) to encrypt or protect defined ranges that you set up. Just be careful to learn/test on a test system, because if you create an encrypted range everything previously there disappears instantly, including partitions. Its the world fastest way I know to completely wipe a drive, flip one bit in the key, poof. Like magic. You can always reset back to the factory default erasing everything on the drive. Calculate your ranges, partition, setup encryption ranges, and install stuff, then finally mark your /boot range as read-only. Don't encrypt your /boot or you will need to install Pre-Boot-Authentication (PBA) and supply a password at boot time. Sedutil source and docs https://github.com/Drive-Trust-Alliance This is interesting. I suppose this would be a way to secure your system, and then you could add AEM over it? That way you are using the security features of the hardware, but not trusting them. As far as "trusting" the drive, you first need a TPM for this to even work, so not all the apples are in one basket. The key itself is not stored anywhere on the drive, but only a partial entropy seed value which when combined with the users password the drive can then generate the required key on the fly. If used for encrypting your data, all that work is done within the drive hardware thus freeing up your host cpu for other things. If you are the paranoid belt and suspenders kind you can also encrypt your data before it goes to the drive where it gets encrypted yet again automatically. Layers of security are always better. It is possible to have the drive bound and unlocked by a specific TPM/PCR value generated during a trusted boot process. That way not only is your drive not writable by the adversary, but the drive itself must be physically in that specific machine/TPM otherwise it remains as useful to the adversary as a paperweight. In the context of xkcd, even beating you over the head for a password won't help if its not in a correctly booted known state of that specific machine/TPM combination. http://imgs.xkcd.com/comics/security.png For the ultra-ultra-ultra paranoid you can even have a hidden partition table such that it exposes the real drive partitioning only after the drive is unlocked (aka. the 'done bit is set' to expose the shadow MBR). This way you can boot readonly into a stripped down ISO image OS with AEM/trusted boot to check for any extra devices connected, then use the PCR magic hash to finally unlock and expose the real partition table, and then boot again into the actual R/W OS partition. That's the use-case that I'm working on for a pet project of mine. I would think that Whonix devs might like to play with that kind of scenario for providing absolute "plausible deniability" when that subsystem is not in use. When you don't need it, you could not even tell that the partition exists, just unallocated sectors on the drive with (encrypted) garbage bytes in it. Lots of creative things can be done with it, and if you buy a current model SSD it likely comes with Opal 2.0 for free. -- 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/8b31845f-cc21-fd9e-f180-43fc5bdd802c%40jhuapl.edu. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/30/2017 05:46 PM, wordswithn...@gmail.com wrote: >> Plus, you always need to disconnect all untrusted USB devices >> while rebooting Qubes, regardless of whether you have USB qube >> set up or not. >> > > I just want to make sure that this is not always the case - > according to https://www.qubes-os.org/doc/usb/, if you create the > USB VM automatically during install, then Qubes will be set to hide > USB devices from dom0 on boot. > >> (Note: Beginning with R3.2, rd.qubes.hide_all_usb is set >> automatically if you opt to create a USB qube during >> installation. This also occurs automatically if you choose to >> create a USB qube using the qubesctl method, which is the first >> pair of steps in the linked section.) > The USB controllers are hidden only from dom0 (via Xen's PCI device blacklisting). BIOS or GRUB can, however, still process the device descriptors or filesystem headers during early boot stages and get exploited. Cheers, Patrik -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJZpuS2AAoJEFwecd8DH5rllxMP/3wgSi7gD+2kVnbILbYhcrWn uqzLLYc0xie9B6ou7YwE8ZTDobY5VNDD8hfX5H51fDInhYcdmvkBio1Rd9nXePGO 4II9UYZdpQiKMtRSYpZ2tnjhp1ITtA755hSZOknJZ95o/HPsxqIVg3DYQeBT12jd ZGHNTIQX8OGGJ9NgR6D9dOPhTA4zJemiH7vlD+3zHV8AbMHCgbicOaN6ETNQoB2A 482QsQOERtRjM0qtyvTBhH/UGqQzwtbcTy4HV+3MBQZv3m3UgPXMoUpCVPAXRDqY VZvWPAS2nBayxyQ+2GCxFVFfej1YSfPTcUXfrRfxdbgSuAvmPwBPPrVOWRx8Q3QV NBHeucjLKVS2B/U7AU3OFKj+M5nacMGgMNIIWgNIerzXEq3/QO9M2VNSbc2odzHr PBzI2EGVPxR+OZcnN6QbXBAc+isY+02wWCiL1jtcTZ8WiDi6ZdMZpoGB98hCitCU 82s6aTQjcPm0/39+fUjywuPFne5bom4OIXKVz8W7IO1bTwDSPEUsJWnQMxnn5cJW fZXlm+ILyz55O02Ub6Rz08iK6nlBnjndRZ0P5ne/bawviWk7QVdpATjeVrAVzNKU hmmdQsxG58IXz8WxOIz2kbn+AeNYajkqWf8zLdgseJTUCA2K1m+LhLPWUuQO6uRf H9+OeJz6OMu0vDaN7lhh =LakE -END PGP SIGNATURE- -- 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/950fe2ab-7185-dfb3-d0df-173405c3fe53%40gmail.com. For more options, visit https://groups.google.com/d/optout. 0x031F9AE5.asc Description: application/pgp-keys 0x031F9AE5.asc.sig Description: PGP signature
Re: [qubes-users] Re: A worrisome threat? Kinda...
On 08/30/2017 05:53 PM, Dominique St-Pierre Boucher wrote: > On Wednesday, August 30, 2017 at 11:32:05 AM UTC-4, Alex wrote: >> There's no isolation benefit with a software firewall if the >> remote administration packets are received by the local network >> adapter, since the "zombie RAT fungus" (Intel ME) fiddles with PCI >> devices on its own. >> >> -- Alex > > Does AMD or ARM motherboard have similar feature(like Intel ME)? > > Thanks > > Dominique > AMD seems to have something on the lines of IME: https://www.reddit.com/r/security/comments/4ot223/do_amdprocessors_have_something_like_intel/ ARM itself is not a specific architecture nor a contained set of them; for example, a quick google search reveals a thread with your question on the Raspberry Pi forum: https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=151542 tl;dr: there does not seem to be some behind-the-scenes management available for ARM, but this does not stop specific implementations from having some weirdness like the VideoCore GPU in a RPi - in this case the GPU "controls" the CPU (it manages CPU boot and manages all CPU RAM at all times) and is an opaque device. -- Alex -- 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/fbfd180c-5f31-2a23-30ff-ab8d664c6254%40gmx.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: A worrisome threat? Kinda...
On Wednesday, August 30, 2017 at 11:32:05 AM UTC-4, Alex wrote: > On 08/30/2017 05:17 PM, wordswithn...@gmail.com wrote: > >> Please also note that any remote administration command can only > >> be received through networking, so proper firewalling (ipv6 may > >> complicate things - prepare your studies in advance) and monitoring > >> may help great lengths. Also, do avoid using x86-based > >> firewalls/routers... ;) > >> > >> -- Alex > > > > Just to be clear for beginners - this means that if you're running > > Qubes on an x86 processor, you cannot trust Qubes as a firewall to > > prevent IME remote administration. > > > > You would need a separate device to act as a firewall. Most routers > > have recently been shown to be compromised in similar ways. It will > > be difficult, but should be possible, to find a device that is secure > > given current knowledge. > > > > You are right. With "proper firewalling" I was implying separate > physical hardware, and that was the basis for "avoid x86 based firewalls". > > There's no isolation benefit with a software firewall if the remote > administration packets are received by the local network adapter, since > the "zombie RAT fungus" (Intel ME) fiddles with PCI devices on its own. > > -- > Alex Does AMD or ARM motherboard have similar feature(like Intel ME)? Thanks Dominique -- 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/435d58b8-05cc-4113-aa81-4d423a65587e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
On Tuesday, August 29, 2017 at 7:16:16 PM UTC-4, steve.coleman wrote: > If your laptop contains an active TPM and a TCG Opal 2.0 compliant SED > (SSD or spinning platter) drive, then you can create a range, install > the bootstrap/OS, and then mark that range as read-only. > > After doing that *nothing* will be able to write to that area without > the password unlocking that range first, even Dom0 root user, but then > it will also need to be unlocked using that same password at the > appropriate moment during any update to the bootstrap/Xen code during > appropriate Dom0 updates. This same range can also protect the partition > table, MBR, and boot menu, etc. Multiple ranges can be set with > different attributes/encryption keys. > > The tool you would need for doing this is "msed" (name given in my > fedora distro) or "sedutil" (from the drive trust alliance) which allows > you to talk to the drive via sata (not usb afaik) to encrypt or protect > defined ranges that you set up. > > Just be careful to learn/test on a test system, because if you create an > encrypted range everything previously there disappears instantly, > including partitions. Its the world fastest way I know to completely > wipe a drive, flip one bit in the key, poof. Like magic. You can always > reset back to the factory default erasing everything on the drive. > > Calculate your ranges, partition, setup encryption ranges, and install > stuff, then finally mark your /boot range as read-only. Don't encrypt > your /boot or you will need to install Pre-Boot-Authentication (PBA) and > supply a password at boot time. > > Sedutil source and docs > https://github.com/Drive-Trust-Alliance > This is interesting. I suppose this would be a way to secure your system, and then you could add AEM over it? That way you are using the security features of the hardware, but not trusting them. -- 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/8935704e-0147-4df9-8504-b8bd731ad4d7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Options for securing /boot
> Plus, you always need to > disconnect all untrusted USB devices while rebooting Qubes, regardless > of whether you have USB qube set up or not. > I just want to make sure that this is not always the case - according to https://www.qubes-os.org/doc/usb/, if you create the USB VM automatically during install, then Qubes will be set to hide USB devices from dom0 on boot. >(Note: Beginning with R3.2, rd.qubes.hide_all_usb is set automatically if you >opt to create a USB qube during installation. This also occurs automatically >if you choose to create a USB qube using the qubesctl method, which is the >first pair of steps in the linked section.) -- 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/82488fb4-7482-464c-a977-fd4fa06707bf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: A worrisome threat? Kinda...
On 08/30/2017 05:17 PM, wordswithn...@gmail.com wrote: >> Please also note that any remote administration command can only >> be received through networking, so proper firewalling (ipv6 may >> complicate things - prepare your studies in advance) and monitoring >> may help great lengths. Also, do avoid using x86-based >> firewalls/routers... ;) >> >> -- Alex > > Just to be clear for beginners - this means that if you're running > Qubes on an x86 processor, you cannot trust Qubes as a firewall to > prevent IME remote administration. > > You would need a separate device to act as a firewall. Most routers > have recently been shown to be compromised in similar ways. It will > be difficult, but should be possible, to find a device that is secure > given current knowledge. > You are right. With "proper firewalling" I was implying separate physical hardware, and that was the basis for "avoid x86 based firewalls". There's no isolation benefit with a software firewall if the remote administration packets are received by the local network adapter, since the "zombie RAT fungus" (Intel ME) fiddles with PCI devices on its own. -- Alex -- 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/b44e3cd5-cb86-613c-2c4e-2e98c3244339%40gmx.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: A worrisome threat? Kinda...
> Please also note that any remote administration command can only be > received through networking, so proper firewalling (ipv6 may complicate > things - prepare your studies in advance) and monitoring may help great > lengths. Also, do avoid using x86-based firewalls/routers... ;) > > -- > Alex Just to be clear for beginners - this means that if you're running Qubes on an x86 processor, you cannot trust Qubes as a firewall to prevent IME remote administration. You would need a separate device to act as a firewall. Most routers have recently been shown to be compromised in similar ways. It will be difficult, but should be possible, to find a device that is secure given current knowledge. -- 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/6a84b72a-1a68-4dbc-beeb-6bc28c59a85b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes-R4.0-rc1-x86_64 how to Install a Browser
b' Snapshot origin LV vm-fedora25-privat not found Volume group qubes_dom0 .\n how to solve this error? This Information I got when starting the VM Am 2017-08-25 09:38, schrieb QubesOS-ML: Hello after rebooting the Qubes OS Laptop and restarting with qvm-start fedora-25 i got a error b' Snapshot origin LV vm-fedora25-privat not found Volume group qubes_dom0 .\n have a nice day vinc -- 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/0f490d553e542eeb00d69cf6139b503e%40kozo.ch. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Dell OptiPlex 9020
Qubes-HCL-Dell_Inc_-OptiPlex_9020-20170830-110851.cpio.gz Description: GNU Zip compressed data --- layout: 'hcl' type: 'mini tower' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'unknown' remap: 'yes' brand: | Dell Inc. model: | OptiPlex 9020 bios: | A08 cpu: | Intel(R) Core(TM) i5-4590 CPU @ 3.30GHz cpu-short: | FIXME chipset: | Intel Corporation 4th Gen Core Processor DRAM Controller [8086:0c00] (rev 06) chipset-short: | FIXME gpu: | Intel Corporation Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev 06) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Ethernet Connection I217-LM (rev 04) memory: | 16292 scsi: | WDC WD5000AAKX-7 Rev: 1H20 DVD+-RW DH-16AES Rev: 3D11 usb: | 3 versions: - works: yes qubes: | R3.2 xen: | 4.6.6 kernel: | 4.9.35-20 remark: | FIXME credit: | Largentula link: | FIXLINK --- -- 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/1f68cb36a350aa6d0e3446b8ebb2bd25%40turlan.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 3.2 installation on Lenovo Thinkpad P51
Hi there, I'm trying to install Qubes 3.2 on a Lenovo Thinkpad P51, and I know that some have succeeded. But so far my issue is very basic : I can't get the installer to start in GUI mode, as X11 fails starting, falling back to the text installaer mode which is known to be bugged and unusable (it complains about having no disk encryption key provided). I'm about sure that all I need is a boot option to add to the kernel parameters, but googling the group archives didn't help. Any clue ? TIA. Kind regards. -- 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/e2c017e406514fc1af209e76fabf1753%40petaramesh.org. For more options, visit https://groups.google.com/d/optout.
