[qubes-users] HCL - Dell Latitude E6430

2017-08-30 Thread Santiago R.R.
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

2017-08-30 Thread Daniel Sage
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

2017-08-30 Thread pixel fairy
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

2017-08-30 Thread pixel fairy
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

2017-08-30 Thread Chris Laprise

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

2017-08-30 Thread Steve Coleman

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

2017-08-30 Thread Patrik Hagara
-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...

2017-08-30 Thread Alex
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=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...

2017-08-30 Thread Dominique St-Pierre Boucher
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

2017-08-30 Thread wordswithnemo
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

2017-08-30 Thread wordswithnemo
> 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...

2017-08-30 Thread Alex
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: Qubes-R4.0-rc1-x86_64 how to Install a Browser

2017-08-30 Thread QubesOS-ML
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

2017-08-30 Thread linuxerie


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

2017-08-30 Thread swami

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.