Re: [qubes-users] Anyone gotten bitcoind to install via snapcraft on an AppVM?
tetrahedra via qubes-users: > On Thu, Feb 27, 2020 at 03:18:30PM +, tetrahedra via qubes-users wrote: >> Current best solution for running bitcoind on an AppVM: >> Download the binaries, run bitcoind as `user` > > For future reference, the current Bitcoin-on-Qubes howtos appear to be > here: > https://github.com/qubenix/qubes-whonix-bitcoin > > Comments for qubenix: > - Some systems have limited disk space (e.g SSDs) so it may make sense > to run a pruned node That's true, but using a pruned bitcoind will limit its usefulness as a backend for other software (eg. electrum servers, block explorers). You may be able to use it for a specific purpose (eg. joinmarket), but the point of my guides is that you can keep adding new software that comes out (eg. btcpayserver, lnd, c-lightning, esplora) and connect it to your bitcoind VM without having to reindex the chain. > - it would be really nice to use bind-dirs to avoid creating a second > Whonix WS templateVM (which takes up lots of disk space) -- > unfortunately I haven't figured out how to create a new user and keep > that user persistent (see prior email) > This is a good point. Unfortunately I don't have a lot of extra time/motivation currently to make sweeping changes like that. That's why my btcpayserver branch hasn't been worked on since November. It's nice to know that someone somewhere is paying attention to work I've done with these. Thank you for that. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/bd9bea7e-5c84-b293-5db6-d158c2033d77%40riseup.net.
Re: [qubes-users] wasabi in qubes
'awokd' via qubes-users: > ehag...@gmail.com: >> I wouild like to use wasbi in a whonix VM. >> >> Can any one tell me how to make it work step by step_ There's some discussion here: https://forums.whonix.org/t/wasabi-wallet-in-whonix/7597. Basically just download it, verify signature, run it, and change config settings to use your gateway's ip for your tor host. > > Assuming Wasabi is a cloud provider and assuming it has some Linux Wasabi is a Bitcoin wallet that facilitates CoinJoins for users: https://www.wasabiwallet.io/. It's a centralized, easy to use solution for people that want to protect against some blockchain analysis. > client (would be good if you provided more detail so people don't have > to guess), the direct answer to your question as stated would be to > install their client software into the whonix-ws-14 template. However, > unless you've audited their software this could be a bad idea from an > anonymity perspective as it may link your identity across all Whonix > client sessions. > > Safer option would be to clone whonix-ws-14 to a new template just for > Wasabi use, install their software in it, then create an AppVM based on > it networked to sys-whonix. > Don't need to install in a template. Just run a release in an AppVM. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/170dd2d4-9569-6aba-ec04-08688f68f60f%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Announcement: Qubes Tor onion services will no longer be maintained
Andrew David Wong: > Dear Qubes Community, > > We regret to announce that the Qubes Tor onion services will no longer > be maintained due to lack of resources. This includes all Qubes onion > services, including the Qubes website onion mirror and the onion package > repos. > > We would like to thank the Whonix Project for generously maintaining > these services for over a year. [1] Maintaining the Tor onion services > requires labor, servers, and bandwidth. Unfortunately, none of these > resources are available to the Qubes OS or Whonix projects in sufficient > quantities to allow us to continue offering these services. > > We recommend that users who currently rely on any Qubes onion addresses > transition to the corresponding clearnet addresses immediately. > > > [1] > https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/ > > This announcement is also available on the Qubes website: > https://www.qubes-os.org/news/2019/03/24/tor-onion-services-no-longer-maintained/ > > Wow, very sad. May I ask why so many extra resources are needed? Can't you just install tor on the system that hosts your clearnet repos? -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/6400d67e-63f0-339a-b19d-6bf111c86bf2%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
OGBaby:
> Hey Qubenix, I have an update for you and anyone curious. The MDB_BAD_TXN
> error has been resolved. For anyone wondering this error most likely mean
> your blockchain was interrupted during sync and is now corrupt.
>
> The solution advised by Monero channels is to delete the blockchain data
> ("lmdb") amd resync.
>
> I was recommended to include the flag '--db-sync-mode=safe' to monerod upon
> startup to protect against unexpected interruptions or reboots during sync.
>
> You should be able to locate the blockchain within /home/user/.bitmonero/
>
> Keep in mind .bitmonero is a hidden directory.
>
> After the resync everything regarding the daemon seem to be in place and
> running. I will repost the most recent logs and provide fresh ones as well.
>
> I am being redirected back here since that particular monerod error appear to
> be resolved, there may be a minor issue with the separation setup of wallet
> and daemon VMs. The lower-left Network Status is 'disconnected' and of course
> "Wallet is not connected to daemon" is still visible above.
>
> If there is anything specific I should verify and confirm, I would gladly
> take a look.
>
> Thanks everyone
>
> Monerod status (previous)
> https://pastebin.com/v95gn1aB
>
> Monerod Bitmonero.log (previous)
> https://pastebin.com/3mzhuSHt
>
> Monerod Status (fresh)
> https://pastebin.com/XwAy91dh
>
> Monerod Bitmonero.log (fresh)
> https://pastebin.com/CHSHg9Zz
>
>
> Hopefully it's just something I'm overlooking.
>
Your daemon issues seem solved, so that's a step in the right direction.
Can you come on irc to resolve this (either freenode or oftc)? I suspect
we're going to be doing a lot of back and forth to find out which step
in the guide wasn't completed correctly.
If you want to, you can go back through the guide first and pay special
attention that you have done the following correctly:
1. Set up qrexec policy (/etc/qubes-rpc/policy/whonix.monerod-mainnet)
in dom0. Guide section 1.4.
2. Set up qrexec file
(/rw/usrlocal/etc/qubes-rpc/whonix.monerod-mainnet) on the daemon vm.
Guide section 3.2.
3. Set up /rw/config/rc.local on wallet vm. Guide section 4.2.
If all of that is done correct, the gui is set to use a local node, and
you still have no connection then we will need to do a lot of back and
forth with running commands in vms and telling me the output.
--
qubenix
CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20
EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765
--
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/86c93f8b-5a4c-4c83-a521-79e708c54e6c%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: How risky is GPU pass-through?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Zrubi: > On 12/23/18 9:34 PM, Demi M. Obenour wrote: >> Someone I know is interested in using QubesOS. However, they >> are also a gamer: if they could not have a Windows VM with access >> to a dedicated graphics card for use by games, then QubesOS is >> not an option for them. > > Short answer: Qubes OS is not an option for them. > Why do you say that? If you search this list there are people that successfully game on Win vm with gpu passthrough. > > The risk part would come only after this feature exists in practice > ;) Search back for the details. > > I can't speak to the security risk from personal experience or knowledge, but I found this: https://security.stackexchange.com/questions/162122/gpu-passthrough-security/162175. - -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEElgluTKCHDxxbr33ZCdFZ4SQfnFQFAlwgMjdfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDk2 MDk2RTRDQTA4NzBGMUM1QkFGN0REOTA5RDE1OUUxMjQxRjlDNTQACgkQCdFZ4SQf nFR7IA//YE7rVNDmYFiXmIU9v7d7j9Bg3bPNSQ6wFnWNclylA3NSvzJ2k/uurcXW HSz/7r3jDSnJgD6trVan8SMOLlVhU48Hz9FCOxrVagwU69Ch+70vEZplauDcbEC7 UKu3vTFaC5Gawu8EHSqeT97eYCjSqvc/K82g6Wlij9uYOp7juTpQXX9ekIYH4i94 2TI+ZEYCJ/IaoL12aNQbDz6TzR6lsQDnsUiEppd1hnCX/yQphVymRlFG4qBQsXUA 40cAiqSUvpoAchxiWuTS7o4wCblSgrYkHHNzBvX0i+8JhSVmiknloPb+rBZmUVrs 0AoS2cqW3ojKIDXdfQ5Yn27p9TSR9AkoGbNDN9hZSl0CQTjXDGKV/Lcdj9qSSy+X +xOEJL63nYp94hofsDmZhg7EfcARA5C5JbLF0TzA2fyXlO7hgoX/SsCAv+KaDWhE 8B3Sq+sWH7MAfiJOK/UZN52Bi+I5hUsYsdXPTDSxqkhc6aOnYL8i9wi89gPZ4iVi JTQ6Tzn87Y5fWeBnz10viMWyfj71rD1AktA9GM20zsw60jx+GcDwtxOHxQLWRTNb vR1KuET9E+XaS4oEmTcNDACNj0ui+H7OgCRt64plfOttrc9FDtUXgTLMHypMx0bV zNsV02DucRNWaFSpG6ZrXJMarqvC4NLihAFzhpo2QsGQSpTgiME= =suwp -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/174d9e11-0e0a-7924-b8f8-5339b138358f%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
OGBaby: > The last line of the bitmonero.log says: ERROR blockchain > src/cryptonote_core/nlockchain.cpp:3728 Exception in > cleanup_handle_incoming_blocks:Failed to commit a transaction to the db: > MDB_BAD_TXN: Transaction must abort, has a child, or is invalid. > That is a new issue or you are out of space again (I think I remember seeing that in one of your original mails iirc). Either way it's not specific to your setup or to Qubes. Best to check on Monero channels (reddit, irc, etc). -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/33cd7193-a769-756c-7b71-cefce6f7b05c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
OGBaby: > Great info! > > I wasn't able to get 'torsocks ./monerod' running but found these options > browsing: > Why or where would you intend to run these? The monerod daemon should be running in the background as soon as the vm is started. You should never interact with the daemon like this. You should use `systemctl` to start/stop the daemon. You can check if the daemon is running by running `sudo systemctl status monerod` or using `tail` on the debug.log (I gave you instructions in a previous mail on that). > > 1. 'DNS_PUBLIC=tcp torsocks monerod --p2p-bind-ip 127.0.0.1 --no-igd' > > 2. 'DNS_PUBLIC=tcp TORSOCKS_ALLOW_INBOUND=1 torsocks monerod --p2p-bind-ip > 127.0.0.1 --no-igd' > You don't need these. They're for setups not as well designed as Whonix, or if you're offering a remote node onion service. > I just wanted to run these by you or the qubes community to make sure I don't > accidently mess with any default settings. (specifically the p2p option which > we've removed from the systemd file).> > 'torsocks monerod' or 'torsocks ./monerod' and the ones I found above all > attempt to resync the blockchain. Is this normal behavior? > As I said, don't run the daemon from the command line. `systemd` is handling it already. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/1d3968dd-06cd-a0ed-863a-038756f0a32d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
OGBaby: > Wow, I had to reread a few materials first but It finally clicked. Security > is the sole scope of this method. I had meshed a couple concepts together > somewhere along the line. There's been a lot of learning (using > linux/terminal included). > > I've managed to successfully download the entire blockchain. > > Just got the "You are now synchronized with the network. You may start > monero-wallet-cli." message via status. > > Monerod is running. The Height displays as "1727318/1727318 (100%) on > mainnet, not mining" > > The log: 'sudo tail -f /home/monerod/.bitmonero/bitmonero.log': "Synced > 1727379/1727379 -- Synchronized Ok" > Congrats! You're well on your way. > > Only 1 error: Torsocks. Specifically, "connection refused to Tor Socks (in > sock5_recv_connect_reply() at socks5.c.549)" > > > P.S. Must I wrap 'monero-wallet-gui' with "torsocks"? This is what I'm doing > now. No, only the daemon needs `torsocks`. The wallets (cli and gui) just make a local connection to the daemon so no `torsocks` needed for them. > > Created the wallet and made time to write down all keys & seed. Connected to > Local. > > The GUI, I assume, will remain disconnected. You mentioned above that things > should be handled within the Daemon vm, would you mind filling me in? (i.e > confirming xmr recieved, sending xmr to address) I'm not sure what you mean by "disconnected", the gui will connect to the daemon to retrieve information about the state of the blockchain to derive your balance. However, it will not connect to the internet directly to help protect against remote attackers. I haven't used the gui in about a year, but if you look at left sidebar there should be some indication that you are connected to the daemon and it will also show your sync progress (the wallet also needs to sync your balances, but it only takes a few minutes to an hour depending on hardware). This might be helpful for you: https://github.com/monero-ecosystem/monero-GUI-guide/blob/master/monero-GUI-guide.md. > > Or... does monero-wallet-cli commands take it from here? As you can my tell > my fogginess is with the addition of the GUI. > You can use either the gui or the cli with the same wallet. It's really just a matter of preference. > > I've also taken a look at './monerod --help> That will give you the daemon's options. If you want the cli options you need to run `monero-wallet-cli` from the wallet vm and the type `help` at the prompt. >> The infomation online is a bit scattered however I completely understand if you'd rather point me some links or resource instead. Any more guidance is appreciated. > Try here for further reading: https://ww.getmonero.org/resources/user-guides/. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/fd921760-aa0f-f15d-18c0-74c4552e6070%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] alternative to bloated templates for faster work and minimal boot time/resources used
> But here's how you could start the loop: > > qvm-ls --running -O name | (read line; while read line; do qvm-run -p > $line 'your vm command goes here'; done) > > There is an extra 'read line' at the start to get rid of the qvm-ls header. Adding `--raw-data` should avoid the header (untested). -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/305c855b-7498-a61f-72aa-abef0c10%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
OGBaby: > Thanks Qubenix, > > Wouldn't a fully synced daemon mean the blockchain is downloaded onto disk? I > was under the impression a benefit to remote node over local was to entirely > avoid downloading the blockchain. > > With the bootstrap-daemon address attempting to alleviate users from becoming > discouraged or impatient during the long-wait by temporarily letting them use > remote nodes while it syncs local. Am I misinterpretating Monero's remote > node all together? > > I can definitely increase the vm but there isn't 75G available. Please let me > know your thoughts. > Using a remote node is a completely different scenario than what this guide is doing. This guide is the safest way to use Monero that requires no trust in third parties, using a remote node is near to the least safest way and relies on third parties to give you information about the state of the blockchain and thus your funds. If you want to use a remote node I would suggest making a new vm, with networking, and use that as your remote node wallet. You lose a ton of security that way, as now your wallet is connected to the internet. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/c1a4af42-5a0d-7b16-ba6e-c0d958b78035%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
OGBaby: > On Monday, December 10, 2018 at 5:16:01 PM UTC-6, qubenix wrote: >> The best thing for you to do is: >> >> 1. Start the daemon's AppVM fresh. >> 2. In a terminal on the daemon's vm do: `sudo tail -f >> /home/monerod/.bitmonero/bitmonero.log`. >> 3. See what is happening in the log and report back. You can paste the >> log to a site like paste.debian.net or similar if you have trouble >> making sense of it. >> a. **Only if the log is sitting completely dormant** do: `sudo >> systemctl status monerod` and then: `sudo journalctl -xe`. >> b. Report back the result of those two. >> > > No problem. > > The Monerod logs: paste.debian.net/hidden/5a996a7a > > [Btw, I was interrupted during my session. I've marked #2 to mark the new > logs upon restarting vm's fresh] > > Also, could you clarify if this setup will leave the GUI as a view-only? > Considering it's offline. > >From the logs: 'Free space is below 1 GB on /hom'. Tells me your out of space on the daemon vm. Increase your private storage size to at least 75G. You can do it from the qube manager gui, or from a dom0 terminal with: `qvm-volume resize monerod-ws:private 75G`. The monero gui will work 100% once your daemon is synchronized, from the logs you are at 4% complete. You cannot use a remote node with it because the wallet vm has no connection to the outside world, set it to use a local node. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/eea4630f-bf17-76d4-358f-a1a512f5b828%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
OGBaby: > Greatly appreciate your help Qubenix. > > I can confirm my systemd file (/lib/systemd/system/monerod-mainnet.service) > matches yours now. I have removed the following to do so: > > ConditonPathExists=/var/run/qubes-service/monerod-mainnet > After=qubes-sysinit.service That was not needed. Those will have no effect on your connectivity. They just give you the ability to turn the service on/off from dom0 via `qvm-service`. I don't remember why I omitted them from the Github post. > > It is now identical to yours. Thank you. > > Unsure if 'sudo systemctl restart monerod-mainnet.service' is sufficient so > I've stopped the daemon and rebooted instead. > > I did figure the Node settings wouldn't work via the GUI. I've tried > '--daemon-address' as well as '--daemon-host' but it didn't work via > monero-wallet-ws terminal. I've just attempted to pass these commands wihin > the Daemon: > > sudo -u monerod monerod --daemon-address node.moneroworld:18089 > > I'm sure that isn't a valid input for option. How would you connect to remote > nodes within the Daemon vm? > > I've only found the '--bootstrap-daemon-address' command listed here: > https://monerodocs.org/interacting/monerod-reference/ > The best thing for you to do is: 1. Start the daemon's AppVM fresh. 2. In a terminal on the daemon's vm do: `sudo tail -f /home/monerod/.bitmonero/bitmonero.log`. 3. See what is happening in the log and report back. You can paste the log to a site like paste.debian.net or similar if you have trouble making sense of it. a. **Only if the log is sitting completely dormant** do: `sudo systemctl status monerod` and then: `sudo journalctl -xe`. b. Report back the result of those two. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/7f9fa29a-4b18-e4f0-ab8d-788c01c39311%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qrexec - Monero-Wallet-WS connection via Monerod-WS (Daemon)
ogbab...@gmail.com: > I have set two AppVMs and one TemplateVM for (split?) isolation of Monero. > The Daemon has networking enabled and the GUI (monero-wallet-ws) does not. > Qrexec seem to make this setup possible. I, however, am having trouble > connecting to node.moneroworld.com:18089, let alone > zdhkwneu7lfaum2p.onion:18099 I also use this setup without any problems. I did have to modify the `systemd` unit after the recent Monero update[1]. Try to adjust your file on the template to match what I have in the link, restart the daemon, and see if that helps your connectivity issues. The major changes are adding `/usr/bin/torsocks` to the `ExecStart` and changing the `Type` to `simple`. As far as connecting to remote nodes, are you doing that in the daemon or the wallet vm? The wallet vm has no networking and so will never be able to make a connection to anything besides the daemon vm. [1]: https://github.com/monero-project/monero/issues/4468#issuecomment-429671939 -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/3dbad9f3-5fbc-f295-65c0-72c6aa85cbdd%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Donation costs
Achim Patzner: > Patrick Schleizer wrote on Mon, 19 November 2018 08:33 >> I don't think crypto currencies add much carbon dioxide >> compared to >> legacy financial institutions. > > Answers like this make me wonder how people arrive at their > threat assessments. > > If you do not know the facts making assumptions based on > your wishes does not work. I strongly believe in finding > facts if I do not have precise data. Try taking a look at > some research: > https://www.nature.com/articles/s41893-018-0152-7.epdf (if > you do not want to pay for the article you will be able to > read it at sci-hub). The current equivalent of the creation > USD 1 in Bitcoin (at the time of writing the article when > Bitcoin was still more expensive than today) is about > 17MJoule (about 4.6kWh). Gold is currently at 5MJ. The > mining of the first 6 months of this year took 30TWh, > estimate for the year is 73TWh. If we're lucky this will > have led to less than 70Mt carbon dioxide. If not we will > have gained quite some nuclear waste we still don't know how > to deal with. > > And as you are making noises about banks: Please add in the > environmental cost of all the computers involved in Bitcoin > transactions. One Bitcoin transaction is currently costing > about as much energy as 40 credit card transactions. > > And yes, the reference section of the article is quite > interesting. > > > Achim Patzner > Good response to this flawed, ignorant study: https://twitter.com/nic__carter/status/1056976815032582144. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/1dcfe60d-8c74-3f98-8e66-c5097d5e2dbe%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] how do I check Tor & Whonix version?
qubes123...@gmail.com: > Thanks a lot for your tips and advice, my Tor version in Qubes4.0 - Whonix is > 0.3.2.9. Which Tor version is currently the most current and the safest? I > do not know the goal is 1000% safe but which is the best and safest version > currently? However, I could not figure out my Whonix version, how can I find > out which Whonix version I have? And if my Tor version is not backed up at > the moment, how can I upgrade this? Thank you for everything in advance. ;) > Sounds like you're on Whonix 13. That would explain why you aren't able to easily find your version number. Another giveaway is your Tor version. On Whonix 14 I have Tor version 0.3.4.8. If you want to upgrade to Whonix 14 see here: https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/7b5c295e-19dc-db69-ca95-26a1e0381082%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] how do I check Tor & Whonix version?
qubes123...@gmail.com: > I entered -> "whonixcheck --verbose --function show_versions" and got this, > see screenshot in the link. > > https://ibb.co/b2GZq0 > In your pic you forgot the underscore in `show_versions`, no need for sudo. This will not give you your Tor version. For that you have to run `tor --version` from the gateway. You could also just do `cat /etc/whonix_version` from the workstation or gateway for your Whonix version. I mention it because whonixcheck produces output you don't need. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/26cec056-151c-b939-c306-04fe563ed461%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Two VPN questions and one Qube Manager question.
birdynam: > To get your vpn randomly, just replace the openvpn.ovpn file in rc.local > by something like `ls *.ovpn|shuf -n 1` might do the job. > > AppVM → sys-vpn → sys-firewall → sys-net should be ok. Just put rules in > your sys-vpn (/rw/config/qubes-firewall-user-script) > > Birdy. > > I've been using `remote-random` in my config for this. From the openvpn man page it is explained: --remote-random When multiple --remote address/ports are specified, or if con‐nection profiles are being used, initially randomize the order of the list as a kind of basic load-balancing measure. -- qubenix CODE PGP: FE7454228594B4DDD034CE73A95D4D197E922B20 EMAIL PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 IRC OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/fb05aaed-6546-898b-a881-91e3b4f3a3d6%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] My farewell to Qubes OS!
Joanna Rutkowska:
> Hello Qubes devs and users!
>
> It's been nearly 9 years[*] since I sent the first internal email
> within ITL to Rafał Wojtczuk and Alex Tereshkin with the original idea
> for making Qubes OS. Shortly after this, we started drafting the
> original architecture and writing some early PoC code...
>
> Today, I've made an announcement I'm switching focus to another area
> of work and joining the Golem Project as a Chief {Strategy, Security}
> Officer:
>
> https://www.qubes-os.org/news/2018/10/25/the-next-chapter/
>
> https://blog.golemproject.net/joanna-rutkowska-joins-golem-as-chief-strategy-security-officer-13f12f0c11c0
>
> I'd like to thank all the people who made Qubes OS possible, which
> includes: the whole ITL team, all the community contributors, and, of
> course, all the Qubes OS users!
>
> Qubes OS will continue under the lead of Marek Marczykowski-Górecki,
> who have been a de-facto lead for all the day-to-day development for
> quite some time already!
>
> Thanks, Marek! Thank you, all!
>
> Cheers,
> joanna.
>
> [*] FWIW, the exact date was November 11th, 2009.
>
Thank you for all your contributions. Your standards for security and
best practices have been an inspiration to me.
I wish you the best of luck and success in the future.
--
qubenix
PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54
OTR: qube...@chat.freenode.net
OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765
--
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/fe9cb528-6a3c-06b7-6e21-370cbe9ac60b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Autostart fedora keychain service in a qube?
'Bjoern Christoph' via qubes-users: > I've set up a Nextcloud server in my LAN. This one works fine on all my > systems, works very well in Qubes 4.0 using a Fedora 26 qube and also > autostarts. > > I specifically use Nextcloud to sync my keepass file across all systems, > that's pretty important as this file changes often. > > The problem using autostart for nextcloud though is that when the qube starts > I am asked to enter the password for my nextcloud user account. > > The popup states: > > "Reading from keychain failed with error: 'No keychain service available'" > > Now I could of course start keepass, copy my cryptic password into the popup, > then once nextcloud is running close keepass so that the keepass file is > updated if required and then start keepass again. > > Um... no not really, that's very annoying. > > I checked the group and have not found anything helpful here. I don't think > that this is a too uncommon problem? Any suggestions on how to solve it? > > Thanks a lot! > > Best regards, > Bjoern > Off the top of my head: set keepass to automatically save all changes. Then your file is always up to date. -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/a95510f7-c964-39c6-95ae-692dfc4802c3%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] firefox plugins on disp templates?
Stumpy: > I realize this is marginally relevant but thought that I am likely not > the only/first one to think about this so Id reach out to see if anyone > else has solved it. > > I LOVE the disp feature and use it fairly often for random browsing, > but, I miss a few addons. I managed to add them to my template (which I > am think might be bad op/sec juju) but even then, when a new addon comes > out the browser updates so I have to update the addon manually in the > template which is a PITA that is quickly becoming not worth it. > > So, is there a way to have addons in a browser in a dispappvm and avoid > this issue? > This should help you: https://www.qubes-os.org/doc/dispvm-customization/. -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/f1220884-d7fb-afcc-1cb2-e2af935860af%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix
> Exactly the same issue. > Running monerod with torsocks was working for me too. > Check my comment here: https://github.com/monero-project/monero/issues/4468#issuecomment-429671939 Running monerod like that from systemd or the command line (with or without --non-interactive doesn't matter, only with systemd needs it) is the best experience I've had with it on Whonix in years. -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/d28d837a-6120-c54a-52cf-91b363f24fe8%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix
qubenix: > mk: >> One last thing, >> >> It should be noted that I still had to remove option >> "--p2p-bind-ip=127.0.0.1" to let monerod bind on 0.0.0.0 to make it work. >> >> Any security implication about this ? Does all traffic is still routed >> through Tor network ? Forgot to mention that there is no security problem to bind on 0.0.0.0. -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/0dbc186f-4c46-fe6b-e8d7-3e66af1cddcc%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix
mk: > One last thing, > > It should be noted that I still had to remove option > "--p2p-bind-ip=127.0.0.1" to let monerod bind on 0.0.0.0 to make it work. > > Any security implication about this ? Does all traffic is still routed > through Tor network ? > If you are using gateway sys-whonix then all of your traffic is always using Tor. Not sure what you mean about "make it work", but I'm having some stalling/connection issues[1][2] on the newly released version (v0.13.0). At first connection issues were solved by adding torsocks to monerod when using Whonix gateway or binding p2p ip to 0.0.0.0 if not using a Whonix gateway. Next I started to experience stalls, which I still haven't found a solution for yet. [1] https://github.com/monero-project/monero/issues/4468 [2] https://github.com/monero-project/monero/issues/4469 -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/c3466858-cc53-118b-3e79-11ef6de7c132%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix
mk: > qubenix, > > I thought I had to run a full node to be synced with main blockchain but I > now understand that running a local node is enough > > So everything works as expected, > > Thanks for you answer and clarification :) > It's still a full node because you fully validate all transactions and blocks as they come in. You just don't send them to new nodes trying to sync. Glad it helped. -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/ffc22c09-06c7-494e-baea-7d09af6a3113%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Guide: Monero wallet/daemon isolation w/qubes+whonix
mk: > Hi guys, > > Thanks for your work on this. > > Setup is working fine for me except that I could not find a way to properly > forward i2p port (18080) from outside to monerod-ws when using sys-whonix as > the netVM, I had to switch to sys-firewall. >> (Script used to setup port forward https://gist.github.com/Joeviocoe/6c4dc0c283f6d6c5b1a3f5af8793292b) > > any ideas on how to fix this ? > It's not i2p port, it's the p2p (peer to peer) port. 1. You don't need to open that port unless you want to. It's only used for serving blocks and transactions to other nodes. Monero's documentation suggests to not open that port when using Tor. Not to be confused with the rpc port (18081), which is opened when wanting to create a remote node for light clients to connect to. 2. If you want to keep using sys-whonix as NetVM (better for privacy), and you still want to open the port, use a Tor hidden service: https://whonix.org/wiki/Hidden_Services. You'll just have to advertise your onion address out of band somehow because Monero doesn't have a setting like externalip= to let peers know about your onion. Probably not worth it. 3. If you want to use sys-firewall you'll have to remove the p2p-bind-ip=127.0.0.1 from the /lib/systemd/system/monerod.service file on the TemplateVM. You will probably also have to allow the port forward on your home router somehow. -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/5e2c15c7-e5b1-5ae0-187e-22cc2adca019%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Problems with split PGP (QUBES_GPG_DOMAIN) in 4.0 + fedora 28
Zbigniew Łukasiak: > 1. QUBES_GPG_DOMAIN env variable somehow gets cleared between the > shell and the Enigmail process. I set it in the shell before starting > thunderbird: > > user@personal:~$ export QUBES_GPG_DOMAIN=work-gpg > user@personal:~$ echo $QUBES_GPG_DOMAIN > work-gpg > user@personal:~$ thunderbird & > > But when I look at the Enigmail debug console I get this error: > > enigmail> /usr/bin/qubes-gpg-client-wrapper --charset utf-8 > --display-charset utf-8 --no-auto-check-trustdb --batch --no-tty > --no-verbose --status-fd 2 --fixed-list-mode --with-colons > --list-config > ERROR: Destination domain not defined! Set it with QUBES_GPG_DOMAIN > env variable. > > > 2. Enigmail somehow refuses to accept > /usr/bin/qubes-gpg-client-wrapper as correct setting even if it > apparently uses it (see above). I keep getting this erro message: > > Enigmail: Error in accessing Enigmail service In order to use > Enigmail, GnuPG is required. If you did not install GnuPG yet, the > easiest way to do this is using the "Setup Wizard" button below. > > And then when I set it up in the wizard I keep getting: > > "The file you specified is not a GnuPG executable. Please specify a > different file." > > Thunderbird data: > Name Thunderbird > Version 60.0 > Build ID 20180829122858 > Update History > User Agent Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 > Thunderbird/60.0 > OS Linux 4.14.67-1.pvops.qubes.x86_64 > > > Not sure why Enigmail is not recognizing the env var, but you could put your gpg domain into the file /rw/config/gpg-split-domain as a workaround. I use this method without any issues on r4.0. Not sure about your second issue as I've personally never that problem. -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/e69bc191-6a91-6d35-e52e-a2e6580735a6%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Signal installation returns gpg: no valid OpenPGP data found.
qubes-...@tutanota.com: > I try to install the Signal to my debian-9 template, following the guide > https://www.qubes-os.org/doc/signal/ <https://www.qubes-os.org/doc/signal/> . > > After I initiate > $ curl -s https://updates.signal.org/desktop/apt/keys.asc > <https://updates.signal.org/desktop/apt/keys.asc> | sudo apt-key add - > I get > $ gpg: no valid OpenPGP data found. > > Thank you > You have added this part "<https://updates.signal.org/desktop/apt/keys.asc>" accidentally. The correct command, as shown in the guide, is: curl -s https://updates.signal.org/desktop/apt/keys.asc | sudo apt-key add - This should work as expected, I just tested it. -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: DFD1DA35 D74E775B 3E3DADB1 226282EE FB711765 -- 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/ee063803-5308-39bc-d192-150f3cab93b8%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: whonix-ws-14 apt-get autoremove broke the template
sbore...@gmail.com: > Am Montag, 17. September 2018 23:48:27 UTC+2 schrieb qube...@tutanota.com: >> hi, after the last update of the whonix-ws-14 template with recommended >> apt-get autoremove, the template got broken. >> - Most of the apps disappeared >> - torbrowser doesnt connect to net >> - template itself cant be updated. >> >> user@host:~$ sudo apt-get update >> Reading package lists... Done >> E: Could not get lock /var/lib/apt/lists/lock - open (11: Resource >> temporarily unavailable) >> E: Unable to lock directory /var/lib/apt/lists/ >> >> Upon launching TorBrowser, the wellcome page is "File not found". Upon >> trying to connect to a web page, "Secure connection failed". >> >> any ideas? > > Hi, > > was bitten by this as well. The whonix repos must have been in a strange > state yesterday (Sep 17), and a dist-upgrade removed too much stuff (with > essentially > the symptoms you describe). > > I bit the bullet and just reinstalled the whonix templates, followed by > apt update/dist-upgrade/autoremove and today everything behaved as expected. > > It would be great though if it were possible to avoid these 'flaky' states of > the whonix repos .. > > Best, > > Stefan > Happened to me from the `testers` repo yesterday too. Luckily I noticed all the packages to be removed, declined the upgrade, and switched to `stretch-proposed-updates` repo. Don't forget you can always use `qvm-volume` to revert your template changes (as long as you haven't restarted the vm since breaking it) instead of reinstalling. See `qvm-volume --help` for details. -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: 3AAF6650 F818BDBE 267C7866 E4A0C614 DBD5EEAD -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: 3AAF6650 F818BDBE 267C7866 E4A0C614 DBD5EEAD -- 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/d1a16eec-7308-5298-fc45-286078540a91%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] how can i patch xen?
Hello all. I'm attempting to build a custom Qubes with one patch added to Xen. Is it enough to simply add the patch with the others in qubes-builder/qubes-src/vmm-xen/, add a line for it in qubes-builder/qubes-src/vmm-xen/xen.spec.in, and then build? -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 OTR: qube...@chat.freenode.net OTR: 3AAF6650 F818BDBE 267C7866 E4A0C614 DBD5EEAD -- 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/e64bfe4b-5072-bc5d-c5c8-77bb486d007a%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - MSI MS-7980 (update)
This is an update to my current HCL entry: https://qubes-os.org/hcl/#msi_ms-7980_i7-6700k_skylake_hd-graphics-530. Since then I've added a GPU, updated BIOS, and moved to Qubes 4.0. Both integrated graphics and the GPU can provide graphics without a problem. Support file is encrypted to the following keys: Andrew - BBAF910D1BC9DDF41043629FBC211FCEE9C54C53 Joanna - 49A322D9CA0D1D7DAEFA2AC63393D8BF0DDC6718 Marek - 86BA6E93318FBA446642A90ADB8FD31CCAD7D72C -- qubenix PGP: 96096E4CA0870F1C5BAF7DD909D159E1241F9C54 -- 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/679a4c3a-134a-1496-f4ab-428e4bf9568b%40riseup.net. For more options, visit https://groups.google.com/d/optout. -BEGIN PGP MESSAGE- hQIMA607L7LGhs0oAQ//WtQcRqKYvCCoxFs4TBZ2hlXWRsVjupo7ipbQbKQv5mU8 N07KMAjD8xd+NbmFKVS5YitBWQBqZwre3T5dUum3hiRPbVz9rZ86GnKbElSL88AD sOsnsamvqppVloSrCgSYy0+XoT+XjSF2OsO+EBagGMDYndMPUM2yPLtPUNGxAAED bHb8DsglbTDYDUJ5qmtshY9rHMPGhH6SZbA9TKbtRTid++epVOddOInE7sKmEP7Y QDN6vXf4G4oEfkOuyXQGY9gpn2e9A4IkOdXeEQPQakNRgJsmeyq1ku33Zp9G/J4k UrmqNOWFU8z/deVzU/BCxMHItwuftwWMaaRl4RJks76nSF6i/iIzoBbMmK3atZrJ 1BqQt64IGo/Z7CF2n23UeQIHA6iP8kobSwWy9MzbkcQ8XrYp213AolLkbldG19ZG Fg/W5TwzsBdzJTw881URsZ95naV3fqL73B+sI7gijbSpQaZwvrUVUpobL9fByOYy e/9OyP8jFUY6Pq13ckTUYZPYBF0zsFCXnHU70F7zPlfQbLm6ioD2spLwdfV+E+uZ CEiATHShX2+KF4lGlHvC7BNMmKHYQPAummsPaRRAQyS3jGucT2efyETcxk6pkgQU IuUiGm1EecImnAws4CoXnfcNhdX6tLf/DS6I+PKT6eS07tbIHEHTcKpskVbopx+F AQwDqH2PP4A1NFQBB/9EdgfNZFGUkOGtehPCMOFyuI0J3DHsgyMQGsGP4N9J+PiU gf/GERIvdzACcdC1/6OBKtqc7JxltrrgmuXcrE1MF4i/5A8q98uPkYdMpG7WJFGP dxfmiv3J+/qZy0Dsr3/gE48TfSKdVSWI2mZFPdeZmp0qlMl1HSAHWtk80fiBrBPx mPdjZY6F/5FZVZ9OtXRuuQ7KRNPqjggW8uMRNtmlJ1PQloQTayyNigm3CSlAoR+Y W2MaCziIN+2lvK2QfzvoJ/X8tLwdJg9PxMZBZN+umYE9PJkFeDP3z1yIiPtYaKb8 DukuGS+f++nNZftWpFFOIeeUos5yNVWPC3vUMmaNhQIMA1oPwWKpItGOAQ/+LMFi 8CfMKaiisJv/tZeYwVMl9PrjWeuRHUzu4F2sernxI9u/rAgKP+l9/kMyV11N54mx XseI0t8TIRf1cGBdMcm0zfvdKTUxrka3yrE/solbHWnlX9npytAFKv3mO6wE/4my 1VEiPY/4UqYvMivU3aS27OU9D4ZrP1Xb0Fc2z8rFfwD9t1as4mK9GW4TFAGopwsF ALIaMfutquEvtd46iqoTPLSzLP9Swn1ZNABQ7Qp3KgKxpHvF0B9O1JcJQlOeIEKg LGp5tuJcxieGwkUvaZg/Y2MxlAcJusWzKb1MKMptyH4jTG5ELrWWhJjXwEY9dAH7 uMYnyujhoPsXFFmz0r9NrlfOVkr+8R1Rev7OxS84HOM0kq3Wh5TpNxdrJ5tX8QFG Bt2eLqKlZotyO83rgWpzw4UQxyb3uZcZYIOVZ274lQnn4Yzt+lyUJioiFZPL2a4b JCXW9dHFZTvQ+/TwThV4UPJP4FpC8gz0wOinzxzsHkRxqR7DKHEFIU9XOQMiH1f/ NybAOIekx4VkmjHB3C508eYzNpDwYgwsR3lj8O1Jh+my//xjM2W1RxpHT2KGitrJ Y/eAw+W13dCkFLXXixZWMu6q+fOi3sSA+HFsoD4mwLoqWPThcu8ryKCuyKJ09bLS Rb0vjYHVX1t10TTOgF3cVS/nSFepRxUMD+GYphiFAgwDyh7gS80KxbUBD/94T1No +gFNp+gQX2pKMVfWgZrzAso2c7SUnBy9WvGLt49meERVhfD5XOkoBebJ3F1N2xut DklmlVYsXSefO2vLy3UlN6rUyU4KYUJitl5no23h92LJ8TxxHamxekANXiW8zHL0 rSjLtZdTiqKEHIExwYuxQx3cgn9tnq/Y+UjAGZu+oFzBWhZWM77sC/v4HFcjjSiu UVW1662cSzBfGb1gpa32wJOJ3WjHqMQ5NE03zD0tXSW2Q0diZoLJkQbqEjBcfBxR 2FFK1UEhOyXTbaPB2WDYg5yEPadH36xuXJ7toADQhrZXt9QAHT5fLaR8U68ePE2Z /8JXSfoyvFh1rAfvd8+0RfkW7W1rjCpLYWAbouOvT6qSZo7IKGbz1bcNsus+i6tb 2LLlJUDUQsbqLHZPD3AExKcTkb0KQ/pHwbiMtRi3CNNG3TNdw/oRYVvbCApUwmwy 2o8qI04+35sbsuKkIdyU4CHW/rjM2kjh0JABVCfpu6YK16WUWv8p4LoFxh4vhRvO FXYoHc/3FW7uYNVf3ZBtoKLucC8mVsYp3QfMY0ZWHuc8jc+xz/fC99EmOrHLyqOW s3rL+C3l/RpuzsiqW5jdUFe2ZrW8zrrZdA52MptqJ0MwIQmlUBpaUYxdboU3LWlP tf9lE7nw5v8YaDEE9R2rgHBwgP8dJlZhi2S/q9LtAV5IY/j5Pf1U/YlJVhu15IJn 0lf5KZpdkNYm+ItMwfZoVq/60430beORWR6OIwNT+Wj6R3ciQJkmcW4bG2cjr2py YSvCVUJInt6WzFJ5zDn6m1iZlDqx3WCOMWbYumO1oAenwsyRQDWNjZVMhyhgukXi BxCrJyq0FgdM4QV32ZZ1cfvqc/CFWt8weLORZwalrJtwsogJmJGAHvpRzhTYB3cs pSTqwtM66N7z21QAEu8YKJsjITXZDg9QL1oFruWJOkCeZGcj0S9pGy2EOmKcKHDa EgwJy4by7hNkHt+6N5j/gmsbmrVmPub0NT8wmdkqnvo6DvmnjXUa/SH3uWiCRnmG Znx7dtIdkiGNva+nvL2uq06yzHv+BpQ6n/rkbQG3zWhcqbirKmxYbtICuRBZS9KC ng9ZBjJGWQWmKje9538IGFh297n7pk6S/SVIjxMSNVsfJTN0jTWTSbDrAiKD6UDA 8cPjojEJE8O2h86GTko3VU9I9nAUKN0Ly3XSjjZdVFBz3tHIETg3Sqm3lOJCWfbW Wo62m4el/s8o9xoFJR8H2g7Hdlp7jSopCQQVXxZuWFDss9JXjQPQ5Y6EcxE2ncnM cWEPlwj/Quwc0y5ztp+l1OPmYIPsuL1OG9613RUzPoPTMZG4FmONrIU+o7Dd1w0q NQa1vpK0hMzLCZJCRsuXfLKRflT5sFEhHJL4x8foLsxwNPC7Gy81VwfH99EbVzRP cc/zlXiXL5YOphvgFWSfXCWrJne0tPJsEH2zugFE8GehcTSOJmKLRfa424INfO69 enkeZUFIeJpOJQFvUHv0k9gZwqlHAsEPxbiwfl9J7l4OpQPqJiQNLT/p1kOqRkS/ +AFDDXzdGeyUFj5XO7o0Qq2YO1kp5w0/In8b7eEcF5SXjRfBeUz0MJIEZRNEP6LQ P+W5Ps3Mz+igjGoPMS8vDgRDAg0g7ewY+voF+6UYX03WZTUHhBgQXmkQZdQxOBfz jGioKi+5v1arE2LDGkKiBTdUMyYwYBo1nWpSxUN7z5bCt6aRBtSnev2KHL/NK3J3 bAr8TkMUShQwBEZWhfww63ApKoqd8A+rpXTxICnvx9PynK9hHtET1UxUrwVMEOpE abpeij6kBGjzkv4FhLBxGW99fyZMz7UcPm9qAQF4ETVmYxfLOU2aP/qi5EBACws2 3qnKKDFvyzQ0mOyx9cJ4HOF6i4Qa4eSUq9C6F06fbQS9IPQKzfFFsYY097QO+ls3 HzeFphBz7DI0gqYx6DK//S4MoZZ5e8kgc9VXLc5nK8GU+P0butp1SjhvaAYVI5bR HI17R7tgFaDpzxmhMgLpB4IO9BPDMXKEUsvAKp3oWbO9di9uqQL/e0fmvB7m6S/G GJv/vwiPlDIEJdBhKs7gCnK1dsfN7vm
Re: [qubes-users] Re: why Whonix and not Tails or the anon-vm?
john: > On 05/17/18 06:25, awokd wrote: >> On Thu, May 17, 2018 3:46 pm, >> josefh.maier-revL73yDgGBWk0Htik3J/w...@public.gmane.org wrote: >>> Hello Forum >>> >>> why was Whonix and not Tails selected for thes anon-vm of QubesOS? >>> Thank's for your feedback! >> >> Don't know the exact discussion that led up to it, but I imagine it's due >> to the flexibility Whonix-Gateway provides by permitting anything >> attached >> to it to get routed through Tor. It is still possible to run Tails under >> Qubes, see https://www.qubes-os.org/doc/tails/. >> >> > technically this is a whonix question, I would suggest posting there : > > https://forums.whonix.org/ > > or read their docs a bit 1st, then patrick and crew respond to most > posts . > I believe it started here: https://blog.invisiblethings.org/2015/06/04/otf-funding-announcement.html. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/b48a06b0-49b0-e468-6c64-62e8564d6d9c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] opening links in another VM opens two browsers
awokd: > On Fri, May 11, 2018 2:56 am, qubenix wrote: >> Hey everyone! Hope you are all doing well. >> >> I followed the guide here: https://www.qubes-os.org/doc/tips-and-tricks/ >> so links clicked in one debian-9 AppVM will open in separate debian-9 >> AppVM. What actually happens is interesting. >> >> If I have firefox running in the destination VM already, everything >> works as expected. The link opens a new tab in the proper AppVM. >> However, if firefox is not currently running, a clicked link will open >> the link in a browser in both VMs. > > Tried to recreate but couldn't. It might be a function of the application > you are using. What happens if you click links in a different app? > > You're right, in other applications everything works as expected. The app in question is discord for the record, and I'm not surprised it's doing unexpected/unwanted things. That's why I was just testing it out in a dedicated VM. Thanks for the tip. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/4cb66b99-1e76-f06d-2efd-59c439900696%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] opening links in another VM opens two browsers
Hey everyone! Hope you are all doing well. I followed the guide here: https://www.qubes-os.org/doc/tips-and-tricks/ so links clicked in one debian-9 AppVM will open in separate debian-9 AppVM. What actually happens is interesting. If I have firefox running in the destination VM already, everything works as expected. The link opens a new tab in the proper AppVM. However, if firefox is not currently running, a clicked link will open the link in a browser in both VMs. Any ideas? -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/47091bca-90fe-286a-e851-008d3f8af1c4%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Ledger Nano S
bojanso...@gmail.com: > In Qubes 4 I can connect all kinds of USB devices via the device selector in > the upper right corner of the window. The Ledger Nano S is a hardware wallet > for cryptocurrencies. Ledger Manager is an extension for Chrome/Chromium > webbrowser. When I connect Ledger Nano S to a USB-port it is recognized by > Qubes and I can select to which VM it shoud be assigned to but it is not > recognized by the Ledger Manager. The Ledger Nano is recognized by Ledger > Manager in other OP's like Windows 10 and different Linux. Any ideas about > what the cause could be? > > I have tested sys-net, sys-firewall and sys-whonix. No difference. > Also tested StandaloneVM based on Fedora26, Debian9 and Windows7. No > differences. > It might have something to do with udev rules in your target VM. See here: https://support.ledgerwallet.com/hc/en-us/articles/115005165269-What-to-do-if-my-Ledger-Nano-S-is-not-recognized-on-Windows-and-or-Linux- -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/25e4c33c-f47c-e074-1633-863d151dffd1%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Guide: Monero wallet/daemon isolation w/qubes+whonix
qubenix: > pauHana: >> After completing the to VM setups and shutting them down is the intention >> then to start monero-wallet-ws and interact with the wallet thru this vm as >> per the usual ./monero-wallet-cli? >> > > Correct. You should be able to run the gui from monero-wallet-ws as > well, but I haven't tried it myself. > > -- > qubenix > GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 > Please don't delete the conversation so the next person that has this trouble can see everything together. Is your daemon sync'd fully? -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/043be5f4-fca2-9e47-4845-06d3b1dc3cf7%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Guide: Monero wallet/daemon isolation w/qubes+whonix
pauHana: > After completing the to VM setups and shutting them down is the intention > then to start monero-wallet-ws and interact with the wallet thru this vm as > per the usual ./monero-wallet-cli? > Correct. You should be able to run the gui from monero-wallet-ws as well, but I haven't tried it myself. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/ae14b912-564e-d523-9633-7f8bf5bf9627%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Best pratice for crypto-currency wallets?
Dave C: > On Monday, August 21, 2017 at 8:33:32 PM UTC-7, Francesco wrote: >> Anguilla >> >> >> >> >> On Mon, Aug 21, 2017 at 8:14 PM, <anguil...@gmail.com> wrote: >> I'd like to use Qubes for my crypto-currency wallets. >> > > I scratched my own itch and made a qubes-friendly tool for XRP transactions. > I'd like to build the same for BTC, etc... but I don't yet know those as well. > > Details on https://www.dave-cohen.com/blog/rcl-tool/ > > -Dave > > > You can put any wallet in an offline VM and use qrexec to forward the needed ports from your daemon. Here's a guide for doing it with monero: https://getmonero.org/resources/user-guides/cli_wallet_daemon_isolation_qubes_whonix.html. The same basic procedure can be used for most crypto wallets. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/560af0d7-da9e-94b8-1f76-4030bd31d458%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: unexpected system restart
cooloutac:
> On Monday, April 2, 2018 at 12:31:09 PM UTC-4, qubenix wrote:
>> Hello all. I'm currently still on R3.2.
>>
>> I had a situation where I was working with a normal (for me) amount of
>> VMs running. Nothing even close to extreme as far as cpu/mem/io/temp.
>> During startup of an AppVM that I use all the time, my system just did a
>> hard shutdown ("no input" on screen, connected with hdmi) and then right
>> into a restart.
>>
>> How can I debug this in a useful way? Does someone have an idea what
>> might cause it?
>>
>> --
>> qubenix
>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
>
> weird. you using sleep mode at all? Checked the obvious issues like temps,
> hdd errors, memory stability?
>
No sleep, checked all obvious issues.
--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
--
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/e8db6aa6-f9d7-d833-cd63-ecd3cbd65c7b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] unexpected system restart
Hello all. I'm currently still on R3.2.
I had a situation where I was working with a normal (for me) amount of
VMs running. Nothing even close to extreme as far as cpu/mem/io/temp.
During startup of an AppVM that I use all the time, my system just did a
hard shutdown ("no input" on screen, connected with hdmi) and then right
into a restart.
How can I debug this in a useful way? Does someone have an idea what
might cause it?
--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
--
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/a55ee19d-0d67-2b53-667a-a0179dfe3acc%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-devel] Re: [qubes-announce] QSB #38: Qrexec policy bypass and possible information leak
> So let me be blunt as this is likely the last email from me to qubes anyway; Bye, I'm happy to see you go away finally. It was killing me inside that you were working on the new gui controller. Fuck off back to bcash. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/2b004517-b9b8-6507-dd04-173728dc3999%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Intel igd: boot freezes on kernels 4.9.5+
I'm using Qubes 3.2, I've got an i6700K cpu connected with hdmi. Only kernel 4.9.45-21 will boot when using Intel igd. If I try to boot from either 4.9.54-21 or 4.9.56-21 using igd the process just hangs at a certain point. I've attempted the solution presented here: https://qubes-os.org/doc/intel-igfx-troubleshooting/, along with "iommu=force" and "iommu=on". None fix the problem, but adding "iommu=no-igfx" causes a boot loop instead of a freeze. Any suggestions? I've got a gpu that works on the newer kernels, but I'd prefer to use the igd for dom0 and save the gpu for passthrough. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/a0192f90-7f67-99d4-d4e0-ad3a2da97d2d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Audio in Debian VMs just disappeared?
Foppe de Haan: > On Wednesday, October 18, 2017 at 12:38:05 AM UTC+2, Stumpy wrote: >> hm... >> >> Is there something else I can post that would make this easier to diag? >> I really really would like to resolve this. >> >> On 16.10.2017 02:28, Stumpy wrote: >>> No one? >>> I still haven't figured this one out >>> >>> in case the private/paste bin was causing no responses here is the >>> output from VLC: >>> from the vlc window: >>> "Audio output failed: >>> The audio device "default" could not be used: >>> No such file or directory." >>> >>> and from the term that I started vlc from: >>> VLC media player 2.2.6 Umbrella (revision 2.2.6-0-g1aae78981c) >>> [5e890a526938] pulse audio output error: PulseAudio server >>> connection failure: Connection refused >>> [5e890a4410e8] core libvlc: Running vlc with the default >>> interface. Use 'cvlc' to use vlc without interface. >>> ALSA lib confmisc.c:767:(parse_card) cannot find card '0' >>> ALSA lib conf.c:4528:(_snd_config_evaluate) function >>> snd_func_card_driver returned error: No such file or directory >>> Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared >>> object file: No such file or directory >>> ALSA lib confmisc.c:392:(snd_func_concat) error evaluating strings >>> ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_concat >>> returned error: No such file or directory >>> ALSA lib confmisc.c:1246:(snd_func_refer) error evaluating name >>> ALSA lib conf.c:4528:(_snd_config_evaluate) function snd_func_refer >>> returned error: No such file or directory >>> ALSA lib conf.c:5007:(snd_config_expand) Evaluate error: No such file >>> or directory >>> ALSA lib pcm.c:2495:(snd_pcm_open_noupdate) Unknown PCM default >>> [5e890a526938] alsa audio output error: cannot open ALSA device >>> "default": No such file or directory >>> [5e890a526938] core audio output error: module not functional >>> [76de94d7eaa8] core decoder error: failed to create audio output >>> Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared >>> object file: No such file or directory >>> [76de74001268] xcb_xv vout display error: no available XVideo >>> adaptor >>> >>> anyone? >>> >>> >>> On 07.10.2017 23:12, Stumpy wrote: >>>> For some reason the audio in all my Debian VMs has stopped working? >>>> AFAIK I haven't done anything other than regular updates. I didn't >>>> notice until recently so I am not sure about exactly when it started. >>>> >>>> In the audio mixer window none of the debian vms are showing up. I >>>> tried plaing something in VLC and it gave the follwoing errors: >>>> >>>> https://privatebin.net/?f36509f33694a053#821JIyu4z/YqpQ61qGRYFP9Bspo7DAP8HmkPJCAk9Q8= >>>> >>>> Also, another strange, maybe unrelated thing happened, I don' thave >>>> nautilus in my debian VMs any more and I tried to reinstall then but >>>> error saying I had some missing dependencies? > > pulseaudio-qubes is still installed? > Must be something with version 11.1-1 of pulseaudio. I've got the same problem on a Kali VM that has the following pulse packages: $ sudo dpkg -l | grep pulse ii gstreamer1.0-pulseaudio:amd64 1.12.3-1 amd64GStreamer plugin for PulseAudio ii libpulse-mainloop-glib0:amd64 11.1-1 amd64PulseAudio client libraries (glib support) ii libpulse0:amd64 11.1-1 amd64PulseAudio client libraries ii libpulse0:i386 11.1-1 i386 PulseAudio client libraries ii libpulsedsp:amd64 11.1-1 amd64PulseAudio OSS pre-load library ii pulseaudio 11.1-1 amd64PulseAudio sound server ii pulseaudio-utils 11.1-1 amd64Command line tools for the PulseAudio sound server However on another Debian stretch template audio is normal. The pulse packages there are: $ sudo dpkg -l | grep pulse ii gstreamer1.0-pulseaudio:amd64 1.10.4-1 amd64GStreamer plugin for PulseAudio ii libpulse-mainloop-glib0:amd64 10.0-1+deb9u1 amd64PulseAudio client libraries (glib support) ii libpulse0:amd64 10.0-1+deb9u1 amd64PulseAudio client libraries ii libpulsedsp:amd64 10.0-1+deb9u1 amd64Pu
Re: [qubes-users] Re: Keepass vault password no worky
yreb-qusw: > On 07/19/2017 05:53 AM, qubenix wrote: >> qubester: >>> On 07/18/2017 02:27 PM, '0brand' via qubes-users wrote: >>>> I've been trying to resolve a problem with both of my Debian-8 >>>> vault-appvms.. For some reason my Keepass passwords no longer work. >>>> When I type in the password I get this message: >>>> Unable to open database. Wrong key or database file is corrupt >>>> I have been using the same password for both my Keepass databases for >>>> quite some time now so the problem isn't due to forgetting or >>>> miss-typing my passwords. Normally this would not be much of a problem >>>> except for the fact that restoring from backups is not remedying the >>>> issue. I've restored both my Keepass vault-appvms and my Debian-8 >>>> Template. >>>> Looking back at the day before this happened there is only one thing >>>> that I did that may have contributed to the problem. I removed my >>>> sys-usb (netvm) and created a sys-usb (appvm). After I created the new >>>> sys-usb I realized that It would not run unless I set pci_strictreset >>>> to false. This was not acceptable to me so I removed the new sys-usb >>>> and created a new one with: >>>> sudo qubesctl top.enable qvm.sys-usb >>>> sudo qubesctl top.enable qvm.sys-usb >>>> The reason I think this may have contributed to the problem is because >>>> the first two times I tried to restore my appVMs things did not go >>>> well. The first time the Gui completely froze and I was unable to >>>> unmount the drive. The second time the backup-restore did not complete >>>> but at least the screen did not freeze up. The third time I used a >>>> backup from a couple days prior and everything went smoothly. It did >>>> not solve the problem though. I still can not unlock my Keepass vaults. >>>> I'm not really sure what to do next. Is it possible that my backups >>>> are somehow being corrupted when I restore them? I'm a little >>>> flustered at this point and I could use some guidance. >>>> Thanks in advance >>>> >>>> Sent with [ProtonMail](https://protonmail.com) Secure Email. >>>> >>> >>> If it makes you feel better, I had the thing fail. with the same >>> messages, and I'd swear, I did nothing at all, after that I stopped >>> using it . as pretty pointless to use something that MUST be >>> reliable and have it fail so easily, whatever caused it IMHO of course >>> ; I think mine was in the Vault VM >>> >> >> Which Keepass? On debian: >> >> user@host:~$ apt-cache search keepass >> keepass2 - Password manager >> keepass2-doc - Password manager - Documentation >> keepassx - Cross Platform Password Manager >> kpcli - command line interface to KeePassX password manager databases >> libfile-keepass-perl - interface to KeePass V1 and V2 database files >> >> I ask because I have been using keepassx for three or four years with >> only two databases. I keep multiple copies on different storage devices >> and I have had only one copy ever become corrupt, but it was the fault >> of the usb device. I use keepassx and kpcli with pleasure. >> > > keepass2 > guess that is a good idea to keep copies in various places > I don't actually know why I would use a usb device with keepass2, so > that wasn't it. > honestly, it was a trial, in the vault appVM , I was a bit shocked that > it failed within a few weeks, was enough, for me to use my other > password manager instead ..YMMV of course > To explain the usb stick, I keep a TAILS usb stick with me that has a copy of my keepassx db on it. Just in case I need to access this data while I'm away from any of my computers. It was this device that became corrupted, but only after massive IO abuse. I knew it would be toast sooner or later, but I always keep backups of this device as well. Always follow 3-2-1 backup rule! http://thehelpfulhacker.net/2011/08/04/the-backups-321-rule-illustrated/ -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/80bbbfe1-9490-2b23-8f16-8b518b841516%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Bitcoin Node on appVM
Unman: > On Tue, Jul 18, 2017 at 09:08:20AM -0700, Max wrote: >> On Tuesday, 18 July 2017 23:45:13 UTC+8, Unman wrote: >>> On Tue, Jul 18, 2017 at 08:33:37AM -0700, Max wrote: >>>> Hi, >>>> >>>> I have installed the Bitcoin Core client and wish to allow inbound >>>> connections. Has anyone tried doing this? I am able to connect to the >>>> network with outbound connections but have had no success when trying to >>>> get inbound connections >>>> >>>> I have taken these steps: >>>> >>>> 1) Installed Bitcoin GUI in the template VM >>>> 2) Run it in a dedicated AppVM, downloaded the entire blockchain and am in >>>> sync >>>> 3) Configured port forwarding on the router, removed the firewall >>>> 4) Followed the port forwarding steps >>>> (https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world) >>>> but replaced the port 443 in the instructions with 8333 >>>> 5) Tried to Telnet the IP address on the sys-net (appears to be >>>> 192.168.1.18 on the wlp0s1 and do check node on bitnodes.21.co but it is >>>> unable to connect to host / says my IP is unreachable >>>> >>>> Any advice >>>> >>>> Thanks, >>>> >>>> Max >>>> >>> >>> I'm always worried when I see comments like "removed the firewall", or >>> global changes to firewall rules. This is almost never the right thing >>> to do.You should be able to put new permissive rules in the firewall >>> and retain other protections. >>> >>> Anyway, 192.168.. is a private address, not routable on the internet. >>> What you want to provide is the EXTERNAL IP address on your router. >>> If you don't know this you can check it using nwtools.com, unless you're >>> using Tor or a VPN, in which case just log in to the router and check. >>> >>> unman >> >> Hi Unman, >> >> Regarding the firewall changes - possibly I wasn't clear. >> >> The statement removing the firewall was simply me disabling it on the >> router. I wanted to eliminate this as a possibility before raising my >> questions here. The only changing of the firewall I have done in the Qubes >> OS is the iptables changes on the sys-net and sys-firewall VMs. >> >> As far as I understand, whilst I may have been a bit of a fool to put in my >> private address in the telnet, the Bitnodes website was testing the correct >> port on the external IP address I have. I am getting an unreachable message >> here. I only did the internal address from a different device on the same >> network. >> >> Thanks, >> >> Max >> > > Hi Max, > > If you can monitor the router, you should be able to see the inbound > traffic when you run that test. > You can also run 'iptables -L -nv' on sys-net, and watch counters - again, > you should see the counter increment when you run the test. (Watch a > rule that allows traffic to port 8333, obviously) > You can also watch counters on sys-firewall and the target qube. > > By doing all this you should be able to see where the traffic is being > blocked, without needing to use a network sniffer or dumping traffic. > > Start at the outmost node, and work inwards. At the point where you dont > see traffic you know the problem lies one hop upstream, (unless it > doesn't get to the router obviously). > > If you see the traffic inbound at the destination qube, then it's > possible that you are blocking the return traffic on the way out. Just > reverse the process to trace the outbound traffic. > > unman > Max, Maybe you already know this, but you can use Tor to get through the firewall. Actually, if you install Tor in your AppVMs template, Bitcoin will set up the hidden service on the fly over the control port. If you're using a Whonix gateway it's a little more work, but not hard and I can help. Still helpful for the network. I use `onlynet=onion` in my Bitcoin config, so definitely helpful for me! -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/0ac3255a-998d-fa03-60e8-5a5241d53a65%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Keepass vault password no worky
qubester: > On 07/18/2017 02:27 PM, '0brand' via qubes-users wrote: >> I've been trying to resolve a problem with both of my Debian-8 >> vault-appvms.. For some reason my Keepass passwords no longer work. >> When I type in the password I get this message: >> Unable to open database. Wrong key or database file is corrupt >> I have been using the same password for both my Keepass databases for >> quite some time now so the problem isn't due to forgetting or >> miss-typing my passwords. Normally this would not be much of a problem >> except for the fact that restoring from backups is not remedying the >> issue. I've restored both my Keepass vault-appvms and my Debian-8 >> Template. >> Looking back at the day before this happened there is only one thing >> that I did that may have contributed to the problem. I removed my >> sys-usb (netvm) and created a sys-usb (appvm). After I created the new >> sys-usb I realized that It would not run unless I set pci_strictreset >> to false. This was not acceptable to me so I removed the new sys-usb >> and created a new one with: >> sudo qubesctl top.enable qvm.sys-usb >> sudo qubesctl top.enable qvm.sys-usb >> The reason I think this may have contributed to the problem is because >> the first two times I tried to restore my appVMs things did not go >> well. The first time the Gui completely froze and I was unable to >> unmount the drive. The second time the backup-restore did not complete >> but at least the screen did not freeze up. The third time I used a >> backup from a couple days prior and everything went smoothly. It did >> not solve the problem though. I still can not unlock my Keepass vaults. >> I'm not really sure what to do next. Is it possible that my backups >> are somehow being corrupted when I restore them? I'm a little >> flustered at this point and I could use some guidance. >> Thanks in advance >> >> Sent with [ProtonMail](https://protonmail.com) Secure Email. >> > > If it makes you feel better, I had the thing fail. with the same > messages, and I'd swear, I did nothing at all, after that I stopped > using it . as pretty pointless to use something that MUST be > reliable and have it fail so easily, whatever caused it IMHO of course > ; I think mine was in the Vault VM > Which Keepass? On debian: user@host:~$ apt-cache search keepass keepass2 - Password manager keepass2-doc - Password manager - Documentation keepassx - Cross Platform Password Manager kpcli - command line interface to KeePassX password manager databases libfile-keepass-perl - interface to KeePass V1 and V2 database files I ask because I have been using keepassx for three or four years with only two databases. I keep multiple copies on different storage devices and I have had only one copy ever become corrupt, but it was the fault of the usb device. I use keepassx and kpcli with pleasure. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/92461c9e-a320-196b-8f8b-d57670264ca0%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Copying between VMs from dom0
wordswithn...@gmail.com: > On Wednesday, June 28, 2017 at 10:07:04 AM UTC-4, qubenix wrote: >> qubenix: >>> wordswithn...@gmail.com: >>>> I want to copy network connection profiles from sys-net to >>>> sys-net-profiles as my computer shuts down. >>>> >>>> I'm creating a bash script in dom0 to help with this. >>>> >>>> I could use >>>> >>>> qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles >>>> /etc/NetworkManager/system-connections/*" >>>> >>>> ...but that will spawn a dom0 confirmation dialogue that I'd rather avoid >>>> (after all, dom0 is initiating the copy). >>>> >>>> I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I >>>> don't want to trust sys-net to initiate this copy on its own. >>>> >>>> Is there any way to directly copy files from one VM to another, executed >>>> directly from dom0? >>>> >>> >>> Not sure if it's the best solution, but this should work for avoiding >>> prompt (briefly tested): >>> >>> for i in $(qvm-run -a -p -u root sys-net "ls >>> /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root "cat >>> /etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm >>> sys-net-profiles $i; done >>> >> >> Oops small typo (forgot to name "sys-net" one time). Fixed: >> >> for i in $(qvm-run -a -p -u root sys-net "ls >> /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root >> sys-net "cat /etc/NetworkManager/system-connections/$i" > $i; >> qvm-move-to-vm sys-net-profiles $i; done >> >> -- >> qubenix >> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 > > How much of a risk do you think this is, passing the file contents through > dom0 via qvm-run -ap? > Yeah, this is moderately secure IMHO. You are copying everything from /etc/NetworkManager/system-connections dir to dom0 before being moved to destination vm without check. So theoretically something malicious could be placed there. However, I don't see how it would be executed in dom0 (should the file be malicious). I took no consideration for security, only to solve the problem of prompt. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/5eef3931-4ff7-3f87-22f0-450353c8b47f%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Copying between VMs from dom0
qubenix: > wordswithn...@gmail.com: >> I want to copy network connection profiles from sys-net to sys-net-profiles >> as my computer shuts down. >> >> I'm creating a bash script in dom0 to help with this. >> >> I could use >> >> qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles >> /etc/NetworkManager/system-connections/*" >> >> ...but that will spawn a dom0 confirmation dialogue that I'd rather avoid >> (after all, dom0 is initiating the copy). >> >> I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I don't >> want to trust sys-net to initiate this copy on its own. >> >> Is there any way to directly copy files from one VM to another, executed >> directly from dom0? >> > > Not sure if it's the best solution, but this should work for avoiding > prompt (briefly tested): > > for i in $(qvm-run -a -p -u root sys-net "ls > /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root "cat > /etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm > sys-net-profiles $i; done > Oops small typo (forgot to name "sys-net" one time). Fixed: for i in $(qvm-run -a -p -u root sys-net "ls /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root sys-net "cat /etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm sys-net-profiles $i; done -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/f9639ac1-bbcf-bd7a-5cb5-01edf539ad11%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Copying between VMs from dom0
wordswithn...@gmail.com: > I want to copy network connection profiles from sys-net to sys-net-profiles > as my computer shuts down. > > I'm creating a bash script in dom0 to help with this. > > I could use > > qvm-run -ap sys-net "sudo qvm-copy-to-vm sys-net-profiles > /etc/NetworkManager/system-connections/*" > > ...but that will spawn a dom0 confirmation dialogue that I'd rather avoid > (after all, dom0 is initiating the copy). > > I could "allow" qubes.Filecopy from sys-net -> sys-net-profiles, but I don't > want to trust sys-net to initiate this copy on its own. > > Is there any way to directly copy files from one VM to another, executed > directly from dom0? > Not sure if it's the best solution, but this should work for avoiding prompt (briefly tested): for i in $(qvm-run -a -p -u root sys-net "ls /etc/NetworkManager/system-connections/"); do qvm-run -a -p -u root "cat /etc/NetworkManager/system-connections/$i" > $i; qvm-move-to-vm sys-net-profiles $i; done -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/624a9c33-920e-412b-9b95-62351ce4825b%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Can't install windows-tools, following docs.
17:24]i410: Variable:
WixBundleOriginalSourceFolder = D:\
[0AA0:0AA4][2017-06-25T18:17:24]i410: Variable: WixBundleProviderKey =
{893ba9c4-6627-45b2-adb5-52faf393dccc}
[0AA0:0AA4][2017-06-25T18:17:24]i410: Variable:
WixBundleRollbackLog_qubes_tools_WIN7x64_3.2.2.3.msi =
C:\Users\IEUser\AppData\Local\Temp\Qubes_Windows_Tools_3.2.2.3_20170625181436_1_qubes_tools_WIN7x64_3.2.2.3.msi_rollback.log
[0AA0:0AA4][2017-06-25T18:17:24]i410: Variable: WixBundleTag =
[0AA0:0AA4][2017-06-25T18:17:24]i410: Variable: WixBundleVersion = 3.2.2.3
[0AA0:0AA4][2017-06-25T18:17:24]i007: Exit code: 0x1, restarting: No
```
--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
--
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/ebb549fb-40d2-b9f3-eded-01a55e3e34fa%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Xen high CPU usage, but nothing is running in the VM
'Vincent Adultman' via qubes-users: > This happens to me sometimes on the current Xen/Linux versions. When I > look at top in the offending VM its "kswapd" that has gone berserk. > > -- > > Chris Laprise, tas...@openmailbox.org > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > -- > I can confirm I've also experienced this with kswapd in either sys-net or > sys-firewall, can't remember which. Only way around it I found was to reboot > the VM. > I have also experience with kswapd going crazy in a Debian vm with intense I/O and CPU. Kswapd persisted to rock the cpu even after all the software was done, for about 10 minutes, until I shutdown the vm. Seems to be a rare condition though because I experience it only 1/50 times with this vm. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/76474d76-e39b-9ea0-83e6-77a81cc2538e%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL MSI Mobo, Intel CPU
Hardware: MOBO: MSI Z170I Gaming Pro AC LGA 1151 MS-7980 CPU: Intel 6th Gen Skylake i7-6700K TPM: MSI 914-4136-103 dTPM 1.2 RAM: G.Skillz Ripjaws V DDR4 2400 --- Notes: - AEM works. - Have to switch boot order, take out "UEFI" options. - No sys-net nm-applet after firstboot. On next boot applet was there. --- Attached are the reports. Support report is encrypted to Qubes Devs: ADW, JR, and MM. Thank you to all devs and everyone on this list. My favorite host OS and a very helpful community. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/2babbd44-ffb5-efdc-93b4-f4262629dea2%40riseup.net. For more options, visit https://groups.google.com/d/optout. -BEGIN PGP MESSAGE- hQIMAyyYz3tWP+oNAQ/+M7zYuSE9fMAn/VLngzNOC0pDpfPSX2jFj/LhrrbsXJzz mqSKV034otweFDnRx1hFNfQT68xfFSJwmPUJKvBf2pxOtZyGRaK4pdOgWGgq1nO7 m/nRiMCmX5HcuAeB9F+6jyOR2oK8YObK3X3L/xd5g0EfWAe1V42pqPTTkvhmGp5h xHi5FFgp7ayIPg+W44o7gdIsoAYGKmnJiaW/p+JiFvX7KdvjH2C1DKYshtJdGHxI LNI7a9Nu15DdpFJHlVyTWgdcka0D5Lxy4fzvx7poQgNvMBZ0ZhR1YYgAdlHwoume CGE9pCM1iLYCZkzX9vgbEaOWvmazryyo4cxbUW1+9eFUSWGUhz+KwM8Js7R42sfh RiKIYP0CiyB3nzAf0telDfLut2eT8t6SA1w/VHQRGkot4aXftSCKhs4gXV0jYA+N 2AIZIhq78/ou2N+5hC282i9NofF4ZJJyj2A30RQJ/mSPeitN2hPcj2lwNhTQ8P3U eKJr6vcD4j8AZMVSJkzzvAC7ZY6pnZ/JV2r5wbS+ZDG9NnmnxpoURbWmF2OdaElB LDxFJblQBIaOlzsj5KmSVH94fcbaNhZHxaWBTvlDWDIC/vPmGFYzcu1HEiU/aQYz l99xsZyM8pvKnktmYsjORLaEUuvNyGDcawoMxABgvrqKRyxW+qeDpHRfyh0G8ASF AQwDqH2PP4A1NFQBCACh69jOT11gJaZxRaZkE3K3RXmJhqx+YF3pQKo+BqdIHZMd DMIUmFTavuUl1jFpYjght/VWpUubSYP4t9YesobsihJKzdbvMfMa8BKCS295qUX6 oHwqkSW4wA6f2JgLSo4LpYeks5QomY4i1nPsGBlqu37y0LiaTQI7/rkyLhIjw0/V 5GInTTcFLEUye7ozPBOPfze41F5rTYlEpiYDyOyItOtx50MtjO5Cudx+vRilPj6C FkmaKxvsQf0jINfOcSYXYcvpfWVSUNwxsZF2AXg4tU/zH+4vzsBD9Y5GyDomZYng Sv2yAJD2PN05nTC7UuE2M7Ez1guN01k4kM0g9F0xhQIMA908wW+lbEkbARAA4f60 s+Db6oJjQ+exNklJUW7UnG5EATtTx9aiS8DBu0DBNW4jxObGOWFhcRxJ4HPbR79F MYQt0fLhHlidGIcaMQ2ZhWNpXvDL7BsdF7XXKjcXn4CEMHD8dNJ/F5Vw81MuAHLH FVoNiYzayxEAJfKuNqmnCVfoTs4W+z0fXKRLhmq+MTV2V+IgGk9+dmLWKr+5QXhO WParx7DmfvGvVXTfpxR1y19N9TduSc2CdXBbH6oFrXBKatXdnSbCWpKLvWRvkwgY f+2ebK8v/zGGF3xxRt/KZAaGHSNjMB+Sc+KTkkPxyO1w7OxOfmRwwVKXa6BbHIMA fs46aLBo1rLSQlfhFpAQOcIv2PUtWr9kptaVirX59zobEXyhlyx3OLhqiZsa2a3n bvbonh8GZuR9bxHyYsBCF3/yJz20v5FsBtEO6uAz623JWNh83v3bIzZZdP0P6++4 +N74grZXm/Im6fShCmsERz4zhZY4dRcsdaWNTPHosaNVopUfYMyYC/97VJdkH7sB K4OjIQMXN8Iu/YBtT+746ehO4SScHTEeG1YGOISHUtJDLCfT9uDcznKygUsTb7Lk G+94D6VHt4DDFkcPoLbBMiBbbTvLE1DtbjUSsE/fmGscb+l3dItaKJ2qWyvAkgvc uQPYfNo+wNG1c5U7MCeBEyGtfLUbjIE02C8yHRHS/wAAJwwBT1pVMaf0jyVblSxR AccJYgo+MtF5eQoXVowNwqUGjGX8OxPiaaK/MqUFdhhXqaYr6nSajKNT5BTmXakK dIjqgO5B0oIZOJwJDYme3LK/jWPQ023ntBs1YkkNXjDv71m2HBZ06AvOYvZ99cb5 74yCtszu+HCin2tGbjq+I29DmODWi2+caXiHkW/+4rNWTEKFm5aLf1ZrWKV57Rac K87+F2Og+P3qfjBOnIMjVSu5maiQZC3PIhm0d75Zn05Ugzre+Xk++7yVbbb6I9RY SPBTwTmk9QCZSpHVeQ5I6qRZVGJHEgO0ZHDJeSszhyB8RfSQ87XcFD6w+c5W6McJ 9uAYXHNEWpm2MmFQVQR41lQsJaVA2P2h2sA91RIdRbAIfJTnOYueHMS3N+hnLwJl Pa2yIolRkCK+5CEoLTtjep1eCq6nVeH0KiGwHEzrAbJ8snFR3ozkciCQgvFogUFY M0uzumFI/YPRk6lMY1TEm+T7jPrmDt8T/Qc9I5LL4k/9Kx7uj1O8tch42ltp8wuy iOdSANj8jXzWZqHg6zX/YHPvO6zRcwl53UXK/6nZIJo63wDUlHXto+N9px1OnnFK b4sm/NzZhcmzl2TGoY9vNSQ+tK9oOjBmFSwKjH8dtyT9fbzpZHHfiTO6z8DK7SgK CH1K0vyIqXKeH5yT41wd08hi/r15NZsrkyCwShLfYClE1wNM8j2GYrEhh4G0od8x Tp8mAjD2z7eF2pPWL5FWAfixTsUB3JuYLQdK2X/2OLDPxUDrfXJ7YMQWWGgZ/kP/ +Z+3zMfLDfQtDQZ9OqxyAtMyVon5/+j8bte883lDfB1elGtJ7jb18CPcdvzITq++ +Df2N5Z8y+ErqT7kvCIkDgVvvLV4DByY+uwYcvZd/Zw/yQGIOwAUbUQl7fgTla0W kP4Ma8Fs0Iqi1uYPSrgwSnaYi1nFKpgURDSN8vuz/hhc9SJF1LXbBlUYH351owv4 bKOY/ddZzP5nN2rzoegXwGNIhssqciKFtGXew+DxMX7w7BTa0n/qv31e+BbE1ywh 4Ap4ONeJdu9igm7JgM9R6xxaegRsHab6bWwfzfwQzE08cWbpR1hhMUGTuY1osYIS IUSKirpEHlmBqbs5eqiPNuzwDNXcRBvgD2lF0sMx5VvsI/P5FFju9ELVTSslY3Pg gJqVeDODybX0eBJahqxqnktx58YwqCnvTmFRNcxFmOP9JMyRlXbCKlBC600FbUov 8DWypnAEAwlpnFXUX8oNAgOdoaWvXhghJpx1LFVZBYhly0pjpTpbQuWzxrySkfj7 icxXifJno2EUFTYeNjjSWFPxpOQVLqQZg4vVkakLHbDG+qv2kKjjMYVZivqwzcUU ENf4+nl3b03qo0tC5hpfdha0qsYhmb422ar0fWRrJxSfTaY7AGpvicDjzIRQMblS Yry3jvEAn2uS+t7adX4K+/lsgz/JB8hWw8rHlqkLL0GN1BU07RSv+fxnAzHeR3So 4IBhZBPHrCJ4UiaBfgb2vInrEqh8meXU6bWt+H4dx1LUu2q2npv3pgOsQpHKopwM FtumI39wxThO0xW9se9PEPyg+uSXbIKHCChH9OcSb+Ki0jUv6FXxden+RLitOr1d A9mx4H/i8FMX6ztp2TtXhz+Aq52yy/7e9v5GGXj8gh/zs1JzuPK84eceLw5CSCjK KuinzWl5AyAXnY/a1kPHY33rijP59F48CCRBwZSHnQDrpwpxDZg15/ySXom+Jvqv V0duDtts7XedGV2wjfASEfqoGAuRuyx45fcBVlxJ+a+tqg+98J59jFUk1rFKbS+M VHwZYvqlrsgH1jI7NC2UsB+rz7U/CM7y/Ox39sAGd+2gS32uEVOc/yEaa7JWok6F ja43e+j9GLmlDrdS8eN/G6O3iHu4okZYiVYS1ogJA/hG16ZZgRtu3fBpntEn4QUz 1/a0FuCGCYeOh3YvU+2XBtXkXixvYWd3emJEDewPVdpsm7gMGqCtJ+0CtAjC7n4B rZASSsICwLwi1bvH1X1V3WR1XWdLI+l7rXtB2bvLMyTK
Re: [qubes-users] Anyone got a intel z270 motherboard to work with Qube os
carrefamilyhomes...@gmail.com: > On Saturday, June 10, 2017 at 8:35:52 PM UTC-4, qubenix wrote: >> carr...@gmail.com: >>> Hi, >>> >>> My motherboard broke and I need to rebuild my computer. I am looking to get >>> something that will last forever and has all the bells and whistles. I am >>> currently looking at the Asus prime >>> z270-K(https://www.newegg.com/Product/Product.aspx?Item=N82E16813132938=1). >>> Has anyone gotten qube os to work on this board? >>> >>> Has anyone gotten qube os on any z270? Any help would be really >>> appreciated. >>> >> >> I just built a rig around z170 board. Everything is working fine so far. >> I'll be doing an HCL once my tpm module arrives. >> >> -- >> qubenix >> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 > > Which model motherboard? What is HCL? > It is a MSI Z170I Gaming Pro AC Mini-ITX (MS-7980). HCL is hardware compatibility list: https://qubes-os.org/hcl. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/68878165-6f5e-5697-a710-e1885176aed2%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anyone got a intel z270 motherboard to work with Qube os
carr...@gmail.com: > Hi, > > My motherboard broke and I need to rebuild my computer. I am looking to get > something that will last forever and has all the bells and whistles. I am > currently looking at the Asus prime > z270-K(https://www.newegg.com/Product/Product.aspx?Item=N82E16813132938=1). > Has anyone gotten qube os to work on this board? > > Has anyone gotten qube os on any z270? Any help would be really appreciated. > I just built a rig around z170 board. Everything is working fine so far. I'll be doing an HCL once my tpm module arrives. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/5d28c161-a54b-178a-c301-ec9ea90bad80%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: "root=/dev/mapper/dmroot crashed"
devr...@gmail.com:
> Hmm. Two devices with the same major:minor numbers? /dev/mapper/dmroot &
> /dev/dm-0
>
> /dev/mapper/dmroot does not appear in Dom0, nor does any error appear in
> journalctl. I do find that device in sys-{net,firewall,whonix,usb} and in
> those cases it always appears as:
>
> ls -l /dev/mapper/dmroot
> brw-rw 1 root disk 251, 0 May 13 20:11 /dev/mapper/dmroot
>
> lsblk /dev/xvdc
> NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
> xvdc 202:32 1 11.5G 0 disk
> ├─xvdc1202:33 11G 0 part [SWAP]
> └─xvdc2202:34 1 10.5G 0 part
> └─dmroot 251:00 10G 0 dm /
>
> In each of these VM's I find only one error related to dmroot. On a single
> bootup (but not subsequently) and in all the VM's:
>
> May 13 02:56:21 fedora-25 systemd-udevd[7757]: conflicting device node
> '/dev/mapper/dmroot' found, link to '/dev/dm-0' will not be created
>
> In all those VM's I also find:
>
> ls -l /dev/dm-0
> brw-rw 1 root disk 251, 0 May 13 20:11 /dev/dm-0
>
> Notice the same major:minor numbers as /dev/mapper/dmroot
>
I'm also getting this error from my usb vm on startup. It has a Fedora24
template. The template is untouched from initial Qubes install, aside
from updates via qubes-vm-r3.2-current-testing repo.
For me the issue just started today for no obvious reason.
--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
--
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/f04ec9b9-7990-5aa8-3e10-3008c836a208%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Onion site stuck in redirect loop
his page (maybe more?): http://qubesos4z6n4.onion/doc/firewall/ gets stuck in a redirection loop. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/68566c1c-b22e-74fd-4dfd-82d1545c9a85%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
Reg Tiangha: > On 04/15/2017 01:06 PM, qubenix wrote: >> peter...@hushmail.com: >>> Is there a script to randomize hostname on each boot? >>> >> I think blank hostname is better than randomized. How would it be >> randomized: dictionary words, rng, cycling popular hostnames, etc.? Your >> randomization method may make you more identifiable than blank. >> > > Dumb question here, but what's the difference between commenting the > line out of the .conf file vs explicitly setting it with a blank > hostname? Does it not result in the same thing? Or does simply > commenting it out still risk sending out a hostname of some kind in some > circumstances? > > I've got it commented out and it has always been blank on my tests. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/cd0a1ea0-6cfe-c28a-fc9a-728b2c800f4f%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
peter...@hushmail.com: > > Is there a script to randomize hostname on each boot? > I think blank hostname is better than randomized. How would it be randomized: dictionary words, rng, cycling popular hostnames, etc.? Your randomization method may make you more identifiable than blank. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/f15d3d7e-cf63-f094-6a9e-dd5872dedb04%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
cooloutac: > On Wednesday, April 12, 2017 at 10:55:08 AM UTC-4, qubenix wrote: >> Unman: >>> On Tue, Apr 11, 2017 at 06:20:38AM -0700, Dominique St-Pierre Boucher wrote: >>>> On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote: >>>>> qubenix: >>>>>> Andrew David Wong: >>>>>>> On 2017-04-09 15:25, Joonas Lehtonen wrote: >>>>>>>> Hi, >>>>>>> >>>>>>>> if you setup MAC randomization via network manager in a debian 9 >>>>>>>> template as described here: >>>>>>>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/ >>>>>>>> you still leak your hostname. >>>>>>> >>>>>>>> Once your MAC address is randomized you might also want to prevent the >>>>>>>> disclosure of your netvm's hostname to the network, since "sys-net" >>>>>>>> might be a unique hostname (that links all your random MAC addresses >>>>>>>> and >>>>>>>> the fact that you likely use qubes). >>>>>>> >>>>>>>> To prevent the hostname leak via DHCP option (12): >>>>>>>> - start the debian 9 template >>>>>>>> - open the file /etc/dhcpd/dhclient.conf >>>>>>>> - in line number 15 you should see "send host-name = gethostname();" >>>>>>>> - comment (add "#" at the beginning) or remove that line and store the >>>>>>>> file >>>>>>>> - reboot your netvm >>>>>>> >>>>>>>> I tested the change via inspecting dhcp requests and can confirm that >>>>>>>> the hostname is no longer included in dhcp requests. >>>>>>> >>>>>>> >>>>>>> Thanks. Added as a comment: >>>>>>> >>>>>>> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628 >>>>>>> >>>>>>> >>>>>> >>>>>> Nice. I was just thinking about this after spending some time on my >>>>>> routers interface. Thanks for the post! >>>>>> >>>>> >>>>> After testing this, 'sys-net' still shows up on my router interface. >>>>> >>>>> -- >>>>> qubenix >>>>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 >>>> >>>> Did the same test and got the same result. >>>> >>>> Anyone has a solution? I can always change my hostname for something else, >>>> but I would prefer not sending the hostname or finding a way to randomize >>>> it!!! >>>> >>>> Dominique >>>> >>> >>> Strange, because those instructions are standard for removing the >>> hostname - I set it as blank, rather than commenting out. If you sniff >>> the traffic you will see that the hostname is indeed no longer sent. >>> >>> Why is it on your router interface? >>> My guess is that your router is returning the hostname that it has >>> associated with the MAC address. I've seen this happen when changing >>> hostname, and the DHCP server returns the *old* hostname as part of >>> the DHCP exchange. If you reboot the router and test again, you may find >>> that the issue goes away. >> >> Confirmed. Router was "guessing" that I was 'sys-net', but not from MAC >> (which is randomized). I believe it was using process of elimination >> based on stored device hostnames (this is not public, devices are pretty >> static). Since restarting the router, it give my pc the hostname of a >> device which connected automatically to it (the only one it had to >> "guess" from). >> >>> >>> You could, of course, set a random hostname from rc.local on each boot of >>> sys-net. >>> >>> unman >>> >>> >> >> >> -- >> qubenix >> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 > > But why use dhcp if its a static home connection? I feel that is a security > risk for other reasons and always disable it. > I haven't looked into the security risk for dhcp connection. I intend to look into it and adjust accordingly. Thanks for the suggestion. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/bb62f68f-75e4-677d-462d-44b0872d72ec%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
Unman: > On Tue, Apr 11, 2017 at 06:20:38AM -0700, Dominique St-Pierre Boucher wrote: >> On Monday, April 10, 2017 at 5:06:30 PM UTC-4, qubenix wrote: >>> qubenix: >>>> Andrew David Wong: >>>>> On 2017-04-09 15:25, Joonas Lehtonen wrote: >>>>>> Hi, >>>>> >>>>>> if you setup MAC randomization via network manager in a debian 9 >>>>>> template as described here: >>>>>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/ >>>>>> you still leak your hostname. >>>>> >>>>>> Once your MAC address is randomized you might also want to prevent the >>>>>> disclosure of your netvm's hostname to the network, since "sys-net" >>>>>> might be a unique hostname (that links all your random MAC addresses and >>>>>> the fact that you likely use qubes). >>>>> >>>>>> To prevent the hostname leak via DHCP option (12): >>>>>> - start the debian 9 template >>>>>> - open the file /etc/dhcpd/dhclient.conf >>>>>> - in line number 15 you should see "send host-name = gethostname();" >>>>>> - comment (add "#" at the beginning) or remove that line and store the >>>>>> file >>>>>> - reboot your netvm >>>>> >>>>>> I tested the change via inspecting dhcp requests and can confirm that >>>>>> the hostname is no longer included in dhcp requests. >>>>> >>>>> >>>>> Thanks. Added as a comment: >>>>> >>>>> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628 >>>>> >>>>> >>>> >>>> Nice. I was just thinking about this after spending some time on my >>>> routers interface. Thanks for the post! >>>> >>> >>> After testing this, 'sys-net' still shows up on my router interface. >>> >>> -- >>> qubenix >>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 >> >> Did the same test and got the same result. >> >> Anyone has a solution? I can always change my hostname for something else, >> but I would prefer not sending the hostname or finding a way to randomize >> it!!! >> >> Dominique >> > > Strange, because those instructions are standard for removing the > hostname - I set it as blank, rather than commenting out. If you sniff > the traffic you will see that the hostname is indeed no longer sent. > > Why is it on your router interface? > My guess is that your router is returning the hostname that it has > associated with the MAC address. I've seen this happen when changing > hostname, and the DHCP server returns the *old* hostname as part of > the DHCP exchange. If you reboot the router and test again, you may find > that the issue goes away. Confirmed. Router was "guessing" that I was 'sys-net', but not from MAC (which is randomized). I believe it was using process of elimination based on stored device hostnames (this is not public, devices are pretty static). Since restarting the router, it give my pc the hostname of a device which connected automatically to it (the only one it had to "guess" from). > > You could, of course, set a random hostname from rc.local on each boot of > sys-net. > > unman > > -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/9245f24a-f51e-1ea8-10d1-55d92abfd6c8%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
qubenix: > Andrew David Wong: >> On 2017-04-09 15:25, Joonas Lehtonen wrote: >>> Hi, >> >>> if you setup MAC randomization via network manager in a debian 9 >>> template as described here: >>> https://www.qubes-os.org/doc/anonymizing-your-mac-address/ >>> you still leak your hostname. >> >>> Once your MAC address is randomized you might also want to prevent the >>> disclosure of your netvm's hostname to the network, since "sys-net" >>> might be a unique hostname (that links all your random MAC addresses and >>> the fact that you likely use qubes). >> >>> To prevent the hostname leak via DHCP option (12): >>> - start the debian 9 template >>> - open the file /etc/dhcpd/dhclient.conf >>> - in line number 15 you should see "send host-name = gethostname();" >>> - comment (add "#" at the beginning) or remove that line and store the file >>> - reboot your netvm >> >>> I tested the change via inspecting dhcp requests and can confirm that >>> the hostname is no longer included in dhcp requests. >> >> >> Thanks. Added as a comment: >> >> https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628 >> >> > > Nice. I was just thinking about this after spending some time on my > routers interface. Thanks for the post! > After testing this, 'sys-net' still shows up on my router interface. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/e43a76ea-eba3-9aba-f127-eec495a7fcee%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] for people using MAC randomization (debian 9 tmpl): you might want to avoid hostname leaks via DHCP too
Andrew David Wong: > On 2017-04-09 15:25, Joonas Lehtonen wrote: >> Hi, > >> if you setup MAC randomization via network manager in a debian 9 >> template as described here: >> https://www.qubes-os.org/doc/anonymizing-your-mac-address/ >> you still leak your hostname. > >> Once your MAC address is randomized you might also want to prevent the >> disclosure of your netvm's hostname to the network, since "sys-net" >> might be a unique hostname (that links all your random MAC addresses and >> the fact that you likely use qubes). > >> To prevent the hostname leak via DHCP option (12): >> - start the debian 9 template >> - open the file /etc/dhcpd/dhclient.conf >> - in line number 15 you should see "send host-name = gethostname();" >> - comment (add "#" at the beginning) or remove that line and store the file >> - reboot your netvm > >> I tested the change via inspecting dhcp requests and can confirm that >> the hostname is no longer included in dhcp requests. > > > Thanks. Added as a comment: > > https://github.com/QubesOS/qubes-issues/issues/938#issuecomment-292843628 > > Nice. I was just thinking about this after spending some time on my routers interface. Thanks for the post! -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/913fb528-2469-976e-4e2c-2c276864727c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Pandavirtualization: Exploiting the Xen hypervisor
Wondering if the list has seen this yet: https://googleprojectzero.blogspot.com/2017/04/pandavirtualization-exploiting-xen.html PoC on Qubes 3.2. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/9c3e200b-1044-d1a8-9075-3779e110503f%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes manager not showing changes, etc.
Since the upgrade to version 3.2.8-1.fc23 of qubes manager I've been having some issues. 1. Changes made to existing VMs or newly created VMs do not show in the manager until I restart Qubes. Restarting only the manager does not help. 2. I have very often yellow state indicators while the VM is running. `qvm-ls` shows state as "Running" and everything works normal in the VM during yellow indicator. Restarting the VM usually fixes this issue. I've noticed that this happens more often when I have many VMs starting together, but not dependant on each other (to rule out race condition of two VMs trying to start same proxy vm for example). It seems others were having these issues before the upgrade, and since I haven't noticed any complaints. My experience was the opposite. I had no issues previous to this upgrade. Please let me know any other info/logs that may be helpful. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/13162574-5746-58bf-7171-9658834d10b1%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Kali TemplateVM terminal etc. do not open
Bernd Kohler: > Hi @ all, > > I made a clone of my debian-8 TemplateVM, renamed it and replaced the > apt-sources with the kali-ones. After that I installed some kali- > paket-groups. > > Everything was fine until last week. After some updates I could start the > TemplateVM but wasn't able to start/run any programm > > For example opening a Gnome terminal does not work. > > In case someone here has the solution I am very interested, but giving me a > hint, where and how to debug will make me happy too ;) > > thx and regards > > Bernd > > > See here for details: https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com In short you need to: - Change qubes repo to `stretch-testing` - update and dist-upgrade your template If you run into problems, all the answers should be in that thread I linked. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/68bffa26-b1e3-2b33-3140-2f08995a896a%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: debian-9 sys-net, random MAC buggy
Chris Laprise: > On 12/15/2016 01:58 PM, Reg Tiangha wrote: >> On 12/15/2016 11:50 AM, qubenix wrote: >>> I've used the docs[1] to randomize my MAC on sys-net with debian-9 as >>> it's template. At first everything was working normal, but I've noticed >>> now that my MAC is only randomized until I connect to a network. At that >>> point it switches back to the original MAC. Anyone else experiencing >>> this? >>> >>> Second issue is that it seems my eth0 is never randomized. Any users >>> with the same experience? >>> >>> [1] https://www.qubes-os.org/doc/anonymizing-your-mac-address/ >>> >> I've had that happen ever since I tried it so I just assumed it was a >> bug or a hardware issue that doesn't allow my wifi adapter to change. If >> there's a workaround or an extra package to install to make it work >> properly, I'd love to hear it. I get the same issue with NM on Debian 9 >> or Fedora 25, as well as the macchanger method. It does scramble the MAC >> address when it's not connected to an access point, but reverts to the >> original one once it connects to a network. > > > The main issue here is that the correct config keyword > "cloned-mac-address" reverted to an incorrect (non-)keyword > "assigned-mac-address" that was used in an earlier version (see > https://github.com/tasket/qubes-doc/commit/27dcc6f142d627293d7788cbd5610b4f6b4f2df5 > ). > > Somehow this got changed back to the original, mistaken keyword here: > https://github.com/QubesOS/qubes-doc/commit/a9a82bedf092eec13e774dc50cbc6f83f0ef2182 > > > The "assigned-mac-address" is a property for NM's dbus interface ...not > in the config parser where "cloned-mac-address" is used (see gnome.org > link below). > > -- > > With that said, there is an actual NM bug where it ignores randomization > settings when connecting to an AP. This bug bit me and the workaround > was to use a newly-created netVM instead of existing one so that old NM > connection data was not present in the new configuration. That's why the > instructions say to create a new netVM. > > https://mail.gnome.org/archives/networkmanager-list/2016-October/msg00019.html > > > > Chris > Ah, that was my mistake/commit. I apologize, I did not see this documented before. Thank you for helping me to realize this confusing situation. The worst part, really, is that the only place in the man pages where random vs. stable is documented is in the section that specifies that `cloned-mac-address` is deprecated!?! It would be really nice if this were also doc'd in the `keyfile` or `ifcfg` pages. So now the Qubes docs have to point to a page that is going to recreate this situation over again. Relevant NetworkManager doc pages: https://developer.gnome.org/NetworkManager/1.4/nm-settings.html https://developer.gnome.org/NetworkManager/1.4/nm-settings-keyfile.html https://developer.gnome.org/NetworkManager/1.4/nm-settings-ifcfg-rh.html -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/73d2e3f7-3552-74e9-0a66-763ef72287e3%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template (and sub-vms) non interactive after package updates
Boris Kourtoukov: > On Tuesday, December 13, 2016 at 3:11:12 PM UTC-5, qubenix wrote: >> Boris Kourtoukov: >>> On Tuesday, December 13, 2016 at 2:49:23 PM UTC-5, qubenix wrote: >>>> Boris Kourtoukov: >>>>> This is similar to what happened with the Whonix discussion here: >>>>> https://groups.google.com/d/msg/qubes-users/IHhxklnCpYc/Wj2K5euVBAAJ >>>>> >>>>> I am getting to this point: >>>>> >>>>> ``` >>>>> ... >>>>> Waiting for VM's qrexec agent...connected >>>>> --> Starting Qubes GUId... >>>>> Connecting to VM's GUI agent: .connected >>>>> --> Sending monitor layout... >>>>> --> Waiting for qubes-session... >>>>> ``` >>>>> >>>>> And then it waits forever. Attempting to open an app in any of the sub >>>>> VMs fails with no (visual) feedback. >>>>> >>>>> The Debian TemplateVM starts and runs. And if I get into it via: >>>>> >>>>> `virsh -c xen:/// console debian-9` >>>>> >>>>> I am able to run commands as root. >>>>> >>>>> Unfortunately doing a dist-upgrade and checking for broken/unmet >>>>> dependencies resulted in nothing (dist-upgrade updated 0 packages.) >>>>> Everything appears to be installed correctly. >>>>> >>>>> (I did a check with `debsums --changed` as well. it came up empty.) >>>>> >>>>> Any thoughts on what else to debug? >>>>> >>>> >From this discussion: >>>> https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com >>>> >>>> Start your template from gui or dom0 cli as you did. When you get to: >>>> >>>>> --> Waiting for qubes-session... >>>> >>>> `Ctrl-c` to stop the endless wait you described. Then (still from dom0) do: >>>> >>>> qvm-run -p -u root debian-9 "apt-get update && apt-get install -t >>>> stretch xserver-xorg-core -y && apt-get dist-upgrade -y" >>>> >>>> Restart your template and see that you get display again, should fix it. >>>> >>>> -- >>>> qubenix >>>> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 >>> >>> It said the package was already at latest version. I proceeded to >>> `--reinstall` it and still no luck. Still sticks on waiting for >>> qubes-session. >>> >> What version do you have installed? >> >> -- >> qubenix >> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 > > 2:1.19.0-2 > Ah, I think you need the repo `stretch-testing` from qubes. So do: qvm-run -u root debian-9 'echo "deb [arch=amd64] http://deb.qubes-os.org/r3.2/vm stretch-testing main" >> /etc/apt/sources.list.d/qubes-r3.list' qvm-run -p -u root debian-9 "apt-get update && apt-get dist-upgrade -y" Hopefully that will fix it. Sorry I forgot the repo had to be changed. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/d7d454fc-b75e-4670-0fa4-b1816e77b398%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template (and sub-vms) non interactive after package updates
Boris Kourtoukov: > On Tuesday, December 13, 2016 at 2:49:23 PM UTC-5, qubenix wrote: >> Boris Kourtoukov: >>> This is similar to what happened with the Whonix discussion here: >>> https://groups.google.com/d/msg/qubes-users/IHhxklnCpYc/Wj2K5euVBAAJ >>> >>> I am getting to this point: >>> >>> ``` >>> ... >>> Waiting for VM's qrexec agent...connected >>> --> Starting Qubes GUId... >>> Connecting to VM's GUI agent: .connected >>> --> Sending monitor layout... >>> --> Waiting for qubes-session... >>> ``` >>> >>> And then it waits forever. Attempting to open an app in any of the sub VMs >>> fails with no (visual) feedback. >>> >>> The Debian TemplateVM starts and runs. And if I get into it via: >>> >>> `virsh -c xen:/// console debian-9` >>> >>> I am able to run commands as root. >>> >>> Unfortunately doing a dist-upgrade and checking for broken/unmet >>> dependencies resulted in nothing (dist-upgrade updated 0 packages.) >>> Everything appears to be installed correctly. >>> >>> (I did a check with `debsums --changed` as well. it came up empty.) >>> >>> Any thoughts on what else to debug? >>> >> >From this discussion: >> https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com >> >> Start your template from gui or dom0 cli as you did. When you get to: >> >>> --> Waiting for qubes-session... >> >> `Ctrl-c` to stop the endless wait you described. Then (still from dom0) do: >> >> qvm-run -p -u root debian-9 "apt-get update && apt-get install -t >> stretch xserver-xorg-core -y && apt-get dist-upgrade -y" >> >> Restart your template and see that you get display again, should fix it. >> >> -- >> qubenix >> GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 > > It said the package was already at latest version. I proceeded to > `--reinstall` it and still no luck. Still sticks on waiting for qubes-session. > What version do you have installed? -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/6b8485a8-2ea7-4e92-3ca5-b84851d8d5a0%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template (and sub-vms) non interactive after package updates
Boris Kourtoukov: > This is similar to what happened with the Whonix discussion here: > https://groups.google.com/d/msg/qubes-users/IHhxklnCpYc/Wj2K5euVBAAJ > > I am getting to this point: > > ``` > ... > Waiting for VM's qrexec agent...connected > --> Starting Qubes GUId... > Connecting to VM's GUI agent: .connected > --> Sending monitor layout... > --> Waiting for qubes-session... > ``` > > And then it waits forever. Attempting to open an app in any of the sub VMs > fails with no (visual) feedback. > > The Debian TemplateVM starts and runs. And if I get into it via: > > `virsh -c xen:/// console debian-9` > > I am able to run commands as root. > > Unfortunately doing a dist-upgrade and checking for broken/unmet dependencies > resulted in nothing (dist-upgrade updated 0 packages.) Everything appears to > be installed correctly. > > (I did a check with `debsums --changed` as well. it came up empty.) > > Any thoughts on what else to debug? > >From this discussion: https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com Start your template from gui or dom0 cli as you did. When you get to: > --> Waiting for qubes-session... `Ctrl-c` to stop the endless wait you described. Then (still from dom0) do: qvm-run -p -u root debian-9 "apt-get update && apt-get install -t stretch xserver-xorg-core -y && apt-get dist-upgrade -y" Restart your template and see that you get display again, should fix it. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/83dc210c-46ba-348d-5a16-c2d9e02c505a%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Debian Template (and sub-vms) non interactive after package updates
Boris Kourtoukov: > This is similar to what happened with the Whonix discussion here: > https://groups.google.com/d/msg/qubes-users/IHhxklnCpYc/Wj2K5euVBAAJ > > I am getting to this point: > > ``` > ... > Waiting for VM's qrexec agent...connected > --> Starting Qubes GUId... > Connecting to VM's GUI agent: .connected > --> Sending monitor layout... > --> Waiting for qubes-session... > ``` > > And then it waits forever. Attempting to open an app in any of the sub VMs > fails with no (visual) feedback. > > The Debian TemplateVM starts and runs. And if I get into it via: > > `virsh -c xen:/// console debian-9` > > I am able to run commands as root. > > Unfortunately doing a dist-upgrade and checking for broken/unmet dependencies > resulted in nothing (dist-upgrade updated 0 packages.) Everything appears to > be installed correctly. > > (I did a check with `debsums --changed` as well. it came up empty.) > > Any thoughts on what else to debug? > >From this discussion: https://groups.google.com/d/msgid/qubes-users/94997d39-2302-4c94-9aa1-ffee6f639bb1%40googlegroups.com Start your template from gui or dom0 cli as you did. When you get to: > --> Waiting for qubes-session... `Ctrl-c` to stop the endless wait you described. Then (still from dom0) do: qvm-run -p -u root debian-9 "apt-get update && apt-get install -t stretch xserver-xorg-core -y && apt-get dist-upgrade -y" Restart Template and/or AppVMs based from it. That should fix things in your TemplateVM and AppVMs. -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/bac730a1-6e49-0ee2-8b85-b3c84075ae39%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Kali VM no longer responding
qubenix:
> qubenix:
>> Marek Marczykowski-Górecki:
>>> On Mon, Dec 12, 2016 at 05:10:00PM +, qubenix wrote:
>>>> Marek Marczykowski-Górecki:
>>>>> Looks like this issue:
>>>>> https://github.com/QubesOS/qubes-issues/issues/2514
>>>>>
>>>>> Rebuilt package just uploaded to testing repository
>>>>> (qubes-gui-agent_3.2.10-2+deb9u1).
>>>>>
>>>>>
>>>
>>>> Doesn't seem to be fixed in stretch, stretch-testing, or
>>>> stretch-securitytesting yet.
>>>
>>>> ```
>>>> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
>>>> dist-upgrade -y"
>>>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>>>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>>>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>>>> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
>>>> Reading package lists...
>>>> Reading package lists...
>>>> Building dependency tree...
>>>> Reading state information...
>>>> Calculating upgrade...
>>>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>>>> [user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-gui
>>>> ii qubes-gui-agent 3.2.8+deb9u1 amd64 Makes X11 windows available to
>>>> qubes dom0
>>>> ```
>>>
>>> Interesting, I have qubes-gui-agent 3.2.11 already, from
>>> stretch-testing. Do you have some caching proxy in between?
>>>
>> At one point I was using Rustybirds update cache proxy, but I've since
>> switched back to a whonix-gw and unchecked "Allow connections to Updates
>> Proxy".
>>
>> I have two debian-9 templates, and they both were connected to update
>> cache and are now connected to whonix-gw. Here's the results from my two
>> debian-9 templates (one is using stretch-testing and
>> stretch-securitytesting the other has only stretch-testing although I
>> don't think that should matter):
>>
>> ```
>> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
>> dist-upgrade -y -V"
>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
>> Reading package lists...
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Calculating upgrade...
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> [user@dom0 ~]$ qvm-run -p d9-kali "sudo apt-get update && sudo apt-get
>> dist-upgrade -y -V"
>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>> Hit:5 http://deb.bitmask.net/debian stretch InRelease
>> Hit:4 http://archive-3.kali.org/kali kali-rolling InRelease
>> Reading package lists...
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Calculating upgrade...
>> The following packages have been kept back:
>>qubes-gui-agent (3.2.8+deb9u1 => 3.2.11-1+deb9u1)
>> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
>> [user@dom0 ~]$ qvm-run -p d9-kali "sudo aptitude dist-upgrade"
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Reading extended state information...
>> Initializing package states...
>> Building tag database...
>> The following NEW packages will be installed:
>> xserver-xorg-input-qubes{ab} xserver-xorg-video-dummyqbs{ab}
>> The following packages will be upgraded:
>> qubes-gui-agent
>> 1 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
>> Need to get 66.5 kB of archives. After unpacking 36.9 kB will be used.
>> The following packages have unmet dependencies:
>> xserver-xorg-video-dummyqbs : Depends: xorg-video-abi-23 which is a
>> virtual package, provided by:
>> - xserver-xorg-core
>> (2:1.19.0-2), but 2:1.18.4-2 is installed
>>
>>Depends: xserver-xorg-core (>=
>> 2:1.18.99.901) but 2:1.18.4-2 is installed
>> xserver-xorg-in
Re: [qubes-users] Kali VM no longer responding
qubenix:
> Marek Marczykowski-Górecki:
>> On Mon, Dec 12, 2016 at 05:10:00PM +, qubenix wrote:
>>> Marek Marczykowski-Górecki:
>>>> Looks like this issue:
>>>> https://github.com/QubesOS/qubes-issues/issues/2514
>>>>
>>>> Rebuilt package just uploaded to testing repository
>>>> (qubes-gui-agent_3.2.10-2+deb9u1).
>>>>
>>>>
>>
>>> Doesn't seem to be fixed in stretch, stretch-testing, or
>>> stretch-securitytesting yet.
>>
>>> ```
>>> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
>>> dist-upgrade -y"
>>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>>> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
>>> Reading package lists...
>>> Reading package lists...
>>> Building dependency tree...
>>> Reading state information...
>>> Calculating upgrade...
>>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>>> [user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-gui
>>> ii qubes-gui-agent 3.2.8+deb9u1 amd64 Makes X11 windows available to
>>> qubes dom0
>>> ```
>>
>> Interesting, I have qubes-gui-agent 3.2.11 already, from
>> stretch-testing. Do you have some caching proxy in between?
>>
> At one point I was using Rustybirds update cache proxy, but I've since
> switched back to a whonix-gw and unchecked "Allow connections to Updates
> Proxy".
>
> I have two debian-9 templates, and they both were connected to update
> cache and are now connected to whonix-gw. Here's the results from my two
> debian-9 templates (one is using stretch-testing and
> stretch-securitytesting the other has only stretch-testing although I
> don't think that should matter):
>
> ```
> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
> dist-upgrade -y -V"
> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Calculating upgrade...
> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
> [user@dom0 ~]$ qvm-run -p d9-kali "sudo apt-get update && sudo apt-get
> dist-upgrade -y -V"
> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
> Hit:5 http://deb.bitmask.net/debian stretch InRelease
> Hit:4 http://archive-3.kali.org/kali kali-rolling InRelease
> Reading package lists...
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Calculating upgrade...
> The following packages have been kept back:
>qubes-gui-agent (3.2.8+deb9u1 => 3.2.11-1+deb9u1)
> 0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
> [user@dom0 ~]$ qvm-run -p d9-kali "sudo aptitude dist-upgrade"
> Reading package lists...
> Building dependency tree...
> Reading state information...
> Reading extended state information...
> Initializing package states...
> Building tag database...
> The following NEW packages will be installed:
> xserver-xorg-input-qubes{ab} xserver-xorg-video-dummyqbs{ab}
> The following packages will be upgraded:
> qubes-gui-agent
> 1 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
> Need to get 66.5 kB of archives. After unpacking 36.9 kB will be used.
> The following packages have unmet dependencies:
> xserver-xorg-video-dummyqbs : Depends: xorg-video-abi-23 which is a
> virtual package, provided by:
> - xserver-xorg-core
> (2:1.19.0-2), but 2:1.18.4-2 is installed
>
>Depends: xserver-xorg-core (>=
> 2:1.18.99.901) but 2:1.18.4-2 is installed
> xserver-xorg-input-qubes : Depends: xorg-input-abi-24 which is a
> virtual package, provided by:
> - xserver-xorg-core (2:1.19.0-2),
> but 2:1.18.4-2 is installed
>
> Depends: xserver-xorg-core (>=
> 2:1.18.99.901) but 2:1.18.4-2 is installed
> The following actions will resolve these dependencies:
>
>
Re: [qubes-users] Kali VM no longer responding
Marek Marczykowski-Górecki:
> On Mon, Dec 12, 2016 at 05:10:00PM +0000, qubenix wrote:
>> Marek Marczykowski-Górecki:
>>> Looks like this issue:
>>> https://github.com/QubesOS/qubes-issues/issues/2514
>>>
>>> Rebuilt package just uploaded to testing repository
>>> (qubes-gui-agent_3.2.10-2+deb9u1).
>>>
>>>
>
>> Doesn't seem to be fixed in stretch, stretch-testing, or
>> stretch-securitytesting yet.
>
>> ```
>> [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
>> dist-upgrade -y"
>> Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
>> Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
>> Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
>> Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
>> Reading package lists...
>> Reading package lists...
>> Building dependency tree...
>> Reading state information...
>> Calculating upgrade...
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> [user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-gui
>> ii qubes-gui-agent 3.2.8+deb9u1 amd64 Makes X11 windows available to
>> qubes dom0
>> ```
>
> Interesting, I have qubes-gui-agent 3.2.11 already, from
> stretch-testing. Do you have some caching proxy in between?
>
At one point I was using Rustybirds update cache proxy, but I've since
switched back to a whonix-gw and unchecked "Allow connections to Updates
Proxy".
I have two debian-9 templates, and they both were connected to update
cache and are now connected to whonix-gw. Here's the results from my two
debian-9 templates (one is using stretch-testing and
stretch-securitytesting the other has only stretch-testing although I
don't think that should matter):
```
[user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get
dist-upgrade -y -V"
Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[user@dom0 ~]$ qvm-run -p d9-kali "sudo apt-get update && sudo apt-get
dist-upgrade -y -V"
Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease
Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease
Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease
Hit:5 http://deb.bitmask.net/debian stretch InRelease
Hit:4 http://archive-3.kali.org/kali kali-rolling InRelease
Reading package lists...
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages have been kept back:
qubes-gui-agent (3.2.8+deb9u1 => 3.2.11-1+deb9u1)
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
[user@dom0 ~]$ qvm-run -p d9-kali "sudo aptitude dist-upgrade"
Reading package lists...
Building dependency tree...
Reading state information...
Reading extended state information...
Initializing package states...
Building tag database...
The following NEW packages will be installed:
xserver-xorg-input-qubes{ab} xserver-xorg-video-dummyqbs{ab}
The following packages will be upgraded:
qubes-gui-agent
1 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 66.5 kB of archives. After unpacking 36.9 kB will be used.
The following packages have unmet dependencies:
xserver-xorg-video-dummyqbs : Depends: xorg-video-abi-23 which is a
virtual package, provided by:
- xserver-xorg-core
(2:1.19.0-2), but 2:1.18.4-2 is installed
Depends: xserver-xorg-core (>=
2:1.18.99.901) but 2:1.18.4-2 is installed
xserver-xorg-input-qubes : Depends: xorg-input-abi-24 which is a
virtual package, provided by:
- xserver-xorg-core (2:1.19.0-2),
but 2:1.18.4-2 is installed
Depends: xserver-xorg-core (>=
2:1.18.99.901) but 2:1.18.4-2 is installed
The following actions will resolve these dependencies:
Keep the following packages at their current version:
1) qubes-gui-agent [3.2.8+deb9u1 (now)]
2) xserver-xorg-input-qubes [Not Installed]
3) xserver-xorg-video-dummyqbs [Not Installed]
Accept this solution? [Y/n/q/?]
```
--
qubenix
GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500
--
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/0e8cbae1-d606-6ff4-b65a-79417943bf4b%40riseup.net.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Kali VM no longer responding
Marek Marczykowski-Górecki: > On Mon, Dec 12, 2016 at 12:17:16AM +, a.mcwh...@yandex.com wrote: >> That means not only me has the same issue with debian-9 template. I've >> started reinstalling template. > >> On December 12, 2016 11:01:00 AM AEDT, qubenix <qube...@riseup.net> wrote: >>> Lucas Arnström: >>>> Hi, I have been using a debian template converted into kali for quite >>>> some time. But recently, neither the kali template nor any appvms >>> based >>>> on it are responding. I can start the vms just fine, but cant do much >>>> other than that. It seems to be some recent change that induced this >>>> problem, considering i have been able to use the very same vms for >>> quite >>>> some time. But after my last update they all stopped working. >>>> >>>> I have attempted to do a complete rebuild of my kali template. I got >>>> everything set up, but as soon as I restarted the template I got the >>>> same issue again. >>>> >>>> I'm attaching the logs. >>>> >>>> // Lucas >>>> >>> >>> I've had this same experience after a dist-upgrade on my debian-9 >>> template (d9) about 12 hours ago. I had made a clone of this template >>> about two weeks ago and added the kali repos and some packages. >>> Strangely, my kali template (and AppVM based on it) work normal even >>> though it was also upgraded at the same time. >>> >>> ``` >>> user@dom0:~$ qvm-run -p d9 gnome-terminal >>> Unable to init server: Could not connect: Connection refused >>> Failed to parse arguments: Cannot open display: >>> ``` > > Looks like this issue: > https://github.com/QubesOS/qubes-issues/issues/2514 > > Rebuilt package just uploaded to testing repository > (qubes-gui-agent_3.2.10-2+deb9u1). > > Doesn't seem to be fixed in stretch, stretch-testing, or stretch-securitytesting yet. ``` [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get dist-upgrade -y" Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. [user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-gui ii qubes-gui-agent 3.2.8+deb9u1 amd64 Makes X11 windows available to qubes dom0 ``` -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/c5b9c017-5864-abb5-529b-b995500ca705%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Kali VM no longer responding
Marek Marczykowski-Górecki: > On Mon, Dec 12, 2016 at 12:17:16AM +, a.mcwh...@yandex.com wrote: >> That means not only me has the same issue with debian-9 template. I've >> started reinstalling template. > >> On December 12, 2016 11:01:00 AM AEDT, qubenix <qube...@riseup.net> wrote: >>> Lucas Arnström: >>>> Hi, I have been using a debian template converted into kali for quite >>>> some time. But recently, neither the kali template nor any appvms >>> based >>>> on it are responding. I can start the vms just fine, but cant do much >>>> other than that. It seems to be some recent change that induced this >>>> problem, considering i have been able to use the very same vms for >>> quite >>>> some time. But after my last update they all stopped working. >>>> >>>> I have attempted to do a complete rebuild of my kali template. I got >>>> everything set up, but as soon as I restarted the template I got the >>>> same issue again. >>>> >>>> I'm attaching the logs. >>>> >>>> // Lucas >>>> >>> >>> I've had this same experience after a dist-upgrade on my debian-9 >>> template (d9) about 12 hours ago. I had made a clone of this template >>> about two weeks ago and added the kali repos and some packages. >>> Strangely, my kali template (and AppVM based on it) work normal even >>> though it was also upgraded at the same time. >>> >>> ``` >>> user@dom0:~$ qvm-run -p d9 gnome-terminal >>> Unable to init server: Could not connect: Connection refused >>> Failed to parse arguments: Cannot open display: >>> ``` > > Looks like this issue: > https://github.com/QubesOS/qubes-issues/issues/2514 > > Rebuilt package just uploaded to testing repository > (qubes-gui-agent_3.2.10-2+deb9u1). > > Doesn't seem to be fixed in stretch, stretch-testing, or stretch-securitytesting yet. ``` [user@dom0 ~]$ qvm-run -p d9 "sudo apt-get update && sudo apt-get dist-upgrade -y" Hit:1 http://vwakviie2ienjx6t.onion/debian stretch InRelease Hit:2 http://sgvtcaew4bxjd7ln.onion stretch/updates InRelease Hit:3 http://deb.qubes-os.org/r3.2/vm stretch-testing InRelease Hit:4 http://deb.qubes-os.org/r3.2/vm stretch-securitytesting InRelease Reading package lists... Reading package lists... Building dependency tree... Reading state information... Calculating upgrade... 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. [user@dom0 ~]$ qvm-run -p d9 "sudo dpkg -l" | grep qubes-guiii qubes-gui-agent 3.2.8+deb9u1 amd64Makes X11 windows available to qubes dom0 ``` -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/43f95f6f-3e98-a174-196c-d3799f1f565c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Kali VM no longer responding
Lucas Arnström: > Hi, I have been using a debian template converted into kali for quite > some time. But recently, neither the kali template nor any appvms based > on it are responding. I can start the vms just fine, but cant do much > other than that. It seems to be some recent change that induced this > problem, considering i have been able to use the very same vms for quite > some time. But after my last update they all stopped working. > > I have attempted to do a complete rebuild of my kali template. I got > everything set up, but as soon as I restarted the template I got the > same issue again. > > I'm attaching the logs. > > // Lucas > I've had this same experience after a dist-upgrade on my debian-9 template (d9) about 12 hours ago. I had made a clone of this template about two weeks ago and added the kali repos and some packages. Strangely, my kali template (and AppVM based on it) work normal even though it was also upgraded at the same time. ``` user@dom0:~$ qvm-run -p d9 gnome-terminal Unable to init server: Could not connect: Connection refused Failed to parse arguments: Cannot open display: ``` -- qubenix GPG: B536812904D455B491DCDCDD04BE1E61A3C2E500 -- 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/7851f332-b97d-e5cb-3bb6-02d09be245da%40riseup.net. For more options, visit https://groups.google.com/d/optout.
