date:20200104

January 5, 2020 3:14 AM, fiftyfourthparal...@gmail.com wrote:

>> However there's probably no way to fully automate it.
> 
> As someone somewhat knowledgeable about tech, but without deep knowledge, 
> this is annoying but
> manageable. Should someone write a "First Boot Checklist" for the wiki, if 
> only to increase the
> accessibility of Qubes?

It would be helpful, sure. I'd also even be interested in outputs like lspci, 
lsusb, dmesg, alsa-info.sh, /proc/cpuinfo, iommu_groups, xl demsg, pm_trace, 
and so on for different machines. But then again, most people are just going to 
test what they actually need and leave it at that. Probably only a small 
minority of Qubes users even submit an HCL report, and even a smaller fraction 
of them troubleshoot issues and update their reports. Fact is, testing and 
troubleshooting can take a lot of time, effort, expertise, and sometimes 
additional hardware. My HCL report for this machine is now almost six months in 
the making, all told.

The HCL doc mentions some of the basics like video, networking, and sleep. Also 
the remarks column of the HCL page is a great place to look for ideas. However, 
I'd say if you can suspend and resume in the middle of a youtube video without 
any noticeable problems, you've already hit all the features for 90% of use 
cases. And keep in mind you can always add to your report later.

-- 
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/607af9d86add9e1eabd0d6cafc91b3a6%40disroot.org.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?

2020-01-04 Thread fiftyfourthparallel


>
> However there's probably no way to fully automate it.


As someone somewhat knowledgeable about tech, but without deep knowledge, 
this is annoying but manageable. Should someone write a "First Boot 
Checklist" for the wiki, if only to increase the accessibility of Qubes?

 

-- 
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/8ecbdf0d-37f9-41e9-910d-c3cac341c060%40googlegroups.com.

[qubes-users] How to Upgrade an Application in VM

2020-01-04 Thread Ray Joseph

Qubes R4.0.2 rc3

I would like to get the latest Sagemath and Jupyter on a VM.  

I am using the Fedora 30 tempateVM which I updated from 29.  I then cloned 
the Fedora 30, and added sagemath with:
dnf install sagemath

Is there a term for this type of installation?

The next version of sagemath is to have full Python 3 capabilities.  

I am concerned on how to install the latest because when I made the initial 
sagemath the newest version was 8.9 but the install was 8.8.  When the next 
version comes out, I would like to assure I get the latest.

How do I get the latest?

What concerns/risks should I consider for this installation?


-- 
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/0492eef6-b623-4735-9e51-58271161683e%40googlegroups.com.

Re: [qubes-users] Re: Qubes 4 boot stuck at: "[ OK ] Reached target Basic System. "

2020-01-04 Thread cyber . citizen

I'm resurrecting this thread to report that I was affected by this problem. 
I hope a solution will be implemented soon because it takes me the better 
part of a day to restore my system, and that's a lot of time to lose to an 
unpredictable glitch.

-- 
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/eec25083-9f92-422a-9f73-780494ae73f6%40googlegroups.com.

[qubes-users] HCL Dell Latitude 7400 (Core i5-8365U Whiskey Lake)

2020-01-04 Thread Daniel Moerner

I recently got a Latitude 7400 from my employer, a perfect replacement
for my 3rd gen X1 Carbon which died four days before the end of 2019.
Looking forward to finally using Qubes with more than 8 GB of RAM.

It works pretty flawlessly with Qubes R4.0.2 after making three
changes: (Still have a lot of fan usage with a pretty loud fan, but
that's Qubes for you.)

1. To boot the installer, you need to remove mapbs=1 and noexitboot=1
(https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-displaying-installer).

2. To get suspend to work, you need to add mem_sleep_default=deep to
the kernel= line in /boot/efi/EFI/qubes/xen.cfg. Otherwise it tries to
use s2idle which does not work with Xen. (cf.
https://groups.google.com/forum/#!topic/qubes-users/w6Jq4j79Eeo)

3. With the 4.19 kernel, it would not complete shutdown without
holding down the power button, and I also didn't get a bootsplash for
the encrypted hard drive. Both of these are fixed with the 5.3.11
kernel in kernel-latest.

Remember that for a machine like this there's some sort of Intel RAID
thing you need to disable in the BIOS for Qubes to find the NVMe disk.

Best,
Daniel

Qubes-HCL-Dell_Inc_-Latitude_7400-20200104-170122.yml
Description: application/yaml

[qubes-users] Re: No Suspend/Resume on Dell Latitude 7400 (i5-8365U) with 4.0.2rc3

2020-01-04 Thread dmoerner

The suspending problem was s2idle. Adding mem_sleep_default=deep to the 
kernel= line of /boot/efi/EFI/qubes/xen.cfg fixes the suspend problem.

Installing kernel-latest (5.3.11-1) fixes the last two problems with 
completing shutdown and with a lack of a bootsplash.

I'll post an HCL in a moment. Everything now works flawlessly.

Daniel

-- 
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/72e1f835-0a5c-42ff-83df-4ae23d884775%40googlegroups.com.

Re: [qubes-users] systemd-modules-load fails, kernel panic

'3vpajfoaga22xc5rf' via qubes-users:

> **BUGS**
> 
> * 1. As I've mentioned earlier, systemd fails to load the kernel modules.
> 
> The full message is:
> [FAILED] Failed to start Load Kernel Modules.
> See 'systemctl status systemd-modules-load.service' for details.

This is cosmetic only. Ignore.

> * 2. During the postinstall (after Qubes' first reboot), Qubes OS crashes
> 4 times, leading to the computer rebooting. It doesn't seem normal.

> I may send this issue to GitHub, if this finally seems to be a Qubes OS
> bug.

A similar issue is already out there on Github related to the kernel
shipped with 4.0.2. Try 4.0.2rc3 instead, or wait a little bit for 4.0.3.

> Nathan (this is a nickname)

awokd (so is this!)

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a0955942-1a18-c356-d0c2-3a87038ace36%40danwin1210.me.

[qubes-users] systemd-modules-load fails, kernel panic

2020-01-04 Thread '3vpajfoaga22xc5rf' via qubes-users

Hey there, Qubes OS community!

It's the story of systemd-modules-load failing to load the kernel modules,
ending in kernel panics at boot.

As I couldn't boot on my last install, I've wiped it with the same
configuration.

Some bugs have been reproduced at installation time, including systemd
failing to load the kernel modules.

**BIOS**

* VT-d is enabled.
* TPM v1.2 was enabled on the first install (v2.0 now)
* memory protection was enabled on the first install (disabled now)
* hyperthreading was enabled on the first install (disabled now)

**BASIC HARDWARE DESCRIPTION**

I run an x260 ThinkPad with an Intel i5-6300U CPU, 8 GB of RAM, and an
SSD.

**CONFIGURATION**

I've partitioned Qubes OS by using the default layout, with FDE.

I've configured Qubes OS to update the system and the VMs through Tor.

**BUGS**

* 1. As I've mentioned earlier, systemd fails to load the kernel modules.

The full message is:
[FAILED] Failed to start Load Kernel Modules.
See 'systemctl status systemd-modules-load.service' for details.

(I haven't used systemd for years, but I haven't found relevant info
with the systemctl output.)

* 2. During the postinstall (after Qubes' first reboot), Qubes OS crashes
4 times, leading to the computer rebooting. It doesn't seem normal.

After 3 reboots, Qubes OS enables me to run the userland I'm using to
send this email. Except the following message:

(I've had the same messages with whonix-ws-15 and fedora-30; there seem
to be the same line numbers on each respective message)

Configuring TemplateVM debian-10 failed:
['qvm-template-postprocess', '--really', '--post-install', 'debian-10',
'/var/lib/qubes/vm-templates/debian-10'] failed:
stdout: ""
stderr: "debian-10: Importing data
Traceback (most recent call last):
File "/usr/bin/qvm-template-postprocess", line 5, in
sys.exit(main())
File "/usr/lib/python3.5/site-packages/qubesadmin/tools/
qvm_template_postprocess.py",
line 310, in main
loop.run_until_complete(post_install(args))
File "/usr/lib64/python3.5/asyncio/base_events.py", line 467, in
run_until_complete
return future.result()
File "/usr/lib64/python3.5/asyncio/futures.py", line 294, in result
raise self._exception
File "/usr/lib64/python3.5/asyncio/tasks.py", line 240, in _step result
= coro.send(None)
File "/usr/lib/python3.5/site-packages/qubesadmin/tools/
qvm_template_postprocess.py", line 235, in post_install
import_root_img(vm, args.dir)
File "/usr/lib/python3.5/site-packages/qubesadmin/tools/
qvm_template_postprocess.py", line 83, in import_root_img
root_size = get_root_img_size(source_dir)
File "/usr/lib/python3.5/site-packages/qubesadmin/tools/
qvm_template_postprocess.py", line 73, in get_root_img_size
raise qubesadmin.exc.QubesException('root.img not found')
qubesadmin.exc.QubesException: root.img not found
"

I suspect this might be a Qubes OS bug, but I'm not sure --
no disrespect to the Qubes OS developers.

I'd like to use Qubes OS nevertheless because thanks to it's UX it
seems safer to use than other security-focused operating systems, in my
big user hands. So many thanks to the Qubes OS developers and
contributors for their patience and for their hard work!

I may send this issue to GitHub, if this finally seems to be a Qubes OS
bug.

Thanks for developing and contributing to Qubes,

Nathan (this is a nickname)

publickey - 3vpajfoaga22xc5rf@protonmail.ch - 0xBA6C2D62.asc
Description: application/pgp-keys

signature.asc
Description: OpenPGP digital signature

Re: [qubes-users] Re: sys-usb issues recognizing devices & maintaining drive connections

scall...@posteo.net:
> 
> 
>  Original Message 
> Subject: Re: [qubes-users] Re: sys-usb issues recognizing devices &
> maintaining drive connections
> Date: 04.01.2020 19:14
> From: scall...@posteo.net
> To: awokd 
> 
> On 04.01.2020 10:51, 'awokd' via qubes-users wrote:

>> Try adding irqpoll to the end of your kernelopts in qvm-prefs sys-usb.
>> Had similar behavior with my Corebooted AMD. Please let me know if it
>> helps you. I think root cause is IRQ setup table issues in Coreboot, but
>> I'm not sure yet how to confirm or fix.
>>
> 
> Unfortunately it doesn't seem to have changed anything. My kernel opts
> are currently set to:
> 
> dom0] qvm-prefs sys-usb
> ...
> kernelopts    -  nopat iommu=soft swiotlb=8192 irqpoll
> ...
> 
> I rebooted sys-usb and am trying to copy a backup to an external USB
> drive and getting the same pauses and low transfer rates (if not worse
> actually).

Thanks for trying. Probably best to remove it then; I could see how it
could make it worse. Once you do, check journalctl -b for sys-usb and
see if there are any complaints when in loads the USB drivers and/or
when they are in use.

-- 
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/86a9c42c-212a-87a0-bf7c-2ab521783cc5%40danwin1210.me.

Re: [qubes-users] "kfd kfd: error getting iommu info. is the iommu enabled?"

Claudia:
> January 4, 2020 9:35 AM, "awokd' via qubes-users" 
>  wrote:

>> The Xen logs look similar to mine. I don't have kfd on my system. 
> 
> From what I saw, I think kfd is an AMD thing. Do you have AMD?

Yes. Pre-Ryzen, but the AMD IOMMU init in Xen logs looks the same.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/1fe5a095-12f9-b394-263c-540432eba4d4%40danwin1210.me.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?

January 4, 2020 5:19 PM, dhorf-hfref.4a288...@hashmail.org wrote:

> On Sat, Jan 04, 2020 at 09:01:35AM -0800, fiftyfourthparal...@gmail.com 
> wrote: 
>> Also, is there a quick diagnostic tool to check if a new installation on a
>> new laptop have all functions working? (like sound, SLAT, TPM, etc.)

qubes-hcl-report checks for the basics, like SLAT, TPM, VT-x, VT-d. Beyond 
that...

I sort of wondered about that too. However there's probably no way to fully 
automate it. E.g., most hardware can't resume itself from suspend, the user has 
to press a key. Same goes for things like external USB device detection, HDMI 
ports, ethernet ports, and so on - you have to physically connect it. And e.g. 
the code wouldn't know if audio is actually coming out of the speakers, even if 
it's writing to the sound card (see below for a real world example). Same goes 
for things like the screen brightness, framebuffer corruption, and so on. So at 
best, a diagnostic tool could only guide the user through the process, which 
would still be helpful but I don't know of any such tool, other than what 
qubes-hcl-report does.

https://www.qubes-os.org/doc/hcl/

> "sound" and "tpm" are simply a question of "is this supported by linux",
> nothing qubes-specific about it.

Well, for the most part, but there are some edge cases. For example in several 
versions of Qubes/Xen my sound card would show up, no errors, but would not 
play any sound other than some slight static. When I booted Qubes without Xen, 
sound worked fine. It turned out it was because the USB controllers are 
IOMMU-grouped with the sound card, so passing one without the other causes 
undefined behavior. I had to disable sys-usb and remove rd.qubes.hide_all_usb. 
Actually I just realized I never followed up on that thread with the actual 
solution.

https://www.mail-archive.com/qubes-users@googlegroups.com/msg31105.html

-- 
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/f83cd216f34f4204d77fcf7856148b4d%40disroot.org.

Re: [qubes-users] Re: sys-usb issues recognizing devices & maintaining drive connections

2020-01-04 Thread scallyob

 Original Message 
Subject: Re: [qubes-users] Re: sys-usb issues recognizing devices & 
maintaining drive connections

Date: 04.01.2020 19:14
From: scall...@posteo.net
To: awokd 

On 04.01.2020 10:51, 'awokd' via qubes-users wrote:

Lorenzo Lamas:

On Friday, January 3, 2020 at 11:02:24 PM UTC+1, scal...@posteo.net 
wrote:

But the other problem I've had with sys-usb is connecting to external
drives. Here are the copy speeds I get on my machine to an external 
usb

device:

Tails OS 33mb/sec
Qubes OS 12mb/sec

This is my hardware: https://www.coreboot.org/Board:asus/kgpe-d16

Try adding irqpoll to the end of your kernelopts in qvm-prefs sys-usb.
Had similar behavior with my Corebooted AMD. Please let me know if it
helps you. I think root cause is IRQ setup table issues in Coreboot, 
but

I'm not sure yet how to confirm or fix.

Unfortunately it doesn't seem to have changed anything. My kernel opts 
are currently set to:

dom0] qvm-prefs sys-usb
...
kernelopts-  nopat iommu=soft swiotlb=8192 irqpoll
...

I rebooted sys-usb and am trying to copy a backup to an external USB 
drive and getting the same pauses and low transfer rates (if not worse 
actually).

253,591,552   0%  249.48kB/s  181:19:51  ^C
rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at 
rsync.c(644) [sender=3.1.3]

[sender] io timeout after 60 seconds -- exiting

Thanks for the suggestion though.

When it is not recognizing devices, the Qubes Devices Widget shows an
additional device: "sys-usb:2-1:1 - 138a_003c_0030009d7e88". It is not
visible when everything works fine. Do you have that as well?

Lorenzo Lamas:

I do not get this 'ghost' device. I either get none or a partial list of 
what should be there.

But that is promising that your USB 3.0 works fine, maybe I should try 
installing an additional USB card. I currently have the onboard usb 
slots on the motherboard and a couple built into my case. They seem to 
behave similarly. Though in the past sometimes switching between them I 
could get things to show up. That was back on Qubes 3.2 though and have 
found rebooting to be the more effective solution when things aren't 
recognized at all.

--
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/a5df2d4744464d972a1c67e90d7da69e%40posteo.net.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?

2020-01-04 Thread fiftyfourthparallel

Many thanks for the lightning-fast reply.

I'm going to use the TPM for Anti Evil Maid. 

On that note, would you happen to know how to downgrade TPM firmware from 
2.0 to 1.2 within Qubes? Will I have to reinstall windows just to do this?

On Sunday, 5 January 2020 01:19:46 UTC+8, dhorf-hfr...@hashmail.org wrote:
>
> On Sat, Jan 04, 2020 at 09:01:35AM -0800, fiftyfour...@gmail.com 
>  wrote: 
> > Quick question: In terms of security, does it matter if I install and 
> use 
> > the latest Linux kernel (5.4) or not? 
>
> quick answer: not different wrt security. 
>
>
> > the potential instability, if there is any? 
>
> quick answer: not different wrt stability. 
>
> see the current 4.0.2 discard drama. 
> even a stable branch kernel can be a lemon. 
> make sure to always keep some back versions installed. 
> so the newest kernel doesnt work in some way? 
> just boot the one from last week, and file an issue report and/or complain 
> on mailinglist and/or irc. 
>
>
> > Also, is there a quick diagnostic tool to check if a new installation on 
> a 
> > new laptop have all functions working? (like sound, SLAT, TPM, etc.) 
>
> quick answer: just boot the installer. 
> if it doesnt like your hardware, it will tell you. 
> that covers at least slat(+iommu). 
>
> "sound" and "tpm" are simply a question of "is this supported by linux", 
> nothing qubes-specific about it. 
>
> tpm has the additional problem of ... 
> aeh, what do you want to use a tpm for anyways? 
> unless you have an actual usecase in mind, just ignore the tpm entirely. 
>
>
>

-- 
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/26e1dbff-e153-467b-9bdf-802b3ddcae8c%40googlegroups.com.

Re: [qubes-users] Does the latest Linux kernel improve security for qubes?

On Sat, Jan 04, 2020 at 09:01:35AM -0800, fiftyfourthparal...@gmail.com wrote:
> Quick question: In terms of security, does it matter if I install and use 
> the latest Linux kernel (5.4) or not? 

quick answer: not different wrt security.

> the potential instability, if there is any?

quick answer: not different wrt stability.

see the current 4.0.2 discard drama.
even a stable branch kernel can be a lemon. 
make sure to always keep some back versions installed.
so the newest kernel doesnt work in some way? 
just boot the one from last week, and file an issue report and/or complain
on mailinglist and/or irc.

> Also, is there a quick diagnostic tool to check if a new installation on a 
> new laptop have all functions working? (like sound, SLAT, TPM, etc.)

quick answer: just boot the installer.
if it doesnt like your hardware, it will tell you.
that covers at least slat(+iommu).

"sound" and "tpm" are simply a question of "is this supported by linux", 
nothing qubes-specific about it.

tpm has the additional problem of ... 
aeh, what do you want to use a tpm for anyways? 
unless you have an actual usecase in mind, just ignore the tpm entirely.

-- 
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/20200104171940.GE8973%40priv-mua.

[qubes-users] Does the latest Linux kernel improve security for qubes?

2020-01-04 Thread fiftyfourthparallel

Happy new decade!*

Quick question: In terms of security, does it matter if I install and use 
the latest Linux kernel (5.4) or not? If security is increased, is it worth 
the potential instability, if there is any?

Also, is there a quick diagnostic tool to check if a new installation on a 
new laptop have all functions working? (like sound, SLAT, TPM, etc.)

**Please don't get pedantic on me*

-- 
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/49254b0f-5bb7-42ac-b918-471d0d2bd141%40googlegroups.com.

Re: [qubes-users] Problem during installation of Qubes 4.0.2

January 4, 2020 12:28 PM, "Fabian"  wrote:

> Hello,
> 
> I recently bought new hardware and tried to install Qubes on it, sadly 
> without any success at all.
> 
> I tried it with UEFI only and with CSM (Compatibility Support Module) only, 
> but neither had worked.
> 
> The media I used is the recent Qubes 4.0.2 ISO, I had the same issues 2 weeks 
> ago with the Qubes
> 4.0.2 RC3 image.
> 
> I copied it to the USB Stick with Rufus (In both MBR/CSM Mode and GPT/UEFI 
> Mode) as well as just
> copying it over to the USB drive and then extract it.
> 
> First of all, the Hardware:
> 
> CPU: AMD Ryzen 9 3950X
> 
> GPU: AMD Radeon RX 5700XT
> 
> Mainboard: ASUS TUF Gaming X570-Plus WiFi
> 
> I made the mainboard decision because of the price and the good VRMs on the 
> board - most other
> "cheap" x570 mainboards are having big problems with VRM temperatures.
> 
> Other parts shouldn't play a significant role here, because I didn't come far 
> enough.
> 
> UEFI Problem:
> When I boot the USB Stick in UEFI Mode, the screen simply stays blank after a 
> couple lines of
> output appeared on the screen.
> I then tried what's written on the "UEFI Troubleshooting" site:
> https://www.qubes-os.org/doc/uefi-troubleshooting
> The output which appears then is visible in the attachment "UEFI.jpg". I also 
> saved the logfile,
> the last lines are the following:
> 
>> [ 9.681987] localhost kernel: usb 3-3.3: New USB device strings: Mfr=1, 
>> Product=2, SerialNumber=0
>> [ 9.682372] localhost kernel: usb 3-3.3: Product: USB2.0 Hub
>> [ 9.682754] localhost kernel: usb 3-3.3: Manufacturer: VIA Labs, Inc.
>> [ 9.724854] localhost kernel: hub 3-3.3:1.0: USB hub found
>> [ 9.725585] localhost kernel: hub 3-3.3:1.0: 4 ports detected
>> [ 9.792658] localhost kernel: usb 3-6: new full-speed USB device number 6 
>> using xhci_hcd
>> [ 9.933606] localhost kernel: usb 3-6: config 1 has an invalid interface 
>> number: 2 but max is 1
>> [ 9.933988] localhost kernel: usb 3-6: config 1 has no interface number 1
>> [ 9.945601] localhost kernel: usb 3-6: New USB device found, idVendor=0b05, 
>> idProduct=18f3,
>> bcdDevice= 1.00
>> [ 9.945983] localhost kernel: usb 3-6: New USB device strings: Mfr=1, 
>> Product=2, SerialNumber=3
>> [ 9.946358] localhost kernel: usb 3-6: Product: AURA LED Controller
>> [ 9.946732] localhost kernel: usb 3-6: Manufacturer: AsusTek Computer Inc.
>> [ 9.947100] localhost kernel: usb 3-6: SerialNumber: 9876543210
>> [ 9.965764] localhost kernel: hid-generic 0003:0B05:18F3.0006: 
>> hiddev97,hidraw5: USB HID v1.11
>> Device [AsusTek Computer Inc. AURA LED Controller] on 
>> usb-:07:00.3-6/input2
>> [ 134.331670] localhost dracut-initqueue[703]: Warning: dracut-initqueue 
>> timeout - starting timeout
>> scripts
>> [ 134.861553] localhost dracut-initqueue[703]: Warning: dracut-initqueue 
>> timeout - starting timeout
>> scripts
>> [ 135.382539] localhost dracut-initqueue[703]: Warning: dracut-initqueue 
>> timeout - starting timeout
>> scripts
> 
> I saved the full Logfile of course, but I prefer to not poste it completely 
> public on this list. So
> if any developer wants it for further inspection, please just let me know, I 
> mail it to you then.
> This all happened before I was able to see the menu (Test this media and 
> Boot, Boot,
> Troubleshooting).
> 
> Then I tried the CSM option in the BIOS. I was at least able to pick an 
> option in the boot menu
> (Test this media and Boot, Boot, Troubleshooting), which then quickly ended 
> in the screenshot
> "CSM.jpg" in normal boot and also in basic graphics mode form Troubleshooting.
> The attachments "CSM_anaconda.log" and "CSM_X.log" are from the installation 
> in CSM Mode.
> 
> Any ideas what the problem could be, and/or how to fix it?
> The hardware is pretty new (GPU released in August 2019, CPU in December 
> 2019, most mainboards with
> X570 Chipset in July 2019. So I suspect it's a driver issue.
> Also a hint from me: I tried to install Debian and Fedora as well, neither 
> has worked. Seems like
> only Windows runs on it for now.
> I somehow expected that already, but maybe my logs help to identify the 
> problem so this hardware
> gets usable sooner for others as well.

Hmm, if you couldn't get the latest Fedora or Debian to run on it, there's 
probably not much hope for Qubes any time soon. But here are some ideas anyway. 

Especially on newer hardware, UEFI mode is strongly recommended if you can get 
it to work, although there's no guarantee. If you want to try the UEFI route: 
Try setting rd.debug in the kernel command line, and note the last few lines. 
This should show you the exact shell command that is timing out. See also: 
https://fedoraproject.org/wiki/How_to_debug_Dracut_problems#Summary_of_dracut_kernel_command_line_options

Otherwise... Try the "nomodeset" kernel parameter which can often fix X 
problems. It's worked for me many times. If it works, after installing and 
updating you can work on getting the graphics driver working

Re: [qubes-users] What happened to "paranoid mode"?

2020-01-04 Thread Chris Laprise


On 1/4/20 6:35 AM, Anil Eklavya wrote:

I wasn’t aware of these options. Thanks for pointing out. I will certainly try 
them out.



I've also been working on an incremental backup tool that is more 
efficient than borg, as it doesn't have to scan the entire volume before 
backing it up.


https://github.com/tasket/sparsebak

It uses LVM metadata to instantly find where volumes have changed and 
processes only those chunks. This is similar to the way Apple's Time 
Machine used update information from its 'sparsebundle' volumes (giving 
Time Machine a major speed boost).


Coding progress had slowed over the last few months, but I'm spending 
more time on it again and hope to have a beta release this month.


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3ee47649-351f-e13b-3d9b-7c4c18f83aa8%40posteo.net.

Re: [qubes-users] Re: Recommended laptop?

On Sat, Jan 04, 2020 at 05:48:29AM -0800, gorked wrote:

> Privacy Beast.   I suspect that I might brick a Lenovo X230 trying to put 
> Core Boot on it.  I know the guys at a local computer shop are capable, but 

the main "trick" here is to have a solid unbricking strategy.
if you have an external flasher, or a device with a clever 
vendor firmware, the worst that will happen is you get to
curse and waste an hour of your time.
i wouldnt even recommend applying me_cleaner without _some_
strategy for recovering from a bad flash.

> My questions being, seems like there is some kind of thing about needing a 
> computer build before 2012 to work properly.   Is this true?

not sure what that means.
actualy, for chromebooks i would recommend "as new as possible". 
all chromebooks with enough oomph ship with coreboot.
any documentation referencing Lewis tooling is outdated.
if you just want to liberate a chromebook without doing own
work on the firmware, MrChromebox tooling is the current way to go.

> Anyone work with a specific Chrome Book?   One can have its RAM increase to 
> say 16 GB, and so on?   

i use qubes on two higher end chromebook models.
Acer CB713 (more pixels, smaller storage) and CB714 (fewer pixels, more
storage).
both have 16GB ram.
both are on the high end of the chromebook price range. 
both can be maddening with their (lack of) internal storage performance.

all modern chromebooks with usbc also support external debug+flash
through a suzyqable. 
very convenient if you want to explore custom firmware mods. 

-- 
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/20200104141332.GD8973%40priv-mua.

[qubes-users] Re: Recommended laptop?

2020-01-04 Thread gorked

I was also interested in a higher security laptop. I feel the guys who
create the Insurgo Privacy Beast are doing a lot more than just flashing
the BIOS. I am on Social Security, so I can not afford their Insurgo
Privacy Beast. I suspect that I might brick a Lenovo X230 trying to put
Core Boot on it. I know the guys at a local computer shop are capable, but
they are not free, and I would have to take the risk of it going bad.

The Librem laptops are not quite in my price range, and I notice the posts
by the developer of Qubes who is somewhat not happy with some of the
direction of Librem development. I am guessing the individual could tweak
up some of the security issues on the Librem. And a Librem is better than
not doing anything, but still prohibitively expensive for me at this time.

I guess I am getting off the point. I was looking at Chrome Books to run
Qubes, and notice,
https://github.com/bibanon/Coreboot-ThinkPads/wiki/Chromebook-Coreboot-Installation

My questions being, seems like there is some kind of thing about needing a
computer build before 2012 to work properly. Is this true?

Anyone work with a specific Chrome Book? One can have its RAM increase to
say 16 GB, and so on?

For now, I have to work with what I have. I have a mid 2009 Mac Book Pro,
and will put another spinning drive in it. Install OS X, the dual book to
some version of Linux. (I guess everyone here knows that is what Apple
calls "Boot Camp") Yes, I did put an SSD in it and try to just install
Linux. Something about it does not seem to shut down properly, and then I
can not get it to boot at all. No doubt not a problem to Linux groupies
here. I feel a dual boot with Boot Camp would resolve that issue. I
guess that is training wheels. That may seem overly detailed, but my last
question is: I know nearly any version of Linux should work in the Apple,
and I may try several, just for fun. I had hoped for a solid Linux stub to
run a virtual machine on top of. But which version of Linux should give me
Security? I had thought of CentOS or its Oracle twin. Parrot OS looks
interesting. None of those are just basic stubs. Thanks for reading
this. and for replying.

Re: [qubes-users] "kfd kfd: error getting iommu info. is the iommu enabled?"

January 4, 2020 9:35 AM, "awokd' via qubes-users" 
 wrote:

> Claudia:
> 
>> I'm getting this message in my logs, about an IOMMU error, on both 4.0.2 and 
>> the F31-based 4.1
>> build. I'm as certain as I can be that the IOMMU is enabled in BIOS. I'm 
>> having issues with
>> passthru and I'm wondering if this might be the cause.
>> 
>> https://bugzilla.redhat.com/show_bug.cgi?id=1404139
>> This thread says it's not a bug, it's just because the system doesn't 
>> support IOMMUv2 and amdkfd
>> (whatever that is) requires IOMMUv2 (whatever that is) for HSA (whatever 
>> that is). I don't really
>> know what any of that means.
>> 
>> Or does it just mean that my GPU is not protected by the IOMMU (same as 
>> iommu=no-igfx on Intel) and
>> I don't have to worry about it?
> 
> I saw in a different thread you made progress, so this is probably
> outdated. However, I think your conclusions are correct. If your IOMMU
> was not working correctly, you would have problems starting HVMs period.
> 

I made progress on a couple of things, but not USB Qube. I was just wondering 
if might have something to do with USB controller passthru. However it may be 
that USB Qube is simply not supported on this system due to IOMMU grouping. 
Other passthru HVMs such as sys-net work fine, though, so I guess that means 
the IOMMU is working despite the error.


> The Xen logs look similar to mine. I don't have kfd on my system. 

>From what I saw, I think kfd is an AMD thing. Do you have AMD?

-- 
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/2d227faa21653704c60f57d5032e684a%40disroot.org.

Re: [qubes-users] What happened to "paranoid mode"?

On Sat, Jan 04, 2020 at 05:05:01PM +0530, Anil Eklavya wrote:

(please dont TOFU)

> I wasn’t aware of these options. Thanks for pointing out. I will
> certainly try them out.

this is all "some assembly required" stuff, but i will try to describe
a working borg setup with some variations and try to explain some of
the thinking behind it.

there are some example scripts here:
https://github.com/xaki23/rzqubes/tree/master/borg

most of these are not commented, userfriendly or have proper 
separation of "code" and "config", but otoh we are talking
about something you set up just once for each system.

the complex parts there are bsnap.sh (which is the hourly
cronjob that does the actual borg-snapping) and bsync.sh 
(which is optionally called at the end of bsnap and does
 the syncing of backup to external target(s), if desired).
the *wraps are just thin wrappers as crude ways to use 
remote-capable tooling (here: borg and rsync) over qubes-rpc.

bsnap.sh has a bit of config at the beginning (lines 3-5), 
storing a password like that is certainly not ideal, but otoh 
doesnt matter (to me) since the script is inside dom0 which 
already has access to all my data and if it is compromised 
its pretty much gameover anyways.

lines 7-13 are leftover from qubes3 days (or for people using
qubes pools of type "file" with q4).

lines 15+16 are a sample of how to use the remote-wrapped variant.
basicly that means your dom0 still does all the reading, chunking,
encryption, but the actual storage backend process is running
on a remote host (or in a qubes appvm). this can be very useful
if you are backing up a stationary desktop to a bulk storage
host on the same lan. 

lines 20-30 are three "backup groups". private volumes at rest,
unsynchronized private volumes of running vms, and dom0 as "files".
the FLP/FLS parts (lines 20+24) select which VMs are backed up
in that way, you can play around with the ls+grep on the commandline
until it matches whatever you want to back up. the examples there
are of the "everything, except what the grep throws away".

lines 21+25+29 delete old backup snapshots that are outside the
specified keep-range. 30/30/30/30 is _a_ _lot_ ...

lines 34-43 are the call to sync out the backup to external
storage, with crude locking. the locking (even when less crude)
is mainly a policy question. if you dont use locking for the sync,
and your sync takes longer than your backup frequency, you might
end up with the sync always just doing half a sync, never completing.
that can be very bad.
otoh, if you do locking, and the (locked) sync stalls out and you
dont have stale-lock detection or a timed hard limit, that stalled
sync job will block all newer sync attempts forever.
thats also very bad.

the called-under-lock bsync.sh tries to level the field (lines 4-8)
by killing/removing anything that might be leftover from older
syncs, creates a lvm snapshot of the local lvm backup volume,
attaches it to a sync-vm and runs a target-specific script inside
that vm.
this is just as setup-specific as it is modular.
doesnt matter to the backup at all whether the sync is done
over webdav, nfs, cifs or rsync-over-ssh. 

the modularity isnt limited to the "sync" phase either.
want to make it respect the per-vm include_in_backup pref?
just add a filter stage based on qvm-ls/qvm-prefs early in bsnap.
want a more paranoid handling of the borg-pw?
use a detached borg repo header, with a different PW in dom0
than in your secret-stash masterkey backup repo, and no repo
header whatsoever in the remote bulk copy.

when restoring localy i tend to use "borg list" to see what snaps
are avail, then "borg list ::snap-12345" to see whats inside,
then "borg extract --sparse ::snap-12345 dev/whatevs". 
these steps are done in dom0 when restoring from a local repo, 
or in the sync-vm if restoring from remote repo.
the restored file is copied to the right blockdevice in dom0 by
"dd if=restored/blah of=/dev/mapper/something conv=sparse".
if the vm/volume used as a restore target isnt fresh/clean/unused, 
make really, really sure to blkdiscard the target volume first.
(filesystems can get really upset if blocks they expect to be zeroed
 are not) 

there is a lot of flexibility and options in all this.
a lot of the options depends on your personal threat model and prefs. 
this also means it is not suitable for users who dont know how
to delete a file without a mouse.
but those will need help with setting up qubes anyways.

feedback, questions, suggestions? 
go ahead, either here, or on #qubes on freenode, or pullreqs ... 

-- 
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/20200104132051.GC8973%40priv-mua.

Re: [qubes-users] Qubes OS 4.0.2 has been released!

2020-01-04 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2020-01-03 7:43 AM, haaber wrote:
> On 1/3/20 3:21 AM, Andrew David Wong wrote:
>> Dear Qubes Community,
>>
>> We're pleased to announce the release of Qubes 4.0.2! This is the second
>> stable point release of Qubes 4.0. It includes many updates over the
>> initial 4.0 release, in particular:
>>
>> - - All 4.0 dom0 updates to date
>> - - Fedora 30 TemplateVM
>> - - Debian 10 TemplateVM
>> - - Whonix 15 Gateway and Workstation TemplateVMs
>> - - Linux kernel 4.19 by default
>>
>> Qubes 4.0.2 is available on the Downloads page:
>> ...
> 
> Dear Andrew (and other users), thanks and a happy new year! I observe
> since one week, that my usual update command
> 
> sudo qubes-dom0-update --enablerepo=qubes*testing
> 
> shows "no new updates available", despite this announcement and a
> previous QSB announcement by Marek. Is this normal? Should I worry?
> Thank you, Bernhard
> 

In a dom0 terminal, the command "sudo dnf history" will show you the
package transaction history of your dom0 updates. The most recent one
I have is from early-mid December.

Each one has an ID number, which you can use to get more info. For
example, if the ID number at the top of your list is 42, try "sudo dnf
history info 42". Now you can see which packages were installed,
updated, uninstalled, etc.

My aforementioned most recent entry from early-mid December involved
upgrading Xen packages to 4.8.5-14 for QSB #055. [1]

However, you're probably thinking of the more recent QSB #056, which
was published on December 25. [2] As stated in that QSB, the packages
are only for TemplateVMs and StandaloneVMs. ("The packages for domUs
are to be installed in TemplateVMs and StandaloneVMs via the Qube
Manager or via their respective package managers...").

In short, I'm not aware of any dom0 updates in the past couple of weeks.


[1] https://www.qubes-os.org/news/2019/12/11/qsb-055/
[2] https://www.qubes-os.org/news/2019/12/25/qsb-056/

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl4QjaYACgkQ203TvDlQ
MDBnvQ//UXVLinBbo+3owqg5J2isg1DQDyaC6WShnShh3TCfoa7YrDeHj13Fp21k
zPz2TZGUWmOkvYBrLOW6b3xam4GLPO1HZWs6Ss8IQDUI0LdaEvmJmJRmJ8PBSc8H
9aQqkDco02Lm+X0FLOd+gAxoQ43TGruYgMkkUE7MQJzwcgyweqMZmyUZOihsUR9L
BNTCJVQhCaO2++u83kVfgUKrbTYDOzQn8zEq1dUBDXu9JoasFbUdCLe8B38pghvE
bQ5J7Q2lsNF6O1rjtvRGkGoOsXkRFvVHqLjCRWb7kTiSyMKygTfh8BUHgNIQte7B
iZH93Goaj8FrB2TDeChK3A90+cy2nDCqcxmpz9ZhNcUn5a+rQI/BoiBytCu+2au7
rUcpSpzX/GQWiBWVf5kXO+gLkXaal1p4vQgKb/1jmzmdXslmG/yGgPiz4o1s9g+d
V9qbYi9YBiC+6k+DZRBkr21neFlgq6H5cNln+yaXosm1+nmsLocz+Fu3z3v3Xq1e
XN0KooFcRFn3P1adxDQHIJzFBjVYP2PATiPVtGcV9frceTFLQdJfCkAEyyh/9cEa
BVAH5IYOdA6bBUbTnz2ry+ylMcCfyBYGnP4IfJPz+t+E4WfoU9V6tO9v3StHsyAu
Vt+k54V1/1dGEzWJxZdIxaSH93MsywnW+iBhnFrLgEINnOyubAQ=
=MVm1
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/447ef69b-53cf-0f40-c126-dfff13f94511%40qubes-os.org.

Re: [qubes-users] etiquette for reviving old threads?

2020-01-04 Thread Andrew David Wong

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 2019-12-31 7:16 AM, trueriver wrote:
> Hi I have found some new info relating to an old thread (~1 yr).
> What's the etiquette here: do I add a new reply to the old thread,
> or do I start a new one?
>
> I ask because different forums I am on have different requests
> about this one! ... oh yes and because I have noticed ppl here have
> quite firm views about etiquette (eg top posting) and I don't want
> to offend ;)
>
> Warmly R~~
>

I see no problem with replying to old threads, as long as the reply is
on-topic. Arguably, it's better than starting a new thread, because it
keeps the discussion in one place.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl4Qh8UACgkQ203TvDlQ
MDCtvQ//UyyJXXKlQTJYZ1SKcbHa313jKqKVNfwIwnc1X/VXTIQvhjsjVVHDmhCs
D2GQ3wcuBEkB+sddkNglOC1TD/jhKIe8qya/jOeY6/p5MqmC4dUWcOjJstL/wEY9
2MwXSnkVi/nr2EvdZ+3ppBujHbJ1jTTNoPCnrQ5Bwr/u7poE8ITRrDj7aedwFweX
xb/srHHeHJ297vrcrIH+SjZpqj5Wk4IDESH5b3nZZjviVGWOQr89NbNQYOol3a5v
GItL8QSTP5LRJUOWrVw7WqLj34BsaytDL96XW/An/UktfGKlMQ2UWigPo/UK9boZ
AKVH00o4a9E/DPQ0Tp9UrUH36r7VBhLRjncLMEIr1H1Shki0e2dap9Rk9qWKTM2L
Rn+TydHxpxCrxfbKxK+Jtd6MmPvxaeJmON2khD36HwpsNtFzyoxBiTzrqclYbAxA
58LphDn4NeKjtLq0CeaUnrSHPZZoHMEjB+lDmO0H9W084dkUs4ViWFTXVz3CrqDC
L47tjA+YcyQqa+4USOu2vZL9wEHAm5xILJPfYWEniBMz+PTnIhNlN9u7MX+pdvD2
H8E79ZmAwFt/9YOnGZoE7/QRUHEFlIPmHlZcFQ8oJUpOtI0E98o5Xdpu+Z2Z5gXU
qPxbviGuPRZOKJdo4Wzdqrup3GlQ5Uf1YupsiYBXTI7pvIHHJ4o=
=cQ9W
-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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/64898d5b-dcf5-550a-43b8-610c46e755bd%40qubes-os.org.

Re: [qubes-users] Re: sys-usb issues recognizing devices & maintaining drive connections

2020-01-04 Thread Lorenzo Lamas



On Saturday, January 4, 2020 at 10:51:47 AM UTC+1, awokd wrote:
>
> > When it is not recognizing devices, the Qubes Devices Widget shows an 
> > additional device: "sys-usb:2-1:1 - 138a_003c_0030009d7e88". It is not 
> > visible when everything works fine. Do you have that as well? 
>
> An "lsusb" inside sys-usb might help identify that device. 
>
>
This is the output of lsusb:
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 138a:003c Validity Sensors, Inc. VFS471 Fingerprint 
Reader
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

-- 
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/2e3cff33-819e-4495-8dba-3d8fb62667cd%40googlegroups.com.

Re: [qubes-users] What happened to "paranoid mode"?

2020-01-04 Thread Anil Eklavya

I wasn’t aware of these options. Thanks for pointing out. I will certainly try 
them out.

I agree with all your points about backup being practical and usable. The 
password is the weak link here’ as everywhere’ just like private keys. Perhaps 
something like YubiKey plus KeePass can solve this problem. Or someone may have 
a better suggestion.

I had once tried setting up YubiKey on Qubes, but there was some problem. I 
will get around to solve them as YubiKey is known to work with Qubes. I made 
the mistake of trying it out on MacOS Catalina, but all hell broke lose. I do 
use it on Windows, Google etc.

Regards,

Anil

> On 04-Jan-2020, at 4:41 PM, dhorf-hfref.4a288...@hashmail.org wrote:
> 
> On Sat, Jan 04, 2020 at 03:56:49PM +0530, Anil Eklavya wrote:
>> A better way to backup and restore will make Qubes much more usable,
>> preferably at some point using something like rsync, as they have
>> already been considering. This is one crucial feature that makes it
>> difficult for common users to use this OS as a default.
> 
> idgi, why dont these people use whatever backup solution they prefer?
> 
> i have been using "borgbackup" to make automated, hourly, incremental
> backups of my qubes machines since qubes3, even did the move
> from qubes3 to qubes4 by "reinstall, restore" or use "backup on machine
> x, restore on machine y" to move appvms or even templates around.
> 
> "restic" looks to have a very similar featureset and i heard good things
> about it, might have used it if i had found it before borg.
> 
> in comparison, "qubes-backup" is about as useful as considering "tar"
> to be the actual default backup solution of a plain linux.
> dont get me wrong, i am not uninstalling tar or qubes-backup, but
> i cant remember the last time i was desperate enough to actualy
> use either for a backup.
> 
> three important points wrt backups in the real world:
> - backups have to be automated + background, or they wont happen.
> - backups have to be incremental, or they wont happen frequently.
> - and unless you have a restore process you are familiar with and
>  use at least sometimes ... 
>  ... you dont have a (real) backup you should rely on.
> 
> 

-- 
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/9FA0DE1A-7AD3-45C2-965D-CD3DD9758271%40gmail.com.

Re: [qubes-users] What happened to "paranoid mode"?

On Sat, Jan 04, 2020 at 03:56:49PM +0530, Anil Eklavya wrote:
> A better way to backup and restore will make Qubes much more usable,
> preferably at some point using something like rsync, as they have
> already been considering. This is one crucial feature that makes it
> difficult for common users to use this OS as a default.

idgi, why dont these people use whatever backup solution they prefer?

i have been using "borgbackup" to make automated, hourly, incremental
backups of my qubes machines since qubes3, even did the move
from qubes3 to qubes4 by "reinstall, restore" or use "backup on machine
x, restore on machine y" to move appvms or even templates around.

"restic" looks to have a very similar featureset and i heard good things
about it, might have used it if i had found it before borg.

in comparison, "qubes-backup" is about as useful as considering "tar"
to be the actual default backup solution of a plain linux.
dont get me wrong, i am not uninstalling tar or qubes-backup, but
i cant remember the last time i was desperate enough to actualy
use either for a backup.

three important points wrt backups in the real world:
- backups have to be automated + background, or they wont happen.
- backups have to be incremental, or they wont happen frequently.
- and unless you have a restore process you are familiar with and
  use at least sometimes ... 
  ... you dont have a (real) backup you should rely on.

-- 
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/2020010403.GB8973%40priv-mua.

Re: [qubes-users] What happened to "paranoid mode"?

2020-01-04 Thread Anil Eklavya

A better way to backup and restore will make Qubes much more usable, preferably 
at some point using something like rsync, as they have already been 
considering. This is one crucial feature that makes it difficult for common 
users to use this OS as a default.

> On 04-Jan-2020, at 3:08 PM, 'awokd' via qubes-users 
>  wrote:
> 
> tetrahedra via qubes-users:
>> From back in the 3.2 era:
>> 
>> https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
>> $ qvm-backup-restore --paranoid-mode
>> 
>> On my 4.0 install this option does not appear. Is it no longer
>> considered necessary?
>> 
> Looks like it is coming back:
> https://github.com/QubesOS/qubes-issues/issues/5310.
> 
> -- 
> - don't top post
> Mailing list etiquette:
> - trim quoted reply to only relevant portions
> - when possible, copy and paste text instead of screenshots
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to qubes-users+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/8255dbcc-7e09-eb18-cce3-17aa54dcfa82%40danwin1210.me.

-- 
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/8AC436C7-D3C0-435C-9AF2-A9DB6D3441BA%40gmail.com.

[qubes-users] Re: HCL - Purism Librem 15 v4

2020-01-04 Thread mr . morfius

Regarding the installation of Qubes OS on Librem 15 v4 - Matt DeVillier 
said: "Everything works". But it seems that TPM does not work on this 
laptop. And this is very important. Could you clarify the situation 
regarding TPM?

-- 
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/ae39df3c-1259-4b61-b071-a3c29ec9543a%40googlegroups.com.

Re: [qubes-users] Which Qemu does Qubes have and how to use?

Guerlan:
> I'm trying to install macOS on Qubes. For it, it needs Qemu. There are two 
> qemu-* in dom0:
> 
> qemu-img-xen and qemu-nbd-xen
> 
> I can't find options to see which versions of qemu they are. Where's the 
> simple `qemu` command? And is it rigth to run it in dom0?
> 
You don't want to install qemu in dom0. You could try installing macOS
in an HVM- https://www.qubes-os.org/doc/standalone-and-hvm/, but I
haven't heard of it running on Qubes before.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f402a041-0dc4-5793-5820-1d223d2c16c7%40danwin1210.me.

Re: [qubes-users] Re: sys-usb issues recognizing devices & maintaining drive connections

Lorenzo Lamas:
> 
> On Friday, January 3, 2020 at 11:02:24 PM UTC+1, scal...@posteo.net wrote:

>> But the other problem I've had with sys-usb is connecting to external 
>> drives. Here are the copy speeds I get on my machine to an external usb 
>> device: 
>>
>> Tails OS 33mb/sec 
>> Qubes OS 12mb/sec 

>> This is my hardware: https://www.coreboot.org/Board:asus/kgpe-d16 

Try adding irqpoll to the end of your kernelopts in qvm-prefs sys-usb.
Had similar behavior with my Corebooted AMD. Please let me know if it
helps you. I think root cause is IRQ setup table issues in Coreboot, but
I'm not sure yet how to confirm or fix.

> When it is not recognizing devices, the Qubes Devices Widget shows an 
> additional device: "sys-usb:2-1:1 - 138a_003c_0030009d7e88". It is not 
> visible when everything works fine. Do you have that as well?

An "lsusb" inside sys-usb might help identify that device.

> I haven't found a solution, so I can't help you there, unfortunately.
> I'm on a 2nd gen Intel i5 laptop btw.

Suspect it is a different problem than above, but agree the symptoms
seem similar.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9a1b1f47-472f-9f72-adf0-ea63d662d50b%40danwin1210.me.

Re: [qubes-users] What happened to "paranoid mode"?

tetrahedra via qubes-users:
> From back in the 3.2 era:
> 
> https://www.qubes-os.org/news/2017/04/26/qubes-compromise-recovery/
> $ qvm-backup-restore --paranoid-mode
> 
> On my 4.0 install this option does not appear. Is it no longer
> considered necessary?
> 
Looks like it is coming back:
https://github.com/QubesOS/qubes-issues/issues/5310.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8255dbcc-7e09-eb18-cce3-17aa54dcfa82%40danwin1210.me.

Re: [qubes-users] "kfd kfd: error getting iommu info. is the iommu enabled?"

Claudia:
> I'm getting this message in my logs, about an IOMMU error, on both 4.0.2 and 
> the F31-based 4.1 build. I'm as certain as I can be that the IOMMU is enabled 
> in BIOS. I'm having issues with passthru and I'm wondering if this might be 
> the cause. 

> https://bugzilla.redhat.com/show_bug.cgi?id=1404139
> This thread says it's not a bug, it's just because the system doesn't support 
> IOMMUv2 and amdkfd (whatever that is) requires IOMMUv2 (whatever that is) for 
> HSA (whatever that is). I don't really know what any of that means. 

> Or does it just mean that my GPU is not protected by the IOMMU (same as 
> iommu=no-igfx on Intel) and I don't have to worry about it?

I saw in a different thread you made progress, so this is probably
outdated. However, I think your conclusions are correct. If your IOMMU
was not working correctly, you would have problems starting HVMs period.
The Xen logs look similar to mine. I don't have kfd on my system.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ebc3a9f9-c7c8-477d-6d85-e2a76b9ea33f%40danwin1210.me.

Re: [qubes-users] IBM X3550 M4 - Ethernet connection not working