[qubes-users] Re: CentOS Virtualization From Multiple .vmdk

[Drew White]

1. Create the HVM.
2. use CLI and browse to the directory.
3. Run:
  #  qemu-img convert {path/to/vmdk}CentOS\ 7.x\ 64-bit.vmdk root.img

This does work. I have done it many times.


On Wednesday, 11 April 2018 22:59:30 UTC+10, hype  wrote:
> Hello everyone, thank you for your help :)
> 
> I'm not having success creating a CentOS 7.6 (x86_64) VM from multiple .vmdk 
> files. I've attempted to follow the official Qubes HVM guide and other guides 
> on the Internet.
> 
> The files:
> 
> CentOS 7.x 64-bit-s001.vmdk
> CentOS 7.x 64-bit-s002.vmdk
> CentOS 7.x 64-bit-s003.vmdk
> CentOS 7.x 64-bit-s004.vmdk
> CentOS 7.x 64-bit-s005.vmdk
> CentOS 7.x 64-bit-s006.vmdk
> CentOS 7.x 64-bit-s007.vmdk
> CentOS 7.x 64-bit-s008.vmdk
> CentOS 7.x 64-bit-s009.vmdk
> CentOS 7.x 64-bit-s010.vmdk
> CentOS 7.x 64-bit-s011.vmdk
> CentOS 7.x 64-bit.nvram
> CentOS 7.x 64-bit.vmdk
> CentOS 7.x 64-bit.vmsd
> CentOS 7.x 64-bit.vmx
> CentOS 7.x 64-bit.vmxf
> 
> This runs CentOS with a GUI successfully under VirtualBox on Linux.
> 
> I have tried these sections of following guide:
> 
> https://www.qubes-os.org/doc/hvm/#converting-virtualbox-vm-to-hvm
> https://www.qubes-os.org/doc/hvm/#creating-an-hvm-domain
> 
> Here are steps I'm taking now to provide more information:
> 
> 
> 
> 
> # Convert vmdk to raw:
> qemu-img convert *.vmdk -O raw image.img
> 
> 
> 
> 
> # Qube Manager - Create new Qube
> # Name and label: centos
> # Type: Standalone qube not based on a template
> # Advanced: install system from device
> 
> 
> 
> 
> # Start CentOS
> qvm-start centos --cdrom=TEMP:/home/user/image.img
> 
> 
> 
> 
> # centos window opens with the following output:
> SeaBIOS (version ...)
> Machine UUID ...
> Booting from DVD/CD...
> Boot failed: Could not read from CDROM (code 0004)
> Booting from Hard Disk...
> Boot failed: not a bootable disk
> 
> Booting from Floppy...
> Bootfailed: could not read the boot disk
> 
> No bootable device.
> 
> 
> 
> 
> # Trying with hddisk as per:
> https://groups.google.com/d/msg/qubes-users/84IjinPx_ng/eWFv81S4tnsJ
> qvm-start centos --hddisk=TEMP:/home/user/image.img
> 
> 
> 
> 
> # F5 and Copying to Dom0 Suggestions also fail:
> https://groups.google.com/d/msg/qubes-users/84IjinPx_ng/mYYfbj6mSeIJ
> 
> Could something here be the problem?
> qemu-img convert *.vmdk -O raw image.img
> 
> I don't know what else to try...
> 
> Thanks for your help. :)

-- 
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/0cf7c251-4905-47e3-8357-94d08cb7c44f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Offtopic :: reasonable secure routers?

[john]

I have some ddwrt flashed to mine, and haven't updated the firmware 
since post heart bleed, and AFAIK, there is no reason to update,  I 
probably have it misconfigured as routers are like some other Greek 
language to myself ...


anyway, this is way off topic, and your not "top posting"  :P

--
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/2d7c179e-e294-83a8-0844-27c498483b44%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes R4.0 broken by 'TypeError: not enough arguments...' for most qvm-* commands

['awokd' via qubes-users]

On Fri, April 13, 2018 12:33 am, Pablo Di Noto wrote:

> Ah! The joy! Now back to R4.0 without massive reinstall.
>
>
> Thanks Marek, awokd and techg...!

I think you taught me more than I helped on this one! Thanks for sharing
your resolution.



-- 
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/04dac88f740f67b95a41f3d69060abe7.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

[Pablo Di Noto]

> > > > You could also try to revert to earlier revision using "qvm-volume
> > revert sys-net:private" for example.
> 
> Will try that tonight.
> 

Unfortunately, that was not possible for the service VMs.
For the only important AppVM that had -back and -back missing, the command 
`qvm-block revert p-2018d:private` was enough.

> > > I remember there was some Saltstack magic to recreate the services vms, 
> > > but could not find anything for R4.0... So I had to revert to R3.2 for 
> > > the time being.
> > 
> > https://www.qubes-os.org/doc/salt/
> > Especially links at the bottom:
> > https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/README.rst
> 
> Thanks. Will also try that tonight.

The way I recreated all sys-* service VMs was:

# You need to unset sys-firewall as netvm for AppVMs
# and unset sys-net as netvm for sys-firewall:
dom0$ qvm-prefs --set  netvm ''
dom0$ qvm-prefs --set sys-firewall netvm ''

# The delete all service VMs qubes:
dom0$ qvm-remove sys-usb
dom0$ qvm-remove sys-firewall
dom0$ qvm-remove sys-net

# Make sure the right salt top files are enabled:
dom0$ sudo qubesctl top.enable qvm.sys-net
dom0$ sudo qubesctl top.enable qvm.sys-firewall
dom0$ sudo qubesctl top.enable qvm.sys-usb
dom0$ sudo qubesctl state.highstate

and that should be all. You have to restore 'sys-firewall' as netvm for all the 
qubes you want networking and thing should be pretty much as they were after 
install. Note that all new service VMs will have different IP address than 
their deceased counterparts, but firewall would be able to cope with that.

Ah! The joy! Now back to R4.0 without massive reinstall.

Thanks Marek, awokd and techg...!

-- 
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/d343c920-7401-475d-a340-39df7c4b3afa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Offtopic :: reasonable secure routers?

[taii...@gmx.com]

On 04/12/2018 09:21 AM, Steve Coleman wrote:

> On 04/12/18 05:32, Jo wrote:
>> My suggestion would be the Turris Omnia. Im using it myself in
>> various cases and im very happy with it.
>
> I second this opinion. Its Open Source (OpenWrt), downloads its own
> patches to keep up with any security issues or exploits in the wild.
> Unless of course you choose to be paranoid enough to do your own
> builds/patches.
It is not open source because it does not have libre firmware nor actual
schematics.

I can't believe peoples standards have fallen so far down that simply
letting you run linux and publishing the board diagram is considered
"open source hardware"

On 04/12/2018 02:04 AM, Giulio wrote:

> In my opinion the best affordable option is using a PC Engines APU2 with 
> OpenBSD https://www.pcengines.ch/apu2.htm (but of couse you can use 
> linux/FreeBSD too).
The APU2 has AMD PSP so I would not get it, whereas the APU1 doesn't.

On 04/12/2018 02:01 AM, 799 wrote:

> having a reasonable secure OS and maybe some additional freedom by using
> Coreboot is great, but might not be enough.

I would use a KCMA-D8 running a libre version of coreboot and OPNSense.
It has two quality onboard nics and various pci-e slots.

pfsense is now controlled by an evil corporation that is forcing
undesired changes and privacy violations on people such as:
* Mandating AES-NI to arbitrary make older computers not work with it,
to try and encourage people to buy their pre-built routers.
* Adding a phone home function that sends your serial numbers and
various data to rubicon communications - this setting is on by default
and for some reason turns back on randomly.
* Ignoring basic security concepts such as signed updates and .isos
because "we have a hash hosted on two separate servers" and insulting me
when I protested.
* Insulting their competitors by making a website full of lies, nazi
images and porn clipart.

https://en.wikipedia.org/wiki/OPNsense
https://opnsense.org/opnsense-com/
"In November 2017, a World Intellectual Property Organization panel
found that Netgate, the copyright owner of pfSense, had been using the
domain opnsense.com in bad faith to discredit OPNsense, and obligated
Netgate to transfer the domain to Deciso. The Netgate party tried to
invoke the fair use clause and claimed that the domain name "has been
used for a parody website"; it was rejected on the basis that free
speech does not cover registration of domain names.[6]"

Does that sound like a trustworthy company lead by mature individuals?

I suggest the use of OPNSense instead of pfsense - the founder of
pfsense has not been in control of the project for a long time.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7171dd4b-f7b8-3e65-b775-6e49fa5830f3%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


0xDF372A17.asc
Description: application/pgp-keys

Re: [qubes-users] Q4 Laptops...

[taii...@gmx.com]

On 04/12/2018 08:49 AM, cooloutac wrote:

> In my case I found uefi mode works better for Qubes.   For example using 
> legacy bios mode i have many wake from sleep problems,  such as usb mouse in 
> sys-usb not working after sleep.  system becoming unresponsive.
>
> Booting in uefi mode I dont' have those problems.  I think eventually we will 
> have no choice but to use uefi cause all hardware will be designed for it.
>
Commodity hardware in the future will suck and won't allow you to run
your own distro, or even your own programs unless you pay for a
"developer" computer. This is the goal of microsoft.

The future for owner controlled high performance devices is POWER, the
TALOS 2 is now in full production and the benchmarks indicate that it
costs thousands less than an intel/amd system with equivilant performance.

For once we have a unicorn - a libre firmware system that is actually
fast and brand new.
> Unfortunately using uefi mode does not give any security benefits since Qubes 
> doesn't support secure boot
>
Oh boy here we go again with
linux-distro-sucks-unless-it-supports-microsoft-technology
https://www.phoronix.com/scan.php?page=news_item=UEFI-Kernel-Lockdown-Concerns

Linus describes Secure Boot as being "pushed in your face by people with
an agenda."
Even linus agrees with me that these things aren't happening in a vacuum.

Remember guys if something is truly good it doesn't need to be forced on
you "for your own good"
> or secure flash.
>
Operating systems should not be modifying EEPROM settings - you are free
to use flashrom to do that yourself if you so desire.

I grow increasingly tired of your uninformed comments.

-- 
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/a1dd081d-1541-eec3-29b3-165368dcdf5e%40gmx.com.
For more options, visit https://groups.google.com/d/optout.


0xDF372A17.asc
Description: application/pgp-keys

Re: [qubes-users] Re: Qubes R4.0 broken by 'TypeError: not enough arguments...' for most qvm-* commands

[Brendon Green]

Check for Meta% above 80%

On Thu, 12 Apr 2018 at 21:21 awokd  wrote:

> On Thu, April 12, 2018 3:20 am, techgee...@gmail.com wrote:
> > On Wednesday, 11 April 2018 08:29:48 UTC+12, Pablo Di Noto  wrote:
> >
> >> Hello,
> >>
> >>
> >> Any debugging tips?
> >>
> >
> > You have almost exactly described my scenario.
> >
> >
> > You can work around the TypeError exception by editing
> > /usr/lib/python3.5/site-packages/qubesadmin/exc.py, as I did.  Please
> > note, however, that the lines _must_ be indented with spaces (not tabs);
> > as Python3 is very particular about indentation style.
> >
> > If, as I suspect, the root cause of your problem is a lack of metadata
> > space on pool00; you can confirm this by typing "sudo lvs" into a
> > console.  You will then need to figure out a way to enlarge that metadata
> > volume.
>
> That's certainly a non-intuitive failure mode. How did you find that? I'm
> not experiencing it myself, but what would one look for in "sudo lvs"-
> Meta% at 100% on one of the pools?
>
>
>

-- 
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/CAJrT%2BYmYVZtk%3DWQDNEOUx%3DgSU5M9svf%3DH_Tev3Q0GXwCHveCTQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

[Pablo Di Noto]

> > > If, as I suspect, the root cause of your problem is a lack of metadata 
> > > space on pool00; you can confirm this by typing "sudo lvs" into a 
> > > console.  You will then need to figure out a way to enlarge that metadata 
> > > volume.
> > 
> > Yes, you are right, the `pool00` volume metadata was >96% when this 
> > happened. The thing is that the volume metadata was set to a quite small 
> > size after install (96mb on a 46gb pool) and after install was on ~20% 
> > usage. I started to use the system, testing stuff with DispVMs, restoring 
> > my debian templates and some work VMs. After a couple of days of usage the 
> > metadata climbed very little, to 27-28%.
> > 
> > I tried to have a second pool to hold my machines, precisely to avoid 
> > issues with thin provisioning on the pool holding `root` and `swap` and 
> > services vms. But the lack of support for cloning/moving between pools made 
> > that effort moot.
> > 
> > So I `lvextend`ed `pool00` and forgot to properly enlarge it's  
> > `pool00_tmeta` counterpart.
> 
> What sizes you have there?
> For me tmeta is 118MB for a ~450GB pool00. And after few months of usage
> it's still at 33%...

An install on a 60G disk partition had a pool00 of 43G created with a 
pool00_tmeta of 44M (11 extents). Later, the pool00 was extended to 147.7G and 
the pool00_tmeta left as is by mistake. 

The metadata became full, and after that the pool00_tmeta was extended to 300M 
by adding 256M.

> > When doing some more customization, including restoring more larger sized 
> > qubes and cloning/renaming qubes it seems the metadata usage climbed really 
> > fast and hit this bug.
> > 
> > Unfortunately, could not recover from that.
> > 
> > It looks like qubes lvm actions while metadata was full may have corrupted 
> > the metadata somehow, since I could enlarge and repair the thin metadata 
> > from a live cd, but many of the volumes that where in use where never 
> > available again. The -private and -snap for the qubes that were running 
> > (not sure how to discard them) and also all the volumes of the qubes being 
> > restored and services vms are lost ("NOT available" as lvm status)
> 
> You could also try to revert to earlier revision using "qvm-volume
> revert sys-net:private" for example.

Will try that tonight.

> > I remember there was some Saltstack magic to recreate the services vms, but 
> > could not find anything for R4.0... So I had to revert to R3.2 for the time 
> > being.
> 
> https://www.qubes-os.org/doc/salt/
> Especially links at the bottom:
> https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/README.rst

Thanks. Will also try that tonight. 

-- 
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/cd525562-ead8-4559-9326-c31787b438dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

[Marek Marczykowski-Górecki]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Thu, Apr 12, 2018 at 08:19:10AM -0700, Pablo Di Noto wrote:
> > techg...@gmail.com
> > If, as I suspect, the root cause of your problem is a lack of metadata 
> > space on pool00; you can confirm this by typing "sudo lvs" into a console.  
> > You will then need to figure out a way to enlarge that metadata volume.
> 
> Yes, you are right, the `pool00` volume metadata was >96% when this happened. 
> The thing is that the volume metadata was set to a quite small size after 
> install (96mb on a 46gb pool) and after install was on ~20% usage. I started 
> to use the system, testing stuff with DispVMs, restoring my debian templates 
> and some work VMs. After a couple of days of usage the metadata climbed very 
> little, to 27-28%.
> 
> I tried to have a second pool to hold my machines, precisely to avoid issues 
> with thin provisioning on the pool holding `root` and `swap` and services 
> vms. But the lack of support for cloning/moving between pools made that 
> effort moot.
> 
> So I `lvextend`ed `pool00` and forgot to properly enlarge it's  
> `pool00_tmeta` counterpart.

What sizes you have there?
For me tmeta is 118MB for a ~450GB pool00. And after few months of usage
it's still at 33%...

> When doing some more customization, including restoring more larger sized 
> qubes and cloning/renaming qubes it seems the metadata usage climbed really 
> fast and hit this bug.
> 
> Unfortunately, could not recover from that.
> 
> It looks like qubes lvm actions while metadata was full may have corrupted 
> the metadata somehow, since I could enlarge and repair the thin metadata from 
> a live cd, but many of the volumes that where in use where never available 
> again. The -private and -snap for the qubes that were running (not sure how 
> to discard them) and also all the volumes of the qubes being restored and 
> services vms are lost ("NOT available" as lvm status)

You could also try to revert to earlier revision using "qvm-volume
revert sys-net:private" for example.

> I remember there was some Saltstack magic to recreate the services vms, but 
> could not find anything for R4.0... So I had to revert to R3.2 for the time 
> being.

https://www.qubes-os.org/doc/salt/
Especially links at the bottom:
https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/README.rst

> I will keep the failing install for debugging, or may be able to recover if 
> someone can provide any tips about:
> 
> - How to recreate sys-net, sys-firewall and sys-usb on a R4.0 system
> - how to recover a qube whose -snap volumes are no longer available (I have 
> no problem losing these short-term data)
> 
> Thanks for pointing to the right direction!
> 


- -- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlrMuusACgkQ24/THMrX
1yy3lQf/cO0oe9uOUviiKwgdf6+fEzhCbn6XUkmAU7MLLAkYC1uCAwE3DoT8MBGt
bbGkpmWq9gijUCJeWzUD0Z2k1QkZWDdiMgEE8nSgiqyS1O6uNxqqO0ucozWe69Ud
FWwmxkCATwX+FK239+HJSO9Jq6/Izb59qbvB1kwewQheqGkZVF9ISNE3AopkMjG8
4RBy1J0dVjHH3wxHtl9N3Z6/4mVwFquLwlE7cM+kTRpFfPtwvrBrNavfYTrEX5lz
ALBvsh/eunXBOmc4FNSGHj2yaKnNZibfBVDOoBGaexXt1G0ykpu9aou8tQrKv0zl
FqhhNHp9DeOdHm3kP0h1d6PZW1EGiw==
=5Ksa
-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/20180412184252.GB2275%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] R4-Win7-64 Installation problem

[Lloyd]

>
>
>
> Did you attach that USB controller to your win7 qube? Try to detach it
> first, before starting?
>

Thanks, you are right and it worked.

Now the windows installation start screen appears, but it stops with a
message "a required cd ROM driver is needed.."

Is there any such driver available ?

>

-- 
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/CAA10ZTpMTgdpfULqapUgAq3eiHjhdzgn0YaGL6nvF05v9PRUCw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

[Pablo Di Noto]

> techg...@gmail.com
> If, as I suspect, the root cause of your problem is a lack of metadata space 
> on pool00; you can confirm this by typing "sudo lvs" into a console.  You 
> will then need to figure out a way to enlarge that metadata volume.

Yes, you are right, the `pool00` volume metadata was >96% when this happened. 
The thing is that the volume metadata was set to a quite small size after 
install (96mb on a 46gb pool) and after install was on ~20% usage. I started to 
use the system, testing stuff with DispVMs, restoring my debian templates and 
some work VMs. After a couple of days of usage the metadata climbed very 
little, to 27-28%.

I tried to have a second pool to hold my machines, precisely to avoid issues 
with thin provisioning on the pool holding `root` and `swap` and services vms. 
But the lack of support for cloning/moving between pools made that effort moot.

So I `lvextend`ed `pool00` and forgot to properly enlarge it's  `pool00_tmeta` 
counterpart.

When doing some more customization, including restoring more larger sized qubes 
and cloning/renaming qubes it seems the metadata usage climbed really fast and 
hit this bug.

Unfortunately, could not recover from that.

It looks like qubes lvm actions while metadata was full may have corrupted the 
metadata somehow, since I could enlarge and repair the thin metadata from a 
live cd, but many of the volumes that where in use where never available again. 
The -private and -snap for the qubes that were running (not sure how to discard 
them) and also all the volumes of the qubes being restored and services vms are 
lost ("NOT available" as lvm status)

I remember there was some Saltstack magic to recreate the services vms, but 
could not find anything for R4.0... So I had to revert to R3.2 for the time 
being.

I will keep the failing install for debugging, or may be able to recover if 
someone can provide any tips about:

- How to recreate sys-net, sys-firewall and sys-usb on a R4.0 system
- how to recover a qube whose -snap volumes are no longer available (I have no 
problem losing these short-term data)

Thanks for pointing to the right direction!

-- 
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/6dbc17a5-6f49-46ac-8e5c-902eae7ee44d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0 on Dell XPS 13 9360 no longer boots anything!

[Mike Keehan]

> 
> Hey Mike, 
> 
> If you could find that email that would be fantastic. I have a
> similar problem on my Dell XPS 13 9343 as described later in this
> thread:
> https://groups.google.com/forum/#!topic/qubes-users/G6lMHyD16xc
> 
> Basically, I can only get Qubes 4.0 installed using Legacy boot,
> which is fine with me, but I can't get it to boot. The machine
> reboots itself every time it tries to boot Qubes, no matter if I
> install on an internal or external SSD. I would really love to get it
> working. 
> 
> Tom
> 

Hi Tom,

It sounds like you might have a different problem, but anyway, this is
what I had to do to get my UEFI boot working again.

"I had to fix the EFI - for some reason the installer messes up the
EFI partition type on the disk, and the bios doesn't recognise any boot
partition.  So I booted from a Linux cdrom and used 'fdisk' to change
the EFI partition type to EFI (which fdisk thought it was anyway!)."

I think the installer messed up the disk identifier string, which has
to be something specific for EFI.  'fdisk' fixed it.

If you haven't used fdisk before, be very carefull!  It can easily
ruin your disk partitions irrecoverably.

Best of luck,

   Mike.


-- 
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/20180412152721.2746da19.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Offtopic :: reasonable secure routers?

[Steve Coleman]

On 04/12/18 05:32, Jo wrote:
My suggestion would be the Turris Omnia. Im using it myself in various 
cases and im very happy with it.


I second this opinion. Its Open Source (OpenWrt), downloads its own 
patches to keep up with any security issues or exploits in the wild. 
Unless of course you choose to be paranoid enough to do your own 
builds/patches.



https://en.wikipedia.org/wiki/Turris_Omnia
https://www.turris.cz/doc/en/start
https://www.turris.cz/en/

--
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/835370ff-dc8a-0c3b-321f-2409ae93d784%40jhuapl.edu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Q4 Laptops...

[cooloutac]

In my case I found uefi mode works better for Qubes.   For example using legacy 
bios mode i have many wake from sleep problems,  such as usb mouse in sys-usb 
not working after sleep.  system becoming unresponsive.

Booting in uefi mode I dont' have those problems.  I think eventually we will 
have no choice but to use uefi cause all hardware will be designed for it.

 Unfortunately using uefi mode does not give any security benefits since Qubes 
doesn't support secure boot or secure flash.

-- 
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/661c47f0-cbc8-4006-bab3-5f8734e47cf0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Upgrade fedora 23 to fedora 24 on qubes 3.2

[Thomas Druilhe]

Hello,

We want to upgrade our templates from fedora23 to fedora26

1) do we have to upgrade 23 to 24 then 24 to 25 then 25 to 26 or can we do 23 
to 26 ?

2) When we tried to upgrade template issues appear : 
 - error nothing provides pulseaudio = 8.0 needed by 
qubes-gui-vm-3.2.13-1.fc24.x86_64
 - error nothing provide python(abi) = 3.6 needed by 
python3-dnf-plugins-qubes-hooks-3.2.10-1.fc24.x86_64

After some research we added "--enablerepo=qubes-vm-r3.2-current-testing" to 
the upgrade command "dnf --releasever=24 distro-sync"
we also tried to use --allowerasing option but it didn't work.

is there a fix to this error ? or Adding fedora repo is a viable workaround ? 

Thanks a lot

Thomas

-- 
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/71b13fa8-5d39-4273-a380-3a86dca444a2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Offtopic :: reasonable secure routers?

[Jo]

That is one of the main reasons im using it so often indeed.Also, it
really has a great range and potential to modify.


cheers


On 04/12/18 12:28, Franz wrote:
>
>
> On Thu, Apr 12, 2018 at 6:32 AM, Jo  > wrote:
>
> My suggestion would be the Turris Omnia. Im using it myself in
> various cases and im very happy with it.
>
>
>
> Interesting, the automatic update feature is unique. I never have time
> for updating the routers and OpenWRT is not so easy to update. Without
> updates the security may be compromised.
>

-- 
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/40022ad4-b79a-4a95-f707-9f9972996384%40seefelder-web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Offtopic :: reasonable secure routers?

[Franz]

On Thu, Apr 12, 2018 at 6:32 AM, Jo  wrote:

> My suggestion would be the Turris Omnia. Im using it myself in various
> cases and im very happy with it.
>
>
>
Interesting, the automatic update feature is unique. I never have time for
updating the routers and OpenWRT is not so easy to update. Without updates
the security may be compromised.

-- 
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/CAPzH-qCEMeK8gr5Y6zBxsR18rm3vh51PBmZF_1r6HgecsB9kmg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Offtopic :: reasonable secure routers?

[Jo]

My suggestion would be the Turris Omnia. Im using it myself in various
cases and im very happy with it.


cheers


On 04/12/18 08:01, 799 wrote:
> Hello,
>
> having a reasonable secure OS and maybe some additional freedom by
> using Coreboot is great, but might not be enough.
>
> At least in Germany most home routers are not owned by the users but
> the internet providers, even worse it ia often not possible to upgrade
> the software as a user.
> If I want to improve this situation, what do you think about librecmc
> (https://librecmc.org/faq.html), I have come across by accident?
>
> Sorry if this is non-qubes question, but I don't know that much people
> carrying about privacy and would like to hear your opinion about it.
>
> "(...)  In the light of recent events, it is more important now more
> than ever to fight for the freedom to control the software that runs
> on a given device. Users should have the freedom to control their
> devices, not the OEMs who originally made the device. Since libreCMC
> is free software, users have total control over what the software on
> their device is doing. This is important because it means that the
> community can add new features, review what the software is doing and
> make improvements that benefit the community as a whole. (...)"
>
> Regards
>
> [799]
>
>
> -- 
> 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/CAJ3yz2svo8YYKaOUyvUEqCQCcy%2B_ORWxk-P%3Dk9HbHHLi-rm-Bw%40mail.gmail.com
> .
> For more options, visit https://groups.google.com/d/optout.

-- 
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/081fdb0c-8bab-a172-3acd-8f25585a5059%40seefelder-web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes R4.0 broken by 'TypeError: not enough arguments...' for most qvm-* commands

['awokd' via qubes-users]

On Thu, April 12, 2018 3:20 am, techgee...@gmail.com wrote:
> On Wednesday, 11 April 2018 08:29:48 UTC+12, Pablo Di Noto  wrote:
>
>> Hello,
>>
>>
>> Any debugging tips?
>>
>
> You have almost exactly described my scenario.
>
>
> You can work around the TypeError exception by editing
> /usr/lib/python3.5/site-packages/qubesadmin/exc.py, as I did.  Please
> note, however, that the lines _must_ be indented with spaces (not tabs);
> as Python3 is very particular about indentation style.
>
> If, as I suspect, the root cause of your problem is a lack of metadata
> space on pool00; you can confirm this by typing "sudo lvs" into a
> console.  You will then need to figure out a way to enlarge that metadata
> volume.

That's certainly a non-intuitive failure mode. How did you find that? I'm
not experiencing it myself, but what would one look for in "sudo lvs"-
Meta% at 100% on one of the pools?


-- 
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/7d73628942f687b771626a3e16fd2b4f.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] inst.text boot option

[elbenna96]

On the line that starts with "linux", write: "inst.text" before "quiet". 
Without quotation marks.

-- 
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/7cabd452-8f1d-4327-a69f-8c9329aa14d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Offtopic :: reasonable secure routers?

[Zrubi]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/12/2018 08:01 AM, 799 wrote:

> having a reasonable secure OS and maybe some additional freedom by
> using Coreboot is great, but might not be enough.
> 
> At least in Germany most home routers are not owned by the users
> but the internet providers, even worse it ia often not possible to
> upgrade the software as a user.

If the ISP provided router is a combined modem + router device: You
may able to setup it as a modem only (bridge mode) and use your own
router.

If the ISP providing a separate (cable) modem and router: You may be
able to simply replace the router with your own one.

If your connection is some legacy PPPoE one, line ISDN, ADSL, etc Your
private router can handle that for sure.

As a last resort: just put your router between the ISP provided device
and your real LAN.


> If I want to improve this situation, what do you think about
> librecmc (https://librecmc.org/faq.html), I have come across by
> accident?

In my case the ISP router is working as a cable modem only, and I'm
using LEDE/OpenWRT on my routers and WiFi ACs.


AFAIR the librecmc is just jet another fork of LEDE/OpenWRT.
and they promise to removing non-free parts.

In my opinion non-free is a legal definition, and there is no direct
relation to security and/or privacy.


If you really care, you may build your own firmware, and then you can
decide what to include...


- -- 
Zrubi
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEw39Thm3rBIO+xeXXGjNaC1SPN2QFAlrPDgoACgkQGjNaC1SP
N2St8A//e42LzXeUgBu8p66NIqLKef7QzJyFh8AWLcEaLV6Y3nzxvsQtlT9OT2ch
KDqA79cYym9U0MxcCMwL0ZRFn8Y68Tn6gjhr5ihTXvX8CoBiKskgRifL2cnUyNA/
P7KQOZVebELUG2sAJXw90wFqrBsordlHwAoqfCZGmW0FSgUO8pohLJF6+GKXFw+1
MZxngVvjiBPxy1O9fayrbk3ZPYAgQLLGvEQjoQ0JEQQ4c22NjagFLSrL7KaDXdY2
3MHVZVWRSUDLZPoWwsy8Z50Su6zZMSo/UWfo6mo17Osi/P/l3JEyRpqVH9zLzwgC
U9uhvHO8P/C+/E20Iq6jhKNYqScqn2gPkKCbliKoQwo2230VGCcO2W26QrIMQa4A
5Lw0veP4pAmhTKZsgNhtZl+2jfhQaSTPeJhvCMRdhiJyT1wYsTmwi6DnJVlb/BdA
NcTs1XlKXoxoTkNxHQaZegP/36SlkKQA5r6B0BhbL2ebWmiI1CMSiVdSWaJtEJyT
XRZmGnZT0un5Dd/GmDP1trffnRdXpo1iL1atmQ+sx7EOzjO3lj1fejr309tzHZPL
LuDAMmIusvlQvhVJHKhtjmlKYmZb+jvk16eBD9QpJST2HZcYIUxoKPOkKPp+Wsgg
c32yVvctsrsS5/1j/T7wGFyb6EIdNQRuN47YYb6Mac5iDFInY/w=
=ffYb
-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/8046b4d2-b57a-d273-a905-51a69ab29231%40zrubi.hu.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Offtopic :: reasonable secure routers?

[799]

Hello Giulio,

Giulio  schrieb am Do., 12. Apr. 2018, 08:04:

> In my opinion the best affordable option is using a PC Engines APU2 with
> OpenBSD https://www.pcengines.ch/apu2.htm (but of couse you can use
> linux/FreeBSD too).
>

Actually this is something I am running already as 2nd device behind the
default router given by my provider.
An Alix Board running pfSense.

[799]

>

-- 
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/CAJ3yz2tqwHEWv2WXdqSebX32pp_QhyPMJzTe4QXug9uHu9eU%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Offtopic :: reasonable secure routers?

[Giulio]

In my opinion the best affordable option is using a PC Engines APU2 with 
OpenBSD https://www.pcengines.ch/apu2.htm (but of couse you can use 
linux/FreeBSD too).


On April 12, 2018 8:01:02 AM GMT+02:00, 799  wrote:
>Hello,
>
>having a reasonable secure OS and maybe some additional freedom by
>using
>Coreboot is great, but might not be enough.
>
>At least in Germany most home routers are not owned by the users but
>the
>internet providers, even worse it ia often not possible to upgrade the
>software as a user.
>If I want to improve this situation, what do you think about librecmc (
>https://librecmc.org/faq.html), I have come across by accident?
>
>Sorry if this is non-qubes question, but I don't know that much people
>carrying about privacy and would like to hear your opinion about it.
>
>"(...)  In the light of recent events, it is more important now more
>than
>ever to fight for the freedom to control the software that runs on a
>given
>device. Users should have the freedom to control their devices, not the
>OEMs who originally made the device. Since libreCMC is free software,
>users
>have total control over what the software on their device is doing.
>This is
>important because it means that the community can add new features,
>review
>what the software is doing and make improvements that benefit the
>community
>as a whole. (...)"
>
>Regards
>
>[799]
>
>-- 
>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/CAJ3yz2svo8YYKaOUyvUEqCQCcy%2B_ORWxk-P%3Dk9HbHHLi-rm-Bw%40mail.gmail.com.
>For more options, visit https://groups.google.com/d/optout.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

-- 
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/8F288F95-3501-40FB-BC0E-0D3132FB4446%40anche.no.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Offtopic :: reasonable secure routers?

[799]

Hello,

having a reasonable secure OS and maybe some additional freedom by using
Coreboot is great, but might not be enough.

At least in Germany most home routers are not owned by the users but the
internet providers, even worse it ia often not possible to upgrade the
software as a user.
If I want to improve this situation, what do you think about librecmc (
https://librecmc.org/faq.html), I have come across by accident?

Sorry if this is non-qubes question, but I don't know that much people
carrying about privacy and would like to hear your opinion about it.

"(...)  In the light of recent events, it is more important now more than
ever to fight for the freedom to control the software that runs on a given
device. Users should have the freedom to control their devices, not the
OEMs who originally made the device. Since libreCMC is free software, users
have total control over what the software on their device is doing. This is
important because it means that the community can add new features, review
what the software is doing and make improvements that benefit the community
as a whole. (...)"

Regards

[799]

-- 
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/CAJ3yz2svo8YYKaOUyvUEqCQCcy%2B_ORWxk-P%3Dk9HbHHLi-rm-Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.