Just to clarify, the original abort/glitch happened after all updates were
successfully *downloaded*, but during the upgrade/install process itself.
At present when I try to do:
sudo dnf check-update
I get:
Failed to synchronize cache for repo 'qubes-dom0-cached', disabling.
I have already
Qubes 3.2
Last night I was updating dom0, but in the middle of the update I accidentally
hit some keys on the keyboard, which I now in hindsight realize must have
included Ctrl-Z.
At that point the update just stopped and froze at item 13/42 which just so
happened to be qubes kernel
Not just an Apple problem, as Lenovo was also mentioned in the article.
Any Intel box could theoretically come this way.
One way to look deep inside ME?
Intel ME Manufacturing Mode: obscured dangers and their relationship to
Apple MacBook vulnerability CVE-2018-4251
On 9/29/18 4:12 PM, 'Setherson' via qubes-users wrote:
> I am using Qubes 3.2. All TemplateVMs and dom0 have been updated sometime
> within the past week.
>
> Since about the same time, my Workstation TemplateVM and every AppVM based on
> it has been unable to connect to the internet.
>
> The
New Qubes user! First install today.
"Qubes-R4.0-x86_64.iso" (DD image) is installed.
Downloaded today (2nd October 2018)
During the install during options for TemplateVMs, Sys-usb, etc. following
error appeared:
--
[Dom 0] Error
On 10/1/18 10:23 AM, Setherson wrote:
>> I should have said in my previous email that I got the same error you just
>> pasted. What I did was comment out the onion server in
>> /etc/apt/sources.list.d/whonix.list as well.
>>
>> That fixed the problem for me.
>>
>> --
>> You received this message
On 9/26/18 9:48 AM, paigemarie-sgozh3hwpm2stnjn9+b...@public.gmane.org
wrote:
>
>
>> All u2f-related packages area already in stable repository (since
>> yesterday), so the above is not needed anymore.
>
> When I run `sudo apt install qubes-u2f` in my Debian template or `sudo dnf
> install
Em terça-feira, 2 de outubro de 2018 09:17:43 UTC-3, Sergio Matta escreveu:
> Em segunda-feira, 1 de outubro de 2018 19:55:24 UTC-3, Sergio Matta escreveu:
> > Em segunda-feira, 1 de outubro de 2018 16:04:34 UTC-3, naas...@gmail.com
> > escreveu:
> > > Installation went fine except for a
Em segunda-feira, 1 de outubro de 2018 19:55:24 UTC-3, Sergio Matta escreveu:
> Em segunda-feira, 1 de outubro de 2018 16:04:34 UTC-3, naas...@gmail.com
> escreveu:
> > Installation went fine except for a libxenlight config error of some kind.
> > I still can't enable IOMMU using either of the
On 10/02/2018 04:53 AM, ben.thomp...@vfemail.net wrote:
> Hi,
> some time ago i discovered qubes, but my laptop did not support it and i
> did not follow the developments.
> Now my old laptop is broken and i am about to buy a new one.
This question has been asked and then answered like 20+ times
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 10/1/18 11:48 PM, mfreemon wrote:
> What is the best practice recommendation on this (for R4, Fedora
> 28 template)? Are we to be using, exclusively, nftables in R4?
The intended benefit was that in case of nftables qubes firewall not
needed to
I wonder if I could encrypt my (only) disc is a "headerless" more and
store the header on a separate sdcard. Once any linux-type system is
completely is booted this is easy. But can the qubes bootloader do that?
(this needs to find and mount the sdcard first, then fetch the header
there ).
Hi,
some time ago i discovered qubes, but my laptop did not support it and
i did not follow the developments.
Now my old laptop is broken and i am about to buy a new one.
I have a few questions:
How well does passing a dedicated graphics card to a vm work / is
gaming in a vm feasible or do
On 10/2/18 1:32 AM, Chris Laprise wrote:
> On 10/01/2018 05:48 PM, mfreemon wrote:
>> On 1/11/18 3:01 PM, Chris Laprise wrote:
>> > On 01/10/2018 03:47 PM, Connor Page wrote:
>> >> The official templates use nftables so shouldn’t be mixed with
>> iptables. I didn’t have time to learn about
14 matches
Mail list logo
