Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
Why are you complaining about bugs when running a ".0rc" version? They're to be expected; if not the point of release candidates. If you want stable, run R3.2. I'm still using that as my daily driver, but from what I see of R4.0rc4 it's to the point where I'm comfortable switching as soon as I can fit it into my work stream. Others already have and are (happily) running it daily. -- 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/47530f9e6a56871059db71d9c1e21bb6.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Feedback Qubes-R4.0-rc4 on a Lenovo Thinkpad P71
Before installing Qubes-R4.0-rc4-x86_64 on my laptop in UEFI mode but not secure boot, I first had to follow the instructions on https://www.qubes-os.org/doc/thinkpad-troubleshooting/ summarized below: In a nutshell, you need to use the Fedora livecd-tools to make a Qubes Installation USB Stick from the Qubes ISO image, then update the label on the partition of that USB stick to “BOOT”, and then update the BOOT/EFI/xen.cfg file on the USB stick so that all labels point to BOOT. Then it installed properly. However, there still seems to be some issues as reported by dmesg output below. -- ~]$ sudo dmesg --notime --show-delta --level=err,warn [<0.00>] ACPI Error: [\_SB_.PCI0.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170728/dswload-210) [<0.11>] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20170728/psobject-252) [<0.000229>] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading table (20170728/tbxfload-228) [<0.012538>] ACPI Error: 1 table load failures, 11 successful (20170728/tbxfload-246) [<0.003614>] ENERGY_PERF_BIAS: Set to 'normal', was 'performance' [<0.01>] ENERGY_PERF_BIAS: View and update with x86_energy_perf_policy(8) [<0.001585>] cpu 0 spinlock event irq 121 [<0.001459>] cpu 1 spinlock event irq 133 [<0.000567>] cpu 2 spinlock event irq 140 [<0.000315>] cpu 3 spinlock event irq 147 [<0.000803>] cpu 4 spinlock event irq 154 [<0.000200>] cpu 5 spinlock event irq 161 [<0.000787>] cpu 6 spinlock event irq 168 [<0.000184>] cpu 7 spinlock event irq 175 [<0.001973>] Grant table initialized [<1.030409>] (NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info(). [<0.026886>] hpet_acpi_add: no address or irqs in _CRS [<1.260721>] acpi PNP0C14:02: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [<0.67>] acpi PNP0C14:03: duplicate WMI GUID 05901221-D566-11D1-B2F0-00A0C9062910 (first instance was on PNP0C14:01) [<0.021726>] i915: unknown parameter 'preliminary_hw_support' ignored [<0.008035>] ACPI Warning: \_SB.PCI0.GFX0._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20170728/nsarguments-100) [<0.000105>] ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20170728/nsarguments-100) [<0.373511>] nouveau :01:00.0: bus: MMIO read of FAULT at 022554 [ IBUS ] [<0.001572>] nouveau :01:00.0: bus: MMIO read of FAULT at 10ac08 [ IBUS ] [<0.874699>] [Firmware Bug]: ACPI(PEGP) defines _DOD but not _DOS [< 69.549364>] device-mapper: thin: Data device (dm-2) discard unsupported: Disabling discard passdown. [<0.466515>] systemd: 26 output lines suppressed due to ratelimiting [<0.708450>] (NULL device *): hwmon_device_register() is deprecated. Please convert the driver to use hwmon_device_register_with_info(). [<5.237246>] kauditd_printk_skb: 81 callbacks suppressed [< 88.634764>] kauditd_printk_skb: 1 callbacks suppressed [< 10.806499>] kauditd_printk_skb: 7 callbacks suppressed [< 72.680640>] kauditd_printk_skb: 1 callbacks suppressed [< 11.120214>] kauditd_printk_skb: 7 callbacks suppressed [< 78.707516>] kauditd_printk_skb: 1 callbacks suppressed [< 10.752228>] kauditd_printk_skb: 7 callbacks suppressed [< 75.713107>] kauditd_printk_skb: 1 callbacks suppressed [< 11.964648>] kauditd_printk_skb: 7 callbacks suppressed [< 66.095443>] kauditd_printk_skb: 147 callbacks suppressed [<6.035025>] kauditd_printk_skb: 82 callbacks suppressed [<5.029873>] kauditd_printk_skb: 102 callbacks suppressed [<5.544555>] kauditd_printk_skb: 90 callbacks suppressed [<5.002831>] kauditd_printk_skb: 88 callbacks suppressed [< 41.219150>] kauditd_printk_skb: 34 callbacks suppressed [< 36.255902>] xen_pciback: :00:14.0: cannot enable memory-write-invalidate (-22) [< 142.443039>] kauditd_printk_skb: 4 callbacks suppressed [< 198.824432>] kauditd_printk_skb: 5 callbacks suppressed -- -- 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/167ebaa8-4633-49d5-aa6a-23c550cfb5d8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
> > The biggest issue i ran into is that Qubes4 is just too immature to > > actually > > use for more than browsing and email. It was too painful for my desktop > > full-time work machine. > > I tried for 2 months, my significant other stated that I had been > > extraordinary patient with Qubes when I finally stopped using it ;) > - The priority is first and foremost security, right? > Qubes is often misunderstood if they do things in Qubes 4, which may first > show its full potential in Qubes 5 or Qubes 6. I understand security is the priority, but I too think the current state of qubes is a mess. You make a good point about the future and Q5-Q6, and maybe you are both right. Besides surfing and emails, as an end-user I may have to wait for a few years to have a mature QubesOS. I too cannot evaluate the code, but qubes-manager, system-tray, widgets paired with so many bugs is not a even close to any early beta version I would use as a daily OS. I will wait, for a few years, but that's really a highly optimistic and rather long-term speculation while dreaming about Qubes-IOT and Qubes-Cloud. All while implementing a new admin-api which roadblocked an already delayed update of QubesOS for new fedora versions and leaving qubes with half baked widget solutions in a bug-riddled mess. Regards -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4c18f2af-6550-403b-a577-a59ad3a93285%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qvm-usb is broken in Qubes 4.0 rc4
On Sunday, February 4, 2018 at 8:50:12 PM UTC-5, Fabrizio Romano Genovese wrote: > Hello all, > > When I try to attach my webcam to any appvm, I get the following message: > > Device attach failed: /usr/lib/qubes/usb-import: line 32: > /sys/devices/platform/vhci_hcd/status: No such file or directoryNo unused > port found!/usr/lib/qubes/usb-import: line 51: > /sys/devices/platform/vhci_hcd/attach: No such file or directory > > In the meantime, the devices widget thinks that everything is ok. > I was able to reproduce this error on two different machines, one upgraded > from Qubes 4.0 rc3 and another coming from a fresh install. What should I do? > > Cheers, > Fab Does it work with a flash drive as storage device? -- 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/b3fc8d8e-7dd8-47b1-939e-865b5858f8b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Building Qubes 4rc4 iso from source
On Sunday, February 4, 2018 at 10:42:05 PM UTC-5, Tim W wrote:
> On Sunday, February 4, 2018 at 8:51:45 PM UTC-5, Unman wrote:
> > On Mon, Feb 05, 2018 at 01:44:10AM +, Unman wrote:
> > > On Sat, Feb 03, 2018 at 06:52:12PM -0800, Tim W wrote:
> > > > Also when I ran setup script it required PyYaml and that was also shown
> > > > in https://www.qubes-os.org/doc/qubes-builder/ Building Qubes From
> > > > Scratch
> > > >
> > > > Then you have the build directions that there is notes to follow the
> > > > Archlinux directions for using the builder tools and they do not have
> > > > them but then it includes python.sh rather than python2.sh . The
> > > > latter is definitely needed.
> > > >
> > > > Then finally in the README.md file in the qubes-builder which you are
> > > > directed to read it has you install perl-open but not dpkg-dev
> > > > debootstrap and a few others. So we are basically given directions to
> > > > go to at least 3 different places that all have from slightly different
> > > > to completely different instructions for building qubes.
> > > >
> > > > IMHO for the advanced user who wants to build qubes from source the
> > > > ./setup script is by far the easiest to follow as it being a all
> > > > inclusive script handles many steps for you in a nice basic gui. Issue
> > > > is we need to have some very basic steps of what will work with each OS
> > > > version. It would only take 10-15 min to update a markup page for each
> > > > os. Everything is there except what works with what OS and frankly
> > > > that's all in terms of instructions that should have to change ever in
> > > > qubes current xen based format. If a dev could even just post a list
> > > > of what templates work with the version in the group I or others can
> > > > easily update the doc page. I have helped in that area before as its
> > > > one area IMO any and all qubes users can help out with and give back to
> > > > the project.
> > > >
> > >
> > > afaik the current instructions on the website are targeted to Fedora 26,
> > > the currently supported version, and should be complete.
> > > The archlinux instructions are quite out of date and the README definitely
> > > needs to be updated.
> > > I'm not sure what you mean by OS version, or most of your last
> > > paragraph. Can you clarify?
> >
> > Sorry, I've gone back to your original post and it's clearer.
> > You should be able to build all the templates referenced in the setup
> > program. If you can't, then (barring network problems) it's a bug.
> > Its a moot point whether you should be building some of the older,
> > eol templates, and whether they should be available to build.
>
> I just added Centos 7 Standard template with the ones that had already built
> correct and as before it errored out with the following:
> ---
> Building core-admin-client (rpm_spec/qubes-core-admin-client.spec) for
> centos7 vm (logfile: build-logs/core-admin-client-vm-centos7.log)
> --> build failed!
> reading sources... [ 92%] manpages/qvm-tags
> reading sources... [ 96%] manpages/qvm-unpause
> reading sources... [100%] manpages/qvm-volume
>
> /home/user/qubes-src/core-admin-client/doc/manpages/qvm-features.rst:91:
> ERROR: Unknown interpreted text role "py:pbj".
> /home/user/qubes-src/core-admin-client/doc/manpages/qvm-firewall.rst:73:
> WARNING: Bullet list ends without a blank line; unexpected unindent.
> looking for now-outdated files... none found
> pickling environment... done
> checking consistency...
> /home/user/qubes-src/core-admin-client/doc/manpages/index.rst:: WARNING:
> document isn't included in any toctree
> done
> writing... qvm-backup-restore.1 { } Checking arguments for
> 'qvm-backup-restore'
>
> Exception occurred:
> File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
> __import__(name)
> File
> "/home/user/qubes-src/core-admin-client/qubesadmin/tools/qvm_backup_restore.py",
> line 4
> SyntaxError: Non-ASCII character '\xc3' in file
> /home/user/qubes-src/core-admin-client/qubesadmin/tools/qvm_backup_restore.py
> on line 4, but no encoding declared; see
> http://www.python.org/peps/pep-0263.html for details
> The full traceback has been saved in /tmp/sphinx-err-JOw4sG.log, if you want
> to report the issue to the developers.
> Please also report this if it was a user error, so that a better error
> message can be provided next time.
> Either send bugs to the mailing list at
>
Re: [qubes-users] Re: Building Qubes 4rc4 iso from source
On Sunday, February 4, 2018 at 8:51:45 PM UTC-5, Unman wrote:
> On Mon, Feb 05, 2018 at 01:44:10AM +, Unman wrote:
> > On Sat, Feb 03, 2018 at 06:52:12PM -0800, Tim W wrote:
> > > Also when I ran setup script it required PyYaml and that was also shown
> > > in https://www.qubes-os.org/doc/qubes-builder/ Building Qubes From
> > > Scratch
> > >
> > > Then you have the build directions that there is notes to follow the
> > > Archlinux directions for using the builder tools and they do not have
> > > them but then it includes python.sh rather than python2.sh . The latter
> > > is definitely needed.
> > >
> > > Then finally in the README.md file in the qubes-builder which you are
> > > directed to read it has you install perl-open but not dpkg-dev
> > > debootstrap and a few others. So we are basically given directions to go
> > > to at least 3 different places that all have from slightly different to
> > > completely different instructions for building qubes.
> > >
> > > IMHO for the advanced user who wants to build qubes from source the
> > > ./setup script is by far the easiest to follow as it being a all
> > > inclusive script handles many steps for you in a nice basic gui. Issue
> > > is we need to have some very basic steps of what will work with each OS
> > > version. It would only take 10-15 min to update a markup page for each
> > > os. Everything is there except what works with what OS and frankly
> > > that's all in terms of instructions that should have to change ever in
> > > qubes current xen based format. If a dev could even just post a list of
> > > what templates work with the version in the group I or others can easily
> > > update the doc page. I have helped in that area before as its one area
> > > IMO any and all qubes users can help out with and give back to the
> > > project.
> > >
> >
> > afaik the current instructions on the website are targeted to Fedora 26,
> > the currently supported version, and should be complete.
> > The archlinux instructions are quite out of date and the README definitely
> > needs to be updated.
> > I'm not sure what you mean by OS version, or most of your last
> > paragraph. Can you clarify?
>
> Sorry, I've gone back to your original post and it's clearer.
> You should be able to build all the templates referenced in the setup
> program. If you can't, then (barring network problems) it's a bug.
> Its a moot point whether you should be building some of the older,
> eol templates, and whether they should be available to build.
I just added Centos 7 Standard template with the ones that had already built
correct and as before it errored out with the following:
---
Building core-admin-client (rpm_spec/qubes-core-admin-client.spec) for centos7
vm (logfile: build-logs/core-admin-client-vm-centos7.log)
--> build failed!
reading sources... [ 92%] manpages/qvm-tags
reading sources... [ 96%] manpages/qvm-unpause
reading sources... [100%] manpages/qvm-volume
/home/user/qubes-src/core-admin-client/doc/manpages/qvm-features.rst:91: ERROR:
Unknown interpreted text role "py:pbj".
/home/user/qubes-src/core-admin-client/doc/manpages/qvm-firewall.rst:73:
WARNING: Bullet list ends without a blank line; unexpected unindent.
looking for now-outdated files... none found
pickling environment... done
checking consistency...
/home/user/qubes-src/core-admin-client/doc/manpages/index.rst:: WARNING:
document isn't included in any toctree
done
writing... qvm-backup-restore.1 { } Checking arguments for 'qvm-backup-restore'
Exception occurred:
File "/usr/lib64/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
File
"/home/user/qubes-src/core-admin-client/qubesadmin/tools/qvm_backup_restore.py",
line 4
SyntaxError: Non-ASCII character '\xc3' in file
/home/user/qubes-src/core-admin-client/qubesadmin/tools/qvm_backup_restore.py
on line 4, but no encoding declared; see
http://www.python.org/peps/pep-0263.html for details
The full traceback has been saved in /tmp/sphinx-err-JOw4sG.log, if you want to
report the issue to the developers.
Please also report this if it was a user error, so that a better error message
can be provided next time.
Either send bugs to the mailing list at
[qubes-users] Re: qvm-usb is broken in Qubes 4.0 rc4
On Sunday, February 4, 2018 at 8:50:12 PM UTC-5, Fabrizio Romano Genovese wrote: > Hello all, > > When I try to attach my webcam to any appvm, I get the following message: > > Device attach failed: /usr/lib/qubes/usb-import: line 32: > /sys/devices/platform/vhci_hcd/status: No such file or directoryNo unused > port found!/usr/lib/qubes/usb-import: line 51: > /sys/devices/platform/vhci_hcd/attach: No such file or directory > > In the meantime, the devices widget thinks that everything is ok. > I was able to reproduce this error on two different machines, one upgraded > from Qubes 4.0 rc3 and another coming from a fresh install. What should I do? > > Cheers, > Fab Open a issue in qubes qit or mention it over on the qubes-devel list. -- 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/72ac85ca-ccf5-43c6-94f2-5d55876a9344%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
This is not directed toward anyone that has posted as I think all have in some fashion; be it coding or updating docs something, support. I know Tom, Awokd and Unman have. To me the only ones I feel have a right to comment on this specific topics are people that have at least contributed to the project. I am not saying I am correct but after 25 yrs of open source I have found there way to large a percentage of people wanting to be spoon fed and want and want and want. Entitlement mentality without offering anything constructive to the group collective projects. IMO that is the largest issue Qubes struggles with as an opensource project. As do many projects. It seems plenty of people want this or that even demand it but rarely are any of them willing or even capable of contributing. Of course all projects needed basic users but this project really really needs more devs. People complain about doc being outdated..then fix them. If a person is capable of loading Qubes OS they sure as hell are capable of creating or updating some Markdown pages even if it more cumbersome than a typical document format. A 3rd grader could do it. With all the users commenting in the qubes-user list there is zero reason Docs should ever be outdated for more than a week or two in any area. I have redone and created a number of doc pages and a VERY minor amount of updating a couple script and conf files. (not much of a coder) But there is no reason there are not 20-30 people that over time should be keeping these docs up to date. Tom has built a Qubes Controller (manager) based on the 4.0 code and went so far as to add in library package so other coding can be used to build. He has been super open to adding functions based on comments. If another person or two could help him with coding now that its not needed to just be python it could become the defacto Qubes GUI to manage the qubes system. That would take it off the plate of the core system devs. i plan to use his controller and if the QM does not work well I will stay with his controller. You have to consider the finances of the core qube dev that are paid. This was a huge project moving Qubes forward. Consider Qubes 1 and how rough it was. Look at where we are at now. Its a long ways. 3.2 was 3 full major revisions and many sub revisions of the same basic code where 4.0 is very different compared to the other progressive steps of this Os before. 3.1 and finally 3.2 was getting very polished and it can be a bit of a shock when you have to take a step back in polish with such a over all change. Its going to take time but the bugs will be fixed and things will be polished. I am not a coder so I will make not comments about python use etc other than it seems the reasons were memory-safety vs other. I tend to wonder if KDE issue seen are because they moved officially to XFCE. I think this may have been because of prefer of dev as users and also the low resources of devs to code. But as I said I do not have the knowledge to really speak on the topic beyond what I have seen. -- 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/65a6a008-e562-4b34-89f5-ca0049fe526b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Building Qubes 4rc4 iso from source
On Sunday, February 4, 2018 at 8:51:45 PM UTC-5, Unman wrote: > On Mon, Feb 05, 2018 at 01:44:10AM +, Unman wrote: > > On Sat, Feb 03, 2018 at 06:52:12PM -0800, Tim W wrote: > > > Also when I ran setup script it required PyYaml and that was also shown > > > in https://www.qubes-os.org/doc/qubes-builder/ Building Qubes From > > > Scratch > > > > > > Then you have the build directions that there is notes to follow the > > > Archlinux directions for using the builder tools and they do not have > > > them but then it includes python.sh rather than python2.sh . The latter > > > is definitely needed. > > > > > > Then finally in the README.md file in the qubes-builder which you are > > > directed to read it has you install perl-open but not dpkg-dev > > > debootstrap and a few others. So we are basically given directions to go > > > to at least 3 different places that all have from slightly different to > > > completely different instructions for building qubes. > > > > > > IMHO for the advanced user who wants to build qubes from source the > > > ./setup script is by far the easiest to follow as it being a all > > > inclusive script handles many steps for you in a nice basic gui. Issue > > > is we need to have some very basic steps of what will work with each OS > > > version. It would only take 10-15 min to update a markup page for each > > > os. Everything is there except what works with what OS and frankly > > > that's all in terms of instructions that should have to change ever in > > > qubes current xen based format. If a dev could even just post a list of > > > what templates work with the version in the group I or others can easily > > > update the doc page. I have helped in that area before as its one area > > > IMO any and all qubes users can help out with and give back to the > > > project. > > > > > > > afaik the current instructions on the website are targeted to Fedora 26, > > the currently supported version, and should be complete. > > The archlinux instructions are quite out of date and the README definitely > > needs to be updated. > > I'm not sure what you mean by OS version, or most of your last > > paragraph. Can you clarify? > > Sorry, I've gone back to your original post and it's clearer. > You should be able to build all the templates referenced in the setup > program. If you can't, then (barring network problems) it's a bug. > Its a moot point whether you should be building some of the older, > eol templates, and whether they should be available to build. Correct on the older templates. The oldest I would consider is fc25 and wheezy etc.. for it to be working correctly without bug I would expect to be able to choose all none EOL templates together and have it build. Would need 100+ gigs but it should work. That is what I am working towards. My original issue with setup script might have been part network and part gpg sig issue. Just would like to know and then update the offical Doc etc pages with correct info where needed. The issue with archlinux is it is referenced at least twice in other docs as to being the most uptodate instructions for building qubes and templates. Basically much of the docs are a mess as they have conflicting missing dif info. -- 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/234ee664-b03f-4df9-bff6-628fb956efb8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Building Qubes 4rc4 iso from source
On Mon, Feb 05, 2018 at 01:44:10AM +, Unman wrote: > On Sat, Feb 03, 2018 at 06:52:12PM -0800, Tim W wrote: > > Also when I ran setup script it required PyYaml and that was also shown > > in https://www.qubes-os.org/doc/qubes-builder/ Building Qubes From Scratch > > > > Then you have the build directions that there is notes to follow the > > Archlinux directions for using the builder tools and they do not have them > > but then it includes python.sh rather than python2.sh . The latter is > > definitely needed. > > > > Then finally in the README.md file in the qubes-builder which you are > > directed to read it has you install perl-open but not dpkg-dev debootstrap > > and a few others. So we are basically given directions to go to at least 3 > > different places that all have from slightly different to completely > > different instructions for building qubes. > > > > IMHO for the advanced user who wants to build qubes from source the ./setup > > script is by far the easiest to follow as it being a all inclusive script > > handles many steps for you in a nice basic gui. Issue is we need to have > > some very basic steps of what will work with each OS version. It would > > only take 10-15 min to update a markup page for each os. Everything is > > there except what works with what OS and frankly that's all in terms of > > instructions that should have to change ever in qubes current xen based > > format. If a dev could even just post a list of what templates work with > > the version in the group I or others can easily update the doc page. I > > have helped in that area before as its one area IMO any and all qubes users > > can help out with and give back to the project. > > > > afaik the current instructions on the website are targeted to Fedora 26, > the currently supported version, and should be complete. > The archlinux instructions are quite out of date and the README definitely > needs to be updated. > I'm not sure what you mean by OS version, or most of your last > paragraph. Can you clarify? Sorry, I've gone back to your original post and it's clearer. You should be able to build all the templates referenced in the setup program. If you can't, then (barring network problems) it's a bug. Its a moot point whether you should be building some of the older, eol templates, and whether they should be available to build. -- 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/20180205015143.ysqms5hyzjhb7h2z%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Please help with custom template build
On Friday, February 2, 2018 at 7:42:26 AM UTC-5, Krišjānis Gross wrote: > On Tuesday, 23 January 2018 17:36:00 UTC, Krišjānis Gross wrote: > > Hi, > > > > I am trying to build a custom installation .iso. I have an issue that I > > have purchased a new set of hardware that does not work with the current > > builds of qubes. I am trying to build the most updated version with hope > > that it could work. > > > > I am running a Fedora linux and trying to build with these instructions: > > https://www.qubes-os.org/doc/building-archlinux-template/ > > > > I use the ./setup to create the installation configuration. > > > > make install-deps goes fine. > > make get-sources goes smooth as well > > > > but I get an error when running the mage qubes command. > > Here is what I get: > > > > [krish@localhost qubes-builder]$ make qubes > > Currently installed dependencies: > > git-2.14.3-2.fc27.x86_64 > > rpmdevtools-8.10-3.fc27.noarch > > rpm-build-4.14.0-2.fc27.x86_64 > > createrepo-0.10.3-12.fc27.noarch > > debootstrap-1.0.92-1.fc27.noarch > > dpkg-dev-1.18.24-3.fc27.noarch > > python2-sh-1.12.14-2.fc27.noarch > > dialog-1.3-10.20170509.fc27.x86_64 > > dpkg-dev-1.18.24-3.fc27.noarch > > debootstrap-1.0.92-1.fc27.noarch > > PyYAML-3.12-5.fc27.x86_64 > > make[1]: Entering directory '/home/krish/qubes-builder' > > -> Preparing fc25 build environment > > -> Initializing RPM database... > > -> Retreiving core RPM packages... > > -> Verifying signatures... > > Filename: > > /home/krish/qubes-builder/cache/fc25/base_rpms/acl-2.2.52-13.fc25.x86_64.rpm > > is not signed. Exiting! > > make[1]: *** > > [/home/krish/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > > /home/krish/qubes-builder/chroot-fc25/home/user/.prepared_base] Error 1 > > make[1]: Leaving directory '/home/krish/qubes-builder' > > make: *** [Makefile:224: vmm-xen-dom0] Error 1 > > > > > > Does anyone has an idea of what I do wrong or how to resolve this? > > I have attached the builder.conf file that I have. > > Tried to build on Fedora 25 but did not succeed. Did not get the same issue > but there was something else that did not work. > Kind of gave up trying because of Qubes 4 RC4 release. > thank You to everyone for the help! Could you type out each command you do as well as your choices inside the setup script. I had issues with this and then with a few recommendation by Awokd I have built a standard 4.0rd4 and one with both minimal settups without errors. But you have to do each thing in specific order. I would recommend deleting the qubes-builder directory and start fresh. Got make sure you get the gpp sig and set the trust properly and move them into the qubes-builder directory properly as well. I am currently trying to go thru the various choices of templates to see what works and what fails. Right now I have added Centos standard into this build. Make sure you have plenty of HD space as it can take over 60 gigs for even a basic build -- 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/28a01237-110d-4a5e-8c11-0d954a5420e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Building Qubes 4rc4 iso from source
On Sat, Feb 03, 2018 at 06:52:12PM -0800, Tim W wrote: > Also when I ran setup script it required PyYaml and that was also shown > in https://www.qubes-os.org/doc/qubes-builder/ Building Qubes From Scratch > > Then you have the build directions that there is notes to follow the > Archlinux directions for using the builder tools and they do not have them > but then it includes python.sh rather than python2.sh . The latter is > definitely needed. > > Then finally in the README.md file in the qubes-builder which you are > directed to read it has you install perl-open but not dpkg-dev debootstrap > and a few others. So we are basically given directions to go to at least 3 > different places that all have from slightly different to completely > different instructions for building qubes. > > IMHO for the advanced user who wants to build qubes from source the ./setup > script is by far the easiest to follow as it being a all inclusive script > handles many steps for you in a nice basic gui. Issue is we need to have > some very basic steps of what will work with each OS version. It would only > take 10-15 min to update a markup page for each os. Everything is there > except what works with what OS and frankly that's all in terms of > instructions that should have to change ever in qubes current xen based > format. If a dev could even just post a list of what templates work with the > version in the group I or others can easily update the doc page. I have > helped in that area before as its one area IMO any and all qubes users can > help out with and give back to the project. > afaik the current instructions on the website are targeted to Fedora 26, the currently supported version, and should be complete. The archlinux instructions are quite out of date and the README definitely needs to be updated. I'm not sure what you mean by OS version, or most of your last paragraph. Can you clarify? -- 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/20180205014410.ybxrv5s56czodpec%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Mon, Feb 05, 2018 at 01:26:28AM +0100, Tom Zander wrote: > On Monday, 5 February 2018 00:55:34 CET Unman wrote: > > On Sun, Feb 04, 2018 at 08:14:57PM +0100, 'Tom Zander' via qubes-users > wrote: > > > * Having nothing but python APIs for your operating system is something > > > that makes no sense. Python was never meant for servers, or even big > > > applications. Finding a full-stack python developer is more rare than > > > finding a Bitcoin C++ developer. > > > > I'm not sure how much of this is just trolling. > > It is not trolling. > > > You obviously dont mean uses like Google, DropBox, YouTube, Reddit etc. > > Perhaps you dont know about Eve Online? Mercurial? Blender? > > Absolutely none of these use python for anywhere near the same percentage of > components as Qubes does. NONE of these? Afaik Eve and Mercurial are all Python. The rest have been almost all Python at various points. > Google is a good example, for instance they shipped proto-buffers. Which > have bindings in a long list of languages (20 or so). > > Check wikipedia for those examples, reality is much more sobering that you > think. > > > There are exceptional developers working in many companies -Google, > > NASA, Astra Zeneca, to name a few, all using python. The fact that > > you arent comfortable with it is fine, but not a reason to reject it. > > Thats moving the goalpost. Naturally there are many experienced python > developers. > > Let me re-state the point for your benefit; > > Having nothing but python bindings and having practically all your > components written in python is without a doubt very realistically limiting > the amount of people you can get hacking on Qubes. Add on top of that the > content matter, which is highly complex and in many cases includes > networking or cross-VM communication or hard-core linux components and you > limit the amount of people even more, to the extend I mentioned above. > You may be right, but I'm simply not convinced. That, of course, is irrelevant. It's a choice for Joanna and Marek to make. You are, of course, free to rewrite Qubes and its components in a language you're comfortable with. -- 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/20180205013302.mgps5nqmrfdlzpj7%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Ubuntu templates
On Sat, Feb 03, 2018 at 11:38:28AM -0800, Yuraeitha wrote: > On Saturday, February 3, 2018 at 9:11:31 AM UTC+1, Foppe de Haan wrote: > > On Saturday, February 3, 2018 at 3:56:05 AM UTC+1, Yuraeitha wrote: > > > On Thursday, February 1, 2018 at 12:56:29 AM UTC+1, Unman wrote: > > > > I'm just pushing up some PRs to remove zesty and institute build support > > > > for artful (17.10). > > > > If you cant wait there's a ready built 3.2 template you can try at: > > > > http://qubes.3isec.org/Templates > > > > > > > > unman > > > > > > This looks really nice unman. I do have a question though, which in the > > > end might just be my lack of understanding. > > > > > > Essentially, how is the build process executed in terms of security and > > > also reliability? > > > > > > I know you're one of the 13 contributors to the Qubes OS, but it'd be > > > nice knowing if this is done securely and reliable like the official > > > Qubes templates (like how Joanna explains the weak links in OS builds, > > > i.e. in one of her presentations on youtube). > > > > > > Also how come it's not released in the secondary templates community > > > repository? Is this due to license issues? > > > > > > I apologize for these questions, it's not out of lack of respect, but > > > rather probably my lack of understanding. > > > > per https://www.qubes-os.org/doc/templates/ubuntu/ : > > "These templates are currently not available in ready to use binary > > packages, because Canonical does not allow redistribution of a modified > > Ubuntu. The redistribution is not allowed by their Intellectual property > > rights policy." > > @Foppe > hmm, that is an unfortunate hard stand on license.. Canonical seems a bit too > needlessly strict here. It feels like an overkill lawyer lock-down on a > contract, to cover all ends needlessly, just to be sure nothing is > overlooked. I'm a bit sad about such mindless over-protection. Perhaps the > license wasn't even written with Ubuntu in mind, but just an overall general > protection... well I wouldn't know, but it seems like it might be. > > Perhaps they can make an exception for cases like Qubes though, it seems like > it would make good sense for them to do so, especially now when Qubes 4 is > gaining a lot of increased attention and traction. I don't personally use > Ubuntu, but it would be a nice addition to Qubes if Canonical gave their > acceptance for this use-case. > > I'm curious now after reading your post though. Since because there are other > distributions of Ubuntu out there, I might dig into the licenses on these > after half a month has passed, when I get the time for it. There must be a > reason why Ubuntu offsprings like; Kubuntu, xubuntu, Edubuntu, Ubuntustudio, > and so on, are allowed in the license. > These are really good questions: in reverse order - Canonical has a strict license policy. The offspring you mention are all licensed by Canonical and permitted to use the Ubuntu name or variants thereof. Canonical have not yet allowed Qubes a license to use Ubuntu, and the Qubes project therefore cannot distribute Ubuntu templates. Ubuntu templates are integrated in to the build system, which is designed to be as simple as possible, and almost anyone should be able to build a template for themselves. It may be possible in the future to persuade Canonical to extend licensing to Qubes. At the moment there are certain requirements on their part which makes this difficult/impossible, but I hope that we can change this at some point. So for these reasons Qubes will not release Ubuntu templates, and they are not included in the community repositories, as is clear on the page Foppe cited. When I post in these mailing lists I don't speak for Qubes: I'm posting as a Qubes user. I think there may be some people who aren't confident enough, or don't have time, to build Ubuntu templates for themselves, so I build example Templates and make them available. I also host repos to serve deb packages for Ubuntu. I use a dedicated machine for building, a caching proxy to save downloads, and run through Tor. Is that secure and reliable? That said, I STRONGLY recommend that you build these templates for yourself. If you look at my posting history and contributions you may choose to trust me and by extension the packages I put up. That's your decision. For what it's worth, no one has reported anything untoward about any of the packages I've posted, or the live images. (Of course, if I were a malicious actor this is EXACTLY the approach I would take.) Hmm, security IS difficult, isn't it? unman -- 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
Re: [qubes-users] HCL Support File (.cpio.gz) / secure + private messaging?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-02-04 17:32, rob_66 wrote: > Hello. > > Whereto could I send my HCL Support File (.cpio.gz)? > > Would it still be helpful? (Qubes 4.0-rc4 on Asus »Zenbook« > UX303LNB) > > Best regards, R. > > If you'd like to send it to a Qubes developer in case it might be useful (I don't know whether it will be), you can send it to Marek in a PGP-encrypted email: https://www.qubes-os.org/team/#marek-marczykowski-g%C3%B3recki - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlp3qMoACgkQ203TvDlQ MDCVEg//bry13i5kzuRq5o4++3itkzJPBWVTZcsR2EqrTjjM5S4SJYFMYPBW4sn8 OwBVChNSykG7tdq9QZ8mqLZi9trtMy6VXyQDorCLvC3XiQX/lsQMpXXYl/fQ61n2 Lee59/4V+HmyyRgqgfvwfQ/MveoRs51cIXrvemsd7XIaLoptKN5dS0j9epqoE3JI yHZAO80iRZora7rw06+g5K3cvnYwVazUoMSR2wQ0F2aLX8pWwpLdHZYlfYGe/k3s zJwb+KDNy6nUvEROUAtrLnCXz9o0VXX9TIofEn5E41jGRLLvLgkdmgz69muxMHzw 5SxGPC+wV9dnYy2LPmjWmdhnDNnF93mpZ3WEfMhEcgqXKWc1rS1tSl6vWOQwwzw8 uHcwW2QCXNALQ2ZCmCQ2+ZrtM9MtM6PXQSpAz7o/wiv07e4bm67T5SCleR73HNPK ZwcLCmSbdQ8w5agxpTK8BteXL3Ysskfrj6QUiqDGkala/0YUjAP/rdru674Rq9t5 oyKuT1qKLK/KPcs4gAuNIvmS7fPhn9n1sgme689Ft4paRuPNR1nVCtnv8ZKwB1O4 1ZnsD28nQFxShMooJxctPph+t6Q2ts7ORHL1TDeyJDTTgZiXOahPGUHSxsMOmAWj d26j8033rjvLbkPk1HvLnKl1Pkgtc87fgibi3JdF2Q24DobX8rQ= =c02/ -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/4830df29-685c-9ee6-32be-6c0720a7fd0b%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] noscript xss warning on qubes os site
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-02-04 09:02, 'Vincent Adultman' via qubes-users wrote: > Confirm I get this too with noscript in firefox. Will try and get > some details together if I can and file an issue... > Thank you! That would be very helpful! We've been investigating this problem for a while, but we haven't been able to determine the cause. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlp3pqEACgkQ203TvDlQ MDDAvBAAu7qFXN+7Fue5BohqBXt5HUgcesm05DIslrMOG7I7eNJnJj55TUD7HYqL PCFShZP+zYG6xizugBikoW0tucWdJ+3zu7XXV5yI1d0ajmMcYwR9bBccayRtnetg zoM6A/5YZJ7JrpCrZPIRKN1ssrbeIUrkrm/6HH0466H0w5SsfXxQV4ZfjLjN5pvu xvLAR44Ifts/7Twg6Nfxo1irGfDpiEPcQ0gW/ktGyK5OTPpRh1POtrh4MK3bSoCM HPKHlxbjooO0kfB1Su/a4zkyYooOHxc5rJ3sgZ8Umqv+qvu/kpYvspGmAFphGJR3 wKcepQoj0XYJcmCSQL12IT4Wazam2ppOdN3epLWXgKdIVu5oPyWzU20bkbq+fCkM uh9tUjOuvaQiu8sY1a1o3Lv9YB7xqSryAtvMENrKD1Ogzca4xzYeatfGMCg/n5Cr m+2p3rG3k7TsLlcGxuj27fc4WNa1MrBC6pU3GzJ7E+GkJa/pY7AhGxJ3AjVoErcX kFoIwctbW7g1dgxg/NpjXdJy5igX3zxqLiUkDbN187XnzHQeNlnpbL7Qhd3A41Uh aVvB5LBPKuUV/pWmOfdFTgPam4EaCj3UO/lwYfz/hAKqI49Q4owHzTHPOGwetgYj BF7wcyT3wAu8yb/Oe9bZX2BpiJ3TyhvgXTuX8n7E+5arTiNgkEY= =CcIN -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/e17059b9-ca9c-326e-ad63-c6b6f8977053%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Monday, 5 February 2018 00:55:34 CET Unman wrote: > On Sun, Feb 04, 2018 at 08:14:57PM +0100, 'Tom Zander' via qubes-users wrote: > > * Having nothing but python APIs for your operating system is something > > that makes no sense. Python was never meant for servers, or even big > > applications. Finding a full-stack python developer is more rare than > > finding a Bitcoin C++ developer. > > I'm not sure how much of this is just trolling. It is not trolling. > You obviously dont mean uses like Google, DropBox, YouTube, Reddit etc. > Perhaps you dont know about Eve Online? Mercurial? Blender? Absolutely none of these use python for anywhere near the same percentage of components as Qubes does. Google is a good example, for instance they shipped proto-buffers. Which have bindings in a long list of languages (20 or so). Check wikipedia for those examples, reality is much more sobering that you think. > There are exceptional developers working in many companies -Google, > NASA, Astra Zeneca, to name a few, all using python. The fact that > you arent comfortable with it is fine, but not a reason to reject it. Thats moving the goalpost. Naturally there are many experienced python developers. Let me re-state the point for your benefit; Having nothing but python bindings and having practically all your components written in python is without a doubt very realistically limiting the amount of people you can get hacking on Qubes. Add on top of that the content matter, which is highly complex and in many cases includes networking or cross-VM communication or hard-core linux components and you limit the amount of people even more, to the extend I mentioned above. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/1610076.pebm5Wnf9q%40strawberry. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Sun, Feb 04, 2018 at 08:14:57PM +0100, 'Tom Zander' via qubes-users wrote: > * Having nothing but python APIs for your operating system is something that > makes no sense. Python was never meant for servers, or even big > applications. Finding a full-stack python developer is more rare than > finding a Bitcoin C++ developer. I'm not sure how much of this is just trolling. This is a joke though, no? You obviously dont mean uses like Google, DropBox, YouTube, Reddit etc. Perhaps you dont know about Eve Online? Mercurial? Blender? There are exceptional developers working in many companies -Google, NASA, Astra Zeneca, to name a few, all using python. The fact that you arent comfortable with it is fine, but not a reason to reject it. -- 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/20180204235534.qc4nu7mjyjgb2jg6%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Building Qubes 4rc4 iso from source
On Sunday, February 4, 2018 at 12:55:10 AM UTC-5, Tim W wrote: > On Sunday, February 4, 2018 at 12:25:46 AM UTC-5, awokd wrote: > > On Sun, February 4, 2018 4:48 am, Tim W wrote: > > > On Saturday, February 3, 2018 at 11:39:09 PM UTC-5, awokd wrote: > > > > > >> On Sun, February 4, 2018 4:21 am, Tim W wrote: > > >> > > >> > > >>> packages'. Error: Error downloading packages: Status code: 503 for > > >>> https://mirrors.fedoraproject.org/metalink?repo=fedora-25=x86_64 > > >>> > > >> > > >>> > > >>> An issue with the link in the makefile? > > >>> > > >> > > >> Probably a Fedora repo issue, maybe it's being updated. You might run > > >> into a bunch of those. All you can do is run "make qubes" again and > > >> cross your fingers. > > > > > > Well that royally sucks. Its not as if the build process is only 5-10 > > > mins. That was 30-45 mins to hit that error. > > > > > > looked at the makefile.fedora and it looks like this section. Does it > > > look correct I was wondering if something might change with depeciation > > > of f25 > > > > I know, it takes me around 6 hours for a fresh download and full build. > > Another thing you can try if you're frequently getting download issues > > (status code 503 is server issue, not missing file) is to build one group > > of components at a time instead of the full list (which "make qubes" > > does). > > If you want to try that instead, do "make help" and look for the list of > > components towards the end. It's like 10 lines long. Then start copying > > and pasting them into make, one batch at a time, like "make vmm-xen > > core-libvirt core-vchan-xen" for the first batch. That way if it fails you > > don't have to go so far back. Make sure to run them in order. > > great idea. I had done that on templates when working out issues back before > we all got archlinux building well. Did not think of if for this. So far > this time its still running on the build so hopefully in a few hours I will > have an iso. We will see. > > After that I think I will start adding in other templates to make a list of > what works. As I can leave it to do its thing will not be a big waste of > time. I am thinking minimal templates should also work. Then its onto > Centos. I prefer it leaps and bounds over Fedora. IMO its the ideal dom0 if > we need to stick to rpm based with its long LTS. Now with the longer linux > kernel support it will go great together for a long term stable system > without having to upgrade. OK I was able to get a standard build done to iso. That is standard FC26 + Strech-Debain + Whonix. I also successful built standard + minimal of those to iso as well. Next I will try adding in certain other templates 1 by 1. A correction on the instructions to build these 4.0 ISOs: You need significantly more private store drive space in the VM. I am using a stand-alone VM FC23 so I have more initial space taken up. Still with an app vm its 2x what the old docs recommend as a minimum. For just the standard build I needed 60gigbyes. For the standard + minimal 65 gig just barely made it. Best to have 70 gigs. My guess if you wanted to build all the non EOL templates for 4.0rc4 if they all can be built would be 100 gigs. I will continue to see what will build and the space needed. My guess is some laptops especially that are running ssd will not have the drive space to build depending on what's used up already for your system data. Looks like I finally have to add the 1tb Samsung Pro SED SSD in the optical bay for vm user data. Still not sure what program differences between the full-loaded-template vs Standard-templates. For me I would rather manually add the programs I wanted in each area. I may try the builds for those so we know if the build or not. I may also try the last template version to be EOL'd such as fc25 for fedora etc but that will be last. Too bad I do not have quad xeons 1000 +gigs of ram workstations vs the T440 with I7 + 16gig. I could get these built in 15-30 min rather than 3 hrs. In the attachment is the QM showing Build-Qubes VM Size used for at the end of #make iso with FC26-Standard+FC26-Minimal & Stretch-Standard + Stretch-Minimal + Whonix 64309MB Cheers, Tim -- 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/32e8fc28-50b9-403e-bead-570445798cef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL Support File (.cpio.gz) / secure + private messaging?
Hello. Whereto could I send my HCL Support File (.cpio.gz)? Would it still be helpful? (Qubes 4.0-rc4 on Asus »Zenbook« UX303LNB) Best regards, R. -- 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/p5854k%24ng6%242%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Asus »Zenbook« UX303LNB - Qubes 4.0-rc4
Just my first impressions from a quite fresh Qubes 4.0-rc4 install on Asus »Zenbook« UX303LNB. Needs further testing/playing around, of course, but basically it seems to run without severe problems. And that's all I need at this stage. Thank you VERY much, Qubes Team! Once again, the installation process is incredibly smooth and simple. (I chose all the proposed options, including Whonix.) I restored my AppVMs (no dom0, no templates) from latest Qubes 3.2 without big issues (so far). I call the AppVMs qubes now. ;) Best regards, Rob -- 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/p583tu%24ng6%241%40blaine.gmane.org. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-ASUSTeK_COMPUTER_INC_-UX303LNB-20180204-234606.yml Description: application/yaml
Re: [qubes-users] Qubes on Lenovo Thinkpad X250 Issues
Did you manage to troubleshoot? I would like to reinstall Qubes v4 on my X250, after having given up due to booting problems at v3.1, and the issue is not identical, but might be connected. Installation succeeds, but when booting just some lines mentioning xen are visible and then a black screen appears. No grub, just a black screen, and I can't find a way of interacting with the computer to debug. Maybe someone has had similar issues and knows how to solve them? Thank you. -- 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/05854135-1130-4fbb-b113-86f4e68d95a1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Issues with 4.0 rc4
On 02/04/2018 07:10 AM, Nuno Branco wrote: 2) When restoring VMs from Qubes 3.2 the software does not seem to work if you select more than one VM to restore at a time. By this I mean the restore process launches and finishes and I do have a VM listed on Qubes manager with the name of the VM I tried to restore however it reports "disk size 0 MiB" - when I power on the VM and check /home it is empty. If I restore the VMs one by one this does not happen and the VMs are restored normally - this is obviously annoying (e.g. while writing this email I had around 8 prompts for access) Just a note here as I've been trying to fix the many problems with restore -- it seems that backup was carefully constructed to work, but restore was more thrown together from a patchwork of old and new code. I just posted a fix for restoring dom0 specifically, which was still broken when RC4 was released. If you don't exclude the dom0 home then you'll almost certainly encounter errors; I expect the fix will get to qubes*testing sometime in the next week or two. Also, restore is currently best used in the CLI (its qvm-backup-restore) as the GUI still has issues of its own. I also decided to try a fresh RC4 install tonight and then restore an R3.2 archive (minus dom0 home) to see how that goes. Maybe I'll be able to recreate your issue... -- 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 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/f45bad15-c4a6-c847-4ffb-0dd8fe6df7bf%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
@Tom Zander On Sunday, February 4, 2018 at 8:15:05 PM UTC+1, Tom Zander wrote: > On Sunday, 4 February 2018 18:10:44 CET Yuraeitha wrote: > > Also it's been explicitly said that no Qubes 4 existing features will be > > added to the new-old Qube Manager. Which might also hint towards no > > changes coming to Qube Manager. If anything, it has to be re-made almost > > entirely to work well with Qubes 4+, and currently no one is doing that. > > The Qubes Manager is written to Qt4, which is equally outdated as the > backends of Qubes it used (3.x). > > I started a project using Qubes4-api and Qt5 APIs, though. See Ps at the > bottom of the mail. > > [start rant] > > The biggest issue i ran into is that Qubes4 is just too immature to actually > use for more than browsing and email. It was too painful for my desktop > full-time work machine. > I tried for 2 months, my significant other stated that I had been > extraordinary patient with Qubes when I finally stopped using it ;) > > My problems are widespread; > * the admin-api is very immature and poorly implemented. Getting a stack- > trace in the server logs and no answer is just unacceptable. Unit tests, > anyone? > * system-tray is hopelessly broken. Losing apps because they don't show in > the system-tray up when you close them was fun! > * The design of qubes-daemon is too fragile, it starts/stops VMs and > patiently waits and hopes everything will work. I expected a much more > 'hands-on' approach (at least for Linux kernels) with much more reporting. I > also lost data because apps aren't being quit, they are being killed on VM > shutdown. > * Why do I see 'lock'-icons for most of my windows in the task-bar? > * the documentation is very out-of-date. > * I don't know how, it may be fedora packaging, it may be qubes packaging or > configs, but the amount of KDE (apps running in dom0) crashes I had in the 2 > months of using Qubes is greater than the amount i had in the previous 5 > years. This boggles the mind... > * The graphics pipeline is hopelessly outdated. Its about a decade behind > the industry. > * Poor quality of many tools, the icon-copier copying the 22px icon from a > VM instead of the 256 one that was also there is just... sad. > * The amount of services, bash-scripts, config files, duplicated data in > qubes and then again in the system is horrible, under documented mess. > * rexecd validation being implemented using bash is a joke (mostly felt > because its extremely slow) > * total lack of mature end-user-focused tools. Swear to God. There are zero > today. > * Having nothing but python APIs for your operating system is something that > makes no sense. Python was never meant for servers, or even big > applications. Finding a full-stack python developer is more rare than > finding a Bitcoin C++ developer. > > end-rant. > > Qubes is an amazing idea, has some fantastic and genius concepts in it. > I hope many of those things will get fixed, although the list has grown so > long that I'm not sure it can without being forked. > > ps. https://github.com/QubesController is the place where I wrote an already > pretty decent "Qubes Controller" using the new APis. > I'm open to adding anyone to the approved committers list that wants to work > on it. > > -- > Tom Zander > Blog: https://zander.github.io > Vlog: https://vimeo.com/channels/tomscryptochannel I think discussion is good and healthy, though I don't feel it's entirely fair to paint it black and white like this. I can agree on many problems, but I think they look very different in different light and perspectives, so lets try shake it up a bit. I'm not claiming to be right, this is just my perspective of things. The ancient city Rom wasn't build in one day, it took many decades and even centuries. And as awokd said, the security in Qubes is rapidly evolving in short time, which is hard to deny. Qubes is heavily disrupting the security industry, which has been too stagnant and slowly reactive developing over many years, rather than a proactive forward looking perspective, which Qubes has. - The priority is first and foremost security, right? Everything else besides that is pretty much secondary or lower. Ease of use and emotional related things, such as good looking and appeal, will come even lower than secondary (don't get me wrong though, I do love good looking systems too my self). While the Qubes OS team could need more funding and donations, I don't think they are feeling ready yet to go and market themselves before the security is on an even higher level. And this I think is very justified in a logical sense seen from an understanding of market perspective, once you start market it, if the security isn't good enough, then Qubes will just become a short-lived fire-fly that only lives 24 hours, before everyone forgets about it again. For proper marketing, you need to be ready before spreading the hype. This is why many open
Re: [qubes-users] Clobbered FirewallVM — how can I get the firewall running again?
On Sun, February 4, 2018 4:55 pm, Demi Obenour wrote: > > > On 02/04/18 14:15, donoban wrote: > >> On 02/04/2018 08:05 PM, demioben...@gmail.com wrote: >> >>> My FirewallVM doesn’t seem to be running the Firewall service. How >>> can I set that up? >>> >> Could you paste "systemctl status qubes-firewall" on it? If it's unload >> or dead try start/restart it. >> > It is running normally: Are you running templates fresh out of the box? Try updating them. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e89fe2c1f3d734c526033da239f019c4.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Clobbered FirewallVM — how can I get the firewall running again?
On 02/04/2018 05:55 PM, Demi Obenour wrote: > On 02/04/18 14:15, donoban wrote: >> On 02/04/2018 08:05 PM, demioben...@gmail.com wrote: >>> My FirewallVM doesn’t seem to be running the Firewall service. How >>> can I set that up? >>> >> Could you paste "systemctl status qubes-firewall" on it? If it's unload >> or dead try start/restart it. >> > It is running normally: Why do you think that it is not running properly? -- 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/b7f68fd0-99ae-f219-b413-a010ff5414a8%40riseup.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Sun, February 4, 2018 7:14 pm, 'Tom Zander' via qubes-users wrote: > The biggest issue i ran into is that Qubes4 is just too immature to > actually use for more than browsing and email. It was too painful for my > desktop full-time work machine. I tried for 2 months, my significant other > stated that I had been extraordinary patient with Qubes when I finally > stopped using it ;) > > My problems are widespread; > * the documentation is very out-of-date. Working on it (where other contributors haven't already)! Am about halfway through now. > * The graphics pipeline is hopelessly > outdated. Its about a decade behind the industry. It's also been more secure than most of the industry for those 10 years. ;) But no point rehashing the related GSoC threads. Your suggestion there seemed valid. I hope you continue to run the released version of 4.0 on a secondary machine at least. I think you provide a valuable viewpoint. -- 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/cd459af052eaeba5682ae14f5376a99b.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Clobbered FirewallVM — how can I get the firewall running again?
On 02/04/18 14:15, donoban wrote: On 02/04/2018 08:05 PM, demioben...@gmail.com wrote: My FirewallVM doesn’t seem to be running the Firewall service. How can I set that up? Could you paste "systemctl status qubes-firewall" on it? If it's unload or dead try start/restart it. It is running normally: [user@sys-firewall ~]$ systemctl status qubes-firewall ● qubes-firewall.service - Qubes firewall updater Loaded: loaded (/usr/lib/systemd/system/qubes-firewall.service; enabled; vend Active: active (running) since Sun 2018-02-04 10:08:16 EST; 1h 45min ago Main PID: 508 (qubes-firewall) Tasks: 1 (limit: 4915) CGroup: /system.slice/qubes-firewall.service └─508 /usr/bin/python2 /usr/sbin/qubes-firewall -- 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/4e2be10d-137c-c698-bc9c-b7cd79b1f5a8%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Clobbered FirewallVM — how can I get the firewall running again?
On 02/04/2018 08:05 PM, demioben...@gmail.com wrote: > My FirewallVM doesn’t seem to be running the Firewall service. How can I set > that up? > Could you paste "systemctl status qubes-firewall" on it? If it's unload or dead try start/restart it. -- 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/dac8742b-7af7-e0af-7b37-00cf85482f3c%40riseup.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Sunday, 4 February 2018 18:10:44 CET Yuraeitha wrote: > Also it's been explicitly said that no Qubes 4 existing features will be > added to the new-old Qube Manager. Which might also hint towards no > changes coming to Qube Manager. If anything, it has to be re-made almost > entirely to work well with Qubes 4+, and currently no one is doing that. The Qubes Manager is written to Qt4, which is equally outdated as the backends of Qubes it used (3.x). I started a project using Qubes4-api and Qt5 APIs, though. See Ps at the bottom of the mail. [start rant] The biggest issue i ran into is that Qubes4 is just too immature to actually use for more than browsing and email. It was too painful for my desktop full-time work machine. I tried for 2 months, my significant other stated that I had been extraordinary patient with Qubes when I finally stopped using it ;) My problems are widespread; * the admin-api is very immature and poorly implemented. Getting a stack- trace in the server logs and no answer is just unacceptable. Unit tests, anyone? * system-tray is hopelessly broken. Losing apps because they don't show in the system-tray up when you close them was fun! * The design of qubes-daemon is too fragile, it starts/stops VMs and patiently waits and hopes everything will work. I expected a much more 'hands-on' approach (at least for Linux kernels) with much more reporting. I also lost data because apps aren't being quit, they are being killed on VM shutdown. * Why do I see 'lock'-icons for most of my windows in the task-bar? * the documentation is very out-of-date. * I don't know how, it may be fedora packaging, it may be qubes packaging or configs, but the amount of KDE (apps running in dom0) crashes I had in the 2 months of using Qubes is greater than the amount i had in the previous 5 years. This boggles the mind... * The graphics pipeline is hopelessly outdated. Its about a decade behind the industry. * Poor quality of many tools, the icon-copier copying the 22px icon from a VM instead of the 256 one that was also there is just... sad. * The amount of services, bash-scripts, config files, duplicated data in qubes and then again in the system is horrible, under documented mess. * rexecd validation being implemented using bash is a joke (mostly felt because its extremely slow) * total lack of mature end-user-focused tools. Swear to God. There are zero today. * Having nothing but python APIs for your operating system is something that makes no sense. Python was never meant for servers, or even big applications. Finding a full-stack python developer is more rare than finding a Bitcoin C++ developer. end-rant. Qubes is an amazing idea, has some fantastic and genius concepts in it. I hope many of those things will get fixed, although the list has grown so long that I'm not sure it can without being forked. ps. https://github.com/QubesController is the place where I wrote an already pretty decent "Qubes Controller" using the new APis. I'm open to adding anyone to the approved committers list that wants to work on it. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/9861258.aloPWp28RD%40cherry. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Clobbered FirewallVM — how can I get the firewall running again?
My FirewallVM doesn’t seem to be running the Firewall service. How can I set that up? -- 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/2f07821e-d3be-4556-bc41-5e0ab8d5e6fe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
I also just noticed that the feature seems to exist in the 4.0 GUI. Maybe I'll test that as well... I just tested it in 4.0 and that's affected by the bug as well... I managed to re-produce it 2/2 times with 2m and proxy and sys-net as netvm. What is interesting: qvm-firewall in dom0 lists a change (i.e. removes the "allow all" rule) after the timer runs out and even in the qubes-vm-settings GUI the checkbox is unchecked again, but the VM still has full Internet access... So whatever timer is there triggers, but the follow-up actions seem to be inappropriate. Btw in 4.0 "no access" seems to mean that DNS and ICMP is still allowed which seems somewhat weird, but at least it's mentioned in the GUI. So "no access" != "no network access" in 4.0. -- 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/7b495527-2b2e-4e20-5e24-a78daae3f924%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] Re: Qubes Manager / Qubes 4.0 R3 ?
On Saturday, February 3, 2018 at 11:10:05 AM UTC+1, ThierryIT wrote: > Le lundi 29 janvier 2018 09:00:23 UTC+2, ThierryIT a écrit : > > Hi, > > > > Not possible anymore to hide "un-running VMs" ? > > By the way, is it possible to create in Qubes Manager folders to be able to > > sort out VMs ? > > > > Thx > > nobody ? It's not possible no, and I doubt it will be before someone re-makes the Manager from almost the beginning (a lot of work). The Qubes Manager was only brought back because of people asking for it, but it was never intended or designed to work together with Qubes 4, and it did not receive the required re-make work to get a proper working manager, so the current old-new manager is buggy, slow, and newer Qubes 4+ features cannot be implemented as it is. The problem is Qubes 4 works very differently, and from what I read from earlier developer posts a year ago or so, it would take extensive work, effort and time to re-make the Qubes Manager for Qubes 4. In addition, the Qubes Manager was seen as being something akin to "bloat", it was not making Qubes feeling like you used any other normal computer system. The Qubes developers goal is not only maximum possible security, it's also user-ability and ease-of-use without making compromises to security. Removing the Qubes Manager was seen as a stepping stone towards that goal. While Qubes 4 isn't quite finished yet, and not ready to entirely let go of the Qubes Manager, the idea (I believe) was to get there as soon as possible. It was never intended to bring back the Qubes Manager, now known as the Qube Manager, notice the removal of the letter "s". The new-old Qube Manager's re-name, is probably to put emphasis on the fact that it's now only a VM-tool, and not a system-wide Qubes OS tool. Also it's been explicitly said that no Qubes 4 existing features will be added to the new-old Qube Manager. Which might also hint towards no changes coming to Qube Manager. If anything, it has to be re-made almost entirely to work well with Qubes 4+, and currently no one is doing that. Maybe we'll see it in Qubes 5, or later? Who knows, but I don't think we need a manager like this though, Qubes 4 works just fine without one, just like how the developers intended it to be. Sure the Qubes 4 approach could be polished a bit to make up not having a Qube Manager, but they managed to get pretty far already, it just needs a bit more to make the Qube Manager completely redundant. Until then, either use secondary tools, or use the old-new Qube-Manager. Try get used to the change instead. If you want to see memory/CPU use, then use other tools, like top, htop, xentop, etc. (the list is long). The most difficult thing about Qubes, is to get used to change. The same difficulty getting used to Qubes for the first time using it, goes too for changing from Qubes 3.2. to Qubes 4.0. The very way a user is meant and designed to interact with Qubes, has indeed changed in Qubes 4.0. -- 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/69ea2e13-a398-4943-9b07-8ec0a696d8f8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: templates update fail over sys-usb (but work using sys-net, on Qubes 4.x rc4)
On Saturday, February 3, 2018 at 11:21:45 PM UTC+1, Dave C wrote: > On Saturday, February 3, 2018 at 1:56:14 PM UTC-8, Yuraeitha wrote: > [ ... snip ... ] > > > It might be a good idea to put this on github, chances are that they might > > fix it soon if the problem is general issue for all USB tethering's, which > > could affect many people, thus possibly given higher priority in the > > limited resources available. They can also better keep track of the issue > > on github. Try report it on github if possible. > > I'll try to reproduce when time permits, and write this up better in a github > issue. > > > > > btw, just to be sure, are you using it in this order? > > sys-net --> sys-usb --> sys-firewall, and tying your Qubes-Global-Settings > > for NetVM updates to sys-usb? > > No, I'm switching between > > 1. sys-net --> sys-firewall --> appvms (the out of the box default) > 2. sys-usb --> sys-firewall --> appvms (sys-net disconnected) > > And the behavior I see is... > > setting #1, `dnf install ...` *succeeds* in appvms, *succeeds* in templates > setting #2, `dnf install ...` *succeeds* in appvms, *fails* in templates > > The way the templates fail has switched from the error in my first post, to > the error in my later post. ahh I see. I haven't done much alteration from the original sys-net --> sys-firewall my self, but in my experience the moment they are pulled apart without getting all the required sub-settings changed too, bad things tend to happen. If you haven't tried this approach down below yet, try see if it works. If not, a different approach is needed, though I can't see why the below should not work, adding sys-usb only complicate things a whole lot more than it needs to. Using the information you provided: "But again, if I configure sys-firewall to use sys-net, and use wifi instead of usb tether, `dnf install ...` succeeds." Try go back to the original sys-net --> sys-firewall --> appvm's scheme, the one you reported working too. like you did before, change back UpdateVM for updates in global settings to sys-firewall. Make sure to re-attach your Wireless device, or ethernet device, if they were removed in the device list on sys-net, but in addition to that, also add your USB controller alongside it. In this suggestion avoid sys-usb entirely, make sure it's not tied with the above approach in any way. If as you said that your updates work with Wireless or Ethernet, but not with the USB tethering (using the above layout), and USB works normally in sys-net otherwise, then you may have narrowed down the possible area the issue can exist. That is, if both Wireless/Ethernet/USB-for-other-things works in sys-net, but your USB internet tethering does not work, then it may much more specific related to the USB tethering drivers or USB tethering settings. If it works with this approach, then all good. But if it does not work, yet for example USB-storage devices or other USB devices can be seen and work in sys-net, then you may be closer to finding the actual reason why it won't work. Further, it's also that your USB controller is pci-reset sensitive, which means it cannot reset the cards memory on request, unless it's been shut down. You may want to either add the reset flag to your USB device, either via termianl or via the VM-settings UI, or alternatively, restart Qubes altogether. If you do that, then you can test whether pci-reset is part of the problem or not. For example, once you do the setup suggested in this post, and you added your USB controller to sys-net. Once there, try restart your Qubes OS before testing, to be sure pci reset is not causing trouble, and then try see if it works or not. (You're not using USB keyboard/mouse right? If you have no alternative input-type for keyboard/mouse, then moving the USB controller to another VM like done above might be dangerous if not taking precautions). -- 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/fc5f255a-f347-4f93-b43e-71784755a747%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Issues with 4.0 rc4
On Sun, February 4, 2018 4:00 pm, Yuraeitha wrote: > On Sunday, February 4, 2018 at 1:10:59 PM UTC+1, Nuno Branco wrote: > Reply to #3 In addition to what Yuraeitha wrote, check https://github.com/QubesOS/qubes-issues/issues/3470. > Reply to #4 qvm-prefs vmname kernel "" Then do your qvm-start --cdrom. -- 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/cdb1abd941656da756acec8e6bd7352e.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Issues with 4.0 rc4
On Sunday, February 4, 2018 at 1:10:59 PM UTC+1, Nuno Branco wrote: > So I decided to take a gamble and see if I could make the jump to 4.0. I > know it is still not the final version and want to thank everyone that > worked hard on this and also want to report on some annoying things and > other more concerning things: > > 1) When installing Qubes 4.0RC4 from ISO I clearly selected to not > install any of the whonix templates, yet Qubes installed them anyway. > > 2) When restoring VMs from Qubes 3.2 the software does not seem to work > if you select more than one VM to restore at a time. By this I mean the > restore process launches and finishes and I do have a VM listed on Qubes > manager with the name of the VM I tried to restore however it reports > "disk size 0 MiB" - when I power on the VM and check /home it is empty. > If I restore the VMs one by one this does not happen and the VMs are > restored normally - this is obviously annoying (e.g. while writing this > email I had around 8 prompts for access) > > 3) When using split GPG I am constantly getting a popup message for > granting access from the VM with the mail app to the VM with the gpg app > - this popup completely disregards the authorization I gave the first VM > to access the second VM for "X minutes" and makes using split gpg a shore. > > 4) I am unable to create a proper HVM. I used the new command with > "qvm-create name --class StadaloneVM --label gray" and it works however > when i try to boot with "qvm-start name --cdrom=vm:/path/to/debian.iso" > nothing happens. I used qvm-prefs to set virtual mode to HVM and when I > try to start it this way the VM briefly boots but crashes before it > reaches the CDROM facility. The ISO file itself is fine as I used it for > the same purposes to create a 3.2 HVM and it booted. > > 5) This is probably been reported before but whenever you try to stop a > VM from qubes manager it errors out (the VM still stops). > > 6) When restoring a vm named "abcd" for some reason now i have a vm > named "xpto" and another vm named "disp-abcd" on my qubes manager that I > can't delete - says it is already in use. "abcd" is the only VM where > this happened and its only special feature is that it was a proxy VM in 3.2 > > If any logs are required to provide more information please let me know > what you need and I will try to provide. > > -- > > Best regards, > Nuno Branco Most of these things you listed can indeed be frustrating, but can be worked around until they are fixed. Feel free to ask for elaboration if I went over something not properly explained. Below are my experiences from using Qubes 4 daily since early RC-2, in relation to your listed points. In other words I'm not an expert, but I have been using the Qubes 4 for a while now. Reply to #1) That's odd, it wasn't like t hat in the previous RC-X versions. I currently use RC-3 updated to RC-4 (no-reinstall required between these particular versions), and I did also not install Whonix/Debian-8 because I had to download newer versions anyhow, so it was redundant to install the older ones. So at least RC-3 did not install them. Perhaps this is a miss-step in the build of the RC-4? It may probably be corrected in possible final release, RC-5, or Qubes 4.1. later on, though it probably isn't on a high priority given the other issues to be fixed atm. Reply to #2) For now you may want to avoid using the GUI backup tools, it seems like it's not always perfect. Generally Qubes 4 has issues where either the terminal or the GUI works better, and usually one of the two is somewhat bug-free, while the other is buggy. Generally the terminal is the better choice, but not always. I imagine this will probably be fixed at some point soon once everything intended for Qubes 4 release works and the remaining issues are smoothing out issues like these. So my guess it will probably be updated later on. For backup and backup-restore recommend you use the dom0 terminal instead, from memory something like this qvm-backup-restore -d name-of-AppVM '/path-to-backup-inside-the-AppVM'. Rememeber you can use '' on the path, like above, so it stays coherent as a single unit from the rest of the command. You can use "man qvm-backup" or "man qvm-backup-restore" for manuals, or check the guides on the Qubes doc page for further information. ALso use "-x VM-name" to narrow down the VM's you do not want to restore, or alternatively instead just write the VM-name if you only want to restore a few VM's. For example "qvm-backup-restore -d name-of-AppVM '/path-to-backup-inside-the-AppVM' -x VM-Bob -x VM-Alice -x VM-and-so-on". Also the Qube Manager does not currently update live, you need to shut it down and up again to see a new read-out. It may be easier to just have a dom0 terminal with "qvm-ls" and then just "arrow-up + enter" every time you need a new read-out. Reply to #3 I'm not quite sure about what to suggest trying here. Maybe make
Re: [qubes-users] How to deal with Yubikey ?
On Sun, February 4, 2018 7:16 am, ThierryIT wrote: > > I have check it, but when doing a "dnf list installed "qubes-*" on my > sys-usb, I can see that qubes-usb-proxy is installed: > qubes-usb-proxy.noarch 1.0.12-1.fc26 @qubes-vm-r3.2-current Shouldn't > be: 4.0 current instead ? Yes, should be 4.0. Did you see the recommendation in https://www.qubes-os.org/doc/upgrade-to-r4.0/ to not restore your R3.2 templates to R4.0? Sounds like that might be what happened. Make sure all your AppVMs are using an R4.0 template. -- 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/e86aec81bd463767ec7ba46bf27ade66.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] noscript xss warning on qubes os site
Confirm I get this too with noscript in firefox. Will try and get some details together if I can and file an issue... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/wvYwPPFm2B2jzrZyAzoVWKOkOY5z4Zry7aeneQnDd7QI1TFFMT1Wv6K5o3o5b2TZ4lVH5G_pMJk_dctMlgzQZWzRAVy7D-aVnvMebexshpc%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
On 02/04/2018 03:20 PM, David Hobach wrote: > Honestly I don't really understand why systemd was used at all for that > functionality. > > Anyway I did test your suggestion and unfortunately it didn't reliably > work for me: > 1/3 times it worked and that seemed to be the random chance of it > working that you also mentioned in your first bullet point. In fact I > followed your steps for 2m, tested it again after daemon-reload & it the > connection went through, then attempted 2 times after a reboot (the > service edit was still there) for which it worked once. When I was testing it I used OnActiveSec=20 and OnUnitActiveSec=20 for speed up debugging. I had "journal -f -u qubes-relaod-firewall@VM-name.timer/service". I experimented that behavior, with OnActiveSec alone the service was triggered once. With OnUnitActiveSec it worked as expected and it seems reliable. Did you get a failure test after adding OnUnitActiveSec? Did you ping same host before expiration or tried different one? > My 3.2 test machine was pretty outdated though, i.e. maybe it also > depends on the systemd version running. > > Feel free to update the ticket though. In particular the observation > that there is a certain chance for it to work as expected is rather > interesting. > > Whether or not an ongoing connection such as a continuing ping should be > broken after timeout is a different topic btw - I guess there's some > RELATED, ESTABLISHED iptables rule that keeps it up. > > I also just noticed that the feature seems to exist in the 4.0 GUI. > Maybe I'll test that as well... It would be nice to found a fix for this but it should only break non-explicitly allowed connections? It seems pretty complex. > In total however using sth like > qvm-firewall [allow all] && sleep [time] ; qvm-firewall [remove allow all] > currently seems to be more reliable. > Totally agree, using systemd for this seems pretty overcomplex. Maybe using sleep could lead some problems with suspend/resume. Another option would be "while true if expiration then update else sleep X" Overall it's simply to fix in some of the possible ways. -- 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/0d713d27-d620-0fa0-ccab-b0c9ad4993dd%40riseup.net. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Qubes 3.2: Temporarily allowing full access does not revoke it after the time runs out
On 02/03/2018 01:31 PM, donoban wrote: On 02/03/2018 01:10 PM, David Hobach wrote: When you add temporary access for a AppVM, a service and a timer are created for that VM: - qubes-reload-firewall@(VM-Name).timer - qubes-reload-firewall@(VM-Name).service then the timer is enabled. 1min later the timer is fired and it enables the service, the service checks if the rule has expired and if yes it updates the iptables rules and stops the timer. The problem without "OnUnitActiveSec=1m" is that the timer is not fired anymore (at least on my computer), it goes to "elapsed" state, and the service is not enabled never again and the VM still with full access forever. Maybe is some problem with systemd. I am not sure about the desired effect of OnActiveSec alone. Honestly I don't really understand why systemd was used at all for that functionality. Anyway I did test your suggestion and unfortunately it didn't reliably work for me: 1/3 times it worked and that seemed to be the random chance of it working that you also mentioned in your first bullet point. In fact I followed your steps for 2m, tested it again after daemon-reload & it the connection went through, then attempted 2 times after a reboot (the service edit was still there) for which it worked once. My 3.2 test machine was pretty outdated though, i.e. maybe it also depends on the systemd version running. Feel free to update the ticket though. In particular the observation that there is a certain chance for it to work as expected is rather interesting. Whether or not an ongoing connection such as a continuing ping should be broken after timeout is a different topic btw - I guess there's some RELATED, ESTABLISHED iptables rule that keeps it up. I also just noticed that the feature seems to exist in the 4.0 GUI. Maybe I'll test that as well... In total however using sth like qvm-firewall [allow all] && sleep [time] ; qvm-firewall [remove allow all] currently seems to be more reliable. -- 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/57292981-35a3-07ea-3f22-33231140f54e%40hackingthe.net. For more options, visit https://groups.google.com/d/optout. smime.p7s Description: S/MIME Cryptographic Signature
[qubes-users] Issues with 4.0 rc4
So I decided to take a gamble and see if I could make the jump to 4.0. I know it is still not the final version and want to thank everyone that worked hard on this and also want to report on some annoying things and other more concerning things: 1) When installing Qubes 4.0RC4 from ISO I clearly selected to not install any of the whonix templates, yet Qubes installed them anyway. 2) When restoring VMs from Qubes 3.2 the software does not seem to work if you select more than one VM to restore at a time. By this I mean the restore process launches and finishes and I do have a VM listed on Qubes manager with the name of the VM I tried to restore however it reports "disk size 0 MiB" - when I power on the VM and check /home it is empty. If I restore the VMs one by one this does not happen and the VMs are restored normally - this is obviously annoying (e.g. while writing this email I had around 8 prompts for access) 3) When using split GPG I am constantly getting a popup message for granting access from the VM with the mail app to the VM with the gpg app - this popup completely disregards the authorization I gave the first VM to access the second VM for "X minutes" and makes using split gpg a shore. 4) I am unable to create a proper HVM. I used the new command with "qvm-create name --class StadaloneVM --label gray" and it works however when i try to boot with "qvm-start name --cdrom=vm:/path/to/debian.iso" nothing happens. I used qvm-prefs to set virtual mode to HVM and when I try to start it this way the VM briefly boots but crashes before it reaches the CDROM facility. The ISO file itself is fine as I used it for the same purposes to create a 3.2 HVM and it booted. 5) This is probably been reported before but whenever you try to stop a VM from qubes manager it errors out (the VM still stops). 6) When restoring a vm named "abcd" for some reason now i have a vm named "xpto" and another vm named "disp-abcd" on my qubes manager that I can't delete - says it is already in use. "abcd" is the only VM where this happened and its only special feature is that it was a proxy VM in 3.2 If any logs are required to provide more information please let me know what you need and I will try to provide. -- Best regards, Nuno Branco -- 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/1e9588c6-aa83-6844-2895-7be412aa9313%40mulligans.pw. For more options, visit https://groups.google.com/d/optout.
