Re: [qubes-users] HCL - Asus All Series
Hi Stat Pow, any chance you could tell us the actual model used? Asus motherboards are always reported as "All series" in the automatically generated report, but I am trying to clean up and make the HCL more useful. So if you can, please share the exact model so I can fix it. /Sven -- public key: https://www.svensemmler.org/2A632C537D744BC7.asc fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5a7c000e-05ae-468f-d22d-e43956463409%40SvenSemmler.org. OpenPGP_signature Description: OpenPGP digital signature
Re: [qubes-users] Re: [HCL] ThinkPad T430
On 9/11/21 08:23, Will Lewis wrote: I'm using a 1TB 870 Pro A few days ago I replaced the 870 QVO with a 860 PRO ... what a difference!!! Learned that lesson for sure. -- public key: https://www.svensemmler.org/2A632C537D744BC7.asc fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7 -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/dc4c37a2-ea65-393c-dc61-8924c65ca70d%40SvenSemmler.org. OpenPGP_signature Description: OpenPGP digital signature
[qubes-users] New article: "Reproducible builds for Debian: a big step forward" by Frédéric Pierret
Dear Qubes Community, A new article has just been published on the Qubes website: "Reproducible builds for Debian: a big step forward" by Frédéric Pierret https://www.qubes-os.org/news/2021/10/08/reproducible-builds-for-debian-a-big-step-forward/ For your convenience, the original Markdown text is reproduced below. --- layout: post title: "Reproducible builds for Debian: a big step forward" categories: articles author: Frédéric Pierret --- _This is the second article in the "reproducible builds" series. Previously: [Improvements in testing and building: GitLab CI and reproducible builds](https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/)._ In the previous article, [Improvements in testing and building: GitLab CI and reproducible builds](https://www.qubes-os.org/news/2021/02/28/improvements-in-testing-and-building/#reproducible-builds), we discussed reproducible builds and our current short-term goals for them in Qubes OS. Notably, we aimed to start by building our Debian templates such that packages can be installed only when configured rebuilders confirm that they really came from the source code we publish. Today, we go beyond this expectation. Reproducible builds: retrieve the past -- The challenge in reproducible builds lies in rebuilding a package in the same environment in which it was officially published. This means that we need to retrieve every single package version that was used as dependency to rebuild a given package. For Debian, some packages in the current release were built several releases in the past but not necessarily with the exact same dependencies. In order to retrieve them, there is only one solution: a Debian service called `snapshot.debian.org`, which is an archive acting as a [Wayback Machine](https://web.archive.org/) that allows access to old packages based on dates and version numbers. It contains all past and present packages that the Debian archive provides. Unfortunately, this service is known to suffer significant blocking issues on usability. For example, watch the DebConf 2021 talk [Making use of snapshot.debian.org for fun and profit](https://debconf21.debconf.org/talks/22-making-use-of-snapshotdebianorg-for-fun-and-profit/) and have a look at some related Debian issues like [#977653](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%977653), [#960304](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%960304), [#969906](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969906), [#969603](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%969603), and [#782857](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%782857). To summarize: There are throttling limits and availability issues such as repeatedly cutting off connections, returning partial content, etc. As announced in our previous article, we developed our own rebuilder tool, [debrebuild](https://github.com/fepitre/debrebuild), which is able to rebuild a single Debian package together with a rebuilder orchestrator [PackageRebuilder](https://github.com/fepitre/package-rebuilder). We started to put it in production in order to actively rebuild Qubes OS and Debian packages, but it quickly ceased to function, as the `snapshot.debian.org` service was unable to sustain the load of rebuilding even a single Debian package. That said, the question was: How should we proceed in order to make it work? Clearly, those issues are critical and make the `snapshot.debian.org` service awful or useless for reproducible builds. Is rebuilding Debian really possible? - The `snapshot.debian.org` issues have still not been addressed even after several years. The service has existed for more than a decade, yet it still suffers from the aforementioned limitations. It's either a design problem or a lack of resources, but we still had to do something. That's why we decided to create our own [snapshot](https://github.com/fepitre/debian-snapshot) service. Easy to say, but not to do. First, the original snapshot service from Debian is roughly 90 TB of repository data. Second, we cannot download files easily because only HTTP(S) is available, and downloading multiple files means we are impeded by availability issues. In order to work around the huge volume of data, we decided to get repositories from 2017 to today (which corresponds approximately to when Debian "Buster" was released) and only related architectures `amd64`, `source`, and `all`. (`all` indicates no specific architecture in the Debian world.) For the download part itself, we needed to parse the metadata of each Debian repository in order to get the list of files to download for every timestamp for which a snapshot had been made. Then, we developed `resume` and `retry` download functions, which unfortunately are brute force download
[qubes-users] Whonix upgrade fails after interruption
I started uprading Whonix using the salt command, but the process was interrupted. On retrying, it fails, unable to create the whonix WS VM due to "permission denied". From journalctl: Oct 08 11:24:35 dom0 qubesd[2098]: permission denied for call b'admin.vm.Create.AppVM'+b'whonix-ws-16' (b'dom0' → b'dom0') with payload of 31 bytes (see below for the salt output) When I run the qvm-create command from the salt output manually, it also fails, because the whonix-ws-16 template doesn't exist: $ qvm-create --verbose whonix-ws-16-dvm --class=AppVM --template=whonix-ws-16 --label=red 2021-10-08 11:33:54,499 [MainProcess qvm_create.main:177] app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details. I assume all this is related to the failed previous attempt. How do I reset the state so that I can successfully do the upgrade? [user@dom0 ~]$ sudo qubesctl state.sls qvm.anon-whonix [WARNING ] /var/cache/salt/minion/extmods/states/ext_state_qvm.py:146: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 status = Status(retcode=1, result=False, stderr=err.message + '\n') [ERROR ] == ['features'] == Virtual Machine does not exist! == ['tags'] == [SKIP] Skipping due to previous failure! [ERROR ] == ['present'] == == stderr == /usr/bin/qvm-create whonix-ws-16-dvm --class=AppVM --template=whonix-ws-16 --label=red app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details. == ['prefs'] == Virtual Machine does not exist! == ['features'] == [SKIP] Skipping due to previous failure! == ['tags'] == [SKIP] Skipping due to previous failure! local: -- ID: template-whonix-ws-16 Function: pkg.installed Name: qubes-template-whonix-ws-16 Result: True Comment: Package qubes-template-whonix-ws-16 is already installed Started: 11:24:14.138294 Duration: 5796.629 ms Changes: -- ID: whonix-ws-tag Function: qvm.vm Name: whonix-ws-16 Result: False Comment: == ['features'] == Virtual Machine does not exist! == ['tags'] == [SKIP] Skipping due to previous failure! Started: 11:24:19.979281 Duration: 271.503 ms Changes: -- ID: whonix-ws-update-policy Function: file.prepend Name: /etc/qubes-rpc/policy/qubes.UpdatesProxy Result: True Comment: File /etc/qubes-rpc/policy/qubes.UpdatesProxy is in correct state Started: 11:24:20.261980 Duration: 14.769 ms Changes: -- ID: whonix-get-date-policy Function: file.prepend Name: /etc/qubes-rpc/policy/qubes.GetDate Result: True Comment: File /etc/qubes-rpc/policy/qubes.GetDate is in correct state Started: 11:24:20.277092 Duration: 12.533 ms Changes: -- ID: template-whonix-gw-16 Function: pkg.installed Name: qubes-template-whonix-gw-16 Result: True Comment: Package qubes-template-whonix-gw-16 is already installed Started: 11:24:20.289981 Duration: 1.316 ms Changes: -- ID: whonix-gw-tag Function: qvm.vm Name: whonix-gw-16 Result: True Comment: == ['features'] == [SKIP] Feature already in desired state: ENABLE 'whonix-gw' = Enabled == ['tags'] == [SKIP] All requested tags already set: created-by-dom0,whonix-updatevm Started: 11:24:20.291708 Duration: 4714.395 ms Changes: -- ID: whonix-gw-update-policy Function: file.prepend Name: /etc/qubes-rpc/policy/qubes.UpdatesProxy Result: True Comment: File /etc/qubes-rpc/policy/qubes.UpdatesProxy is in correct state Started: 11:24:25.006518 Duration: 7.468 ms Changes: -- ID: sys-net Function: qvm.exists Result: True Comment: /usr/bin/qvm-check sys-net None Started: 11:24:25.014322 Duration: 2048.565 ms Changes: -- ID: sys-firewall Function: qvm.exists Result: True Comment: /usr/bin/qvm-check sys-firewall None Started: 11:24:27.065077 Duration: 1868.662 ms Changes: -- ID: sys-whonix Function: qvm.exists Result: True Comment: /usr/bin/qvm-check sys-whonix None Started: 11:24:28.935733 Duration: 1744.59 ms Changes: -- ID: whonix-ws-16-dvm Function: qvm.vm Result: False Comment: == ['present'] == == stderr == /usr/bin/qvm-create whonix-ws-16-dvm --class=AppVM --template=whonix-ws-16 --label=red app: Error creating VM: Got empty response from qubesd. See journalctl in dom0 for details. == ['prefs'] == Virtual Machine does not exist!
Re: [qubes-users] Re: usb keyboard not working on debian 11 template
On Wed, Oct 06, 2021 at 10:48:14PM +0200, 'qtpie' via qubes-users wrote: > Installing qubes-input-proxy-sender in the template it was. Problem solved. > Thanks awokd! > > Note: to avoid this problem, these should either be default installed > packages in all templates, or be documented in > https://www.qubes-os.org/doc/usb-qubes/. If the latter is preferred, I can > adapt the documentation. Please let me know. > qubes-input-proxy-sender is installed by default in the debian-11 template. If you are using a minimal template, this is meant for advanced users, but in any case, installation of qubes-input-proxy-sender is documented at https://www.qubes-os.org/doc/templates/minimal/ -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/YWArvIPQtqpjNn4I%40thirdeyesecurity.org.
