[qubes-users] snap issues, related to the filesystem outside of ~/ ?

2021-06-10 Thread Stumpy
 

I tried installing snaps in a debian template and then 

but while it ran fine the first time, after restarting it stopped
working. As I wanted to be sure it was not a qubes issue I posted on the
snapcraft forum [1] and the question they asked that made me think it
was qubes related was

 _"Is this being run inside a container? It seems to imply that either
/dev or /tmp/snap.rootfs_IeI049/ do not exist, but previously in the log
the tmp dir was created by snap-confine"_

So, AFAIK i installed it according to the qubes instructions [2] but am
getting various errors that are starting to point to the ephemeral
nature of appvms (only the home dir is retained).

Anyone know how to fix this?
 

Links:
--
[1]
https://forum.snapcraft.io/t/authy-snap-error-cannot-perform-operation-mount-rbind/24932
[2]
https://www.qubes-os.org/doc/software-update-domu/#installing-snap-packages

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


[qubes-users] Re: QubesOS weekly builds

2021-06-10 Thread Frédéric Pierret

Hi,

Le 3/21/21 à 11:33 PM, Frédéric Pierret a écrit :

Hi,
As some of you may know, months(years?) ago, I've setup a pipeline that is 
automatically PR latest kernels for Qubes OS and more recently, pulseaudio 
headers too. This is done every week.

At some point, I added the build of ISO including kernel-latest for users who 
were having issues with latest hardware. I stopped it quickly because we were 
merging more and more kernel versions thank to the help of automatic PR and 
Qubes point releases.

Due to recent troubles with kernels 5.4.X and 5.10.X, I've decided to add again 
to this weekly pipeline, the build of a fresh Qubes R4.1 ISO. I don't build any 
package or any template. It uses only Qubes OS repositories. The qubes-builder 
conf is: 
https://github.com/QubesOS/qubes-release-configs/blob/master/R4.1/qubes-os-iso-full-online.conf
 and the kickstart can be found here: 
https://github.com/QubesOS/qubes-installer-qubes-os/blob/master/conf/iso-full-online.ks.

Please note that, contrary to my first attempt, I don't include kernel-latest kernels. 
It's a standard R4.1 ISO as if Marek would release one. It is built in a dedicated AppVM 
together with Split GPG. The ISOs are signed by "fepitre-bot" 
1C8714D640F30457EC953050656946BA873DDEC1. Some of you already download latest R4.1 devel 
ISOs in openQA but they are not signed and not necessary built in a safe environment 
because it's only for CI purposes. That's a solution between CI ISOs and R4.1 alpha 
release.

That said, the ISO(s) can be found on my self hosted server: 
https://qubes.notset.fr/iso/.

Best regards,
Frédéric



I've added support to qubes-builder the possibility to build an ISO having the 
installer running kernel-latest and the installed QubesOS too. For 
documentation: 
https://github.com/QubesOS/qubes-builder/blob/master/doc/Configuration.md#iso_use_kernel_latest
 (pretty simple, isn't it?)

I'm pleased to announce you that I've added that to my weekly build pipeline where I will 
still build both versions: the standard and the one with kernel-latest embedded. Same as 
previously, you can find signed ISOs here https://qubes.notset.fr/iso/ and also result of 
openQA tests too (see openqa.qubes-os.org with build tag having -kernel-latest. For 
example: 
https://openqa.qubes-os.org/tests/overview?build=20210610-kernel-latest-4.1=qubesos=4.1=1).

The goal is still the same: providing testing QubesOS images built in a sane 
environment for latest drivers support by Linux until LTS kernels would have 
enough backports for very recent hardware.

A final remark like on the Discourse thread, I do recurrent cleaning for space 
consideration. I keep only ISOs for the current month now.

Best regards,
Frédéric

--
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/5068b322-bda1-f92b-cbed-023a9f925692%40qubes-os.org.


OpenPGP_signature
Description: OpenPGP digital signature


[qubes-users] Re: [HCL] ThinkPad T430

2021-06-10 Thread Plexus
Awesome work Sven and thank you for being the "one hard t430" guide 
collaborator and alpha tester. I have so many permutations of T430 in my 
home right now its hard to keep track of them all. 

I will get the guide finished soon and change the repo to public so the 
community can benefit.,

Cheers,
Plexus.

-- 
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/ab56334f-e6f5-4fde-b247-a176cc941f35n%40googlegroups.com.


Re: [qubes-users] Re: [HCL] ThinkPad T430

2021-06-10 Thread Sven Semmler

On 6/10/21 2:06 PM, BGW wrote:

I see that on the Nitrokey site that they say the i7 73740 is NOT
QUBES compatible?  Did I get that right?


There are three chips we should talk about to clarify this:

i7-3632QM (listed by Nitrokey, not compatible with Qubes OS)
i7-3740QM (the one I used, NOT listed by Nitrokey)
i7-3840QM (listed by Nitrokey)

The i7-3632QM is that fastest 4 core 35 watt chip Intel makes and the 
socket 2 version of it, which you would need for the T430 does not have 
Vt-d. Although there is a i7-3632QM version that has it, but that one 
can't be used with the T430.


I originally ordered a i7-3632QM because I wanted to stay within the 35 
watt design of the T430 and then found out that it lacks Vt-d when I 
tried to install Qubes OS. I asked Nitrokey about it and they continued 
to tell me that their i7-3632QM would have Vt-d. Then @Plexus made a 
post on the Qubes OS Forum regarding this and alerted the Qubes OS Team 
and that's when Nitrokey added the warning you saw.


You can however also use 45 watt chips with the T430 if you mod the 
cooling (like I've done). In that case the fastest chip is the i7-3840QM 
as offered by Nitrokey.


The one I've used is the i7-3740QM which was recommended by @Plexus. 
It's a tiny bit less powerful than the i7-3840QM but about half the 
price (if you shop right and not just go for the first listing on Amazon 
as I did).


Bottom-line: the i7-3740QM has Vt-d and works perfectly with Qubes OS!

/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/48145d31-7ec5-62eb-d27e-c564855da1f4%40SvenSemmler.org.


OpenPGP_signature
Description: OpenPGP digital signature


[qubes-users] Re: [HCL] ThinkPad T430

2021-06-10 Thread BGW
I see that on the Nitrokey site that they say the i7 73740 is NOT QUBES 
compatible?  Did I get that right?

On Thursday, June 10, 2021 at 6:55:02 AM UTC+10 Ulrich Windl wrote:

> On 6/4/21 1:28 AM, Sven Semmler wrote:
> > A dream has come true!
> > 
> > * ThinkPad T430
> > * Coreboot/Heads with TOTP & HOTP (Nitrokey)
> > * ME cleaned & disabled
> > * Qubes OS R4.0.4 all debian-minimal, memory optimized
> > 
> > Upgrades:
> > 
> > * i7-3740QM
> > * 16 GB RAM
> > * 2 TB SSD
> > * Intel Wireless 7260
> > * 1080p display
>
> Hmm...: How many $$$ (€)?
>
> > 
> > I'll be using this machine for a long long time. :-)
> > 
> > /Sven
> > 
>

-- 
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/6f816e84-cd35-468b-9eb4-8fb4fead37b5n%40googlegroups.com.


Re: [qubes-users] Re: [HCL] ThinkPad T430

2021-06-10 Thread Sven Semmler
I forgot to mention the Nitrokey. But a Libremkey or Yubikey will do the 
same job. Whatever you already have or suits your wallet / location etc.


/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/2952f586-f99d-57db-546f-8faf38cbf490%40SvenSemmler.org.


OpenPGP_signature
Description: OpenPGP digital signature


[qubes-users] Re: Bitcoin Core RPC qvm-connect-tcp not working?

2021-06-10 Thread 'keyandthegate' via qubes-users
Wait, apparently I can't even "netcat -l 5000" and "telnet localhost 5000" in 
the same debian vm? Even if I clear the iptables and set the default policies 
to accept? Clearly I don't understand Qubes networking.

‐‐‐ Original Message ‐‐‐
On Thursday, June 10th, 2021 at 12:56 AM, keyandthegate 
 wrote:

> I tried in a fresh vm:
> user@my-new-qube:~$ qvm-connect-tcp 8332:bitcoind:8332
> Binding TCP 'bitcoind:8332' to 'localhost:8332'...
> user@my-new-qube:~$ telnet localhost 8332
> Trying ::1...
> Trying 127.0.0.1...
> Connected to localhost.
> Escape character is '^]'.
> Request refused
> 2021/06/09 17:50:53 socat[992] E waitpid(): child 993 exited with status 126
> Connection closed by foreign host.
>
> How would bitcoin core even know that I'm connecting from a different VM, if 
> it should also be as if from localhost?
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, June 10th, 2021 at 12:09 AM, keyandthegate 
>  wrote:
>
>> Hi, I'm following the instructions here: 
>> https://github.com/qubenix/qubes-whonix-bitcoin/blob/master/1_joinmarket.md
>>
>> After I run "qvm-connect-tcp 8332:bitcoind:8332" in the joinmarket vm
>>
>> "telnet localhost 8332" works from bitcoind vm, but does not work from the 
>> joinmarket vm, where it says "Connection closed by foreign host."
>>
>> I tried adding this to my bitcoin config:
>> rpcbind=127.0.0.1
>> rpcallowip=0.0.0.0/0
>> rpcbind=bitcoind
>> and then running "sudo systemctl restart bitcoind"
>> after reading:
>> https://bitcoin.stackexchange.com/questions/87943/unable-to-bind-any-endpoint-for-rpc-server
>> but it didn't help
>>
>> Is there anywhere I can find a working example of using qvm-connect-tcp to 
>> connect to bitcoin core RPC server from another vm?

-- 
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/ywwVKW8pR0A7nMqNanVjLtLPGz7TI_uJTuVoeFjfSOCO-hDt0Yz02H7dkKdTKa_MF4q5CtZH7g7cnluSk4UsD5YnYqo2ku2YCjgxm-P8B7U%3D%40protonmail.com.