[qubes-users] System freezes when left up for a day or two
Hi.
I am running Qubes-OS, 4.0, kept up to date, to the best of my knowledge.
I am on an HP Z8 G4 with 64GB memory. I pretty much mainly run a
personal VM (fedora-29+additions template) with the requisite
sys-{net,*,usb,...}.
The personal VM typically has FireFox, ThunderBird, and a Files and Term
running when it freezes.
I can successfully hibernate, but on restart, it just reboots, no
resume, so either I shutdown/reboot all the time, or I leave it running.
It never lasts more than a day or so. I come in to use it, and the
screen is dimmed, and will not wake up. I have it on an UPS, and no
other machines have issues with power, so that is not it.
When it freezes, sys-net does not respond to ARP requests. That is as
much as I know. No kernel debugger to break into, so no way to force it
to spill the beans. I have looked at various log files post reboot, but
nothing jumps out.
Anyone else having such issues?
--
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/a0fa99c2-e623-d8b7-b91b-3a5decae69c9%40damon.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Upgrades for dom0-Qubes 4; on system reboot skips plymouth, usb kb dies, can't enter decrypt pw
Hello, Try to update to kernel 4.19 sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing kernel kernel-qubes-vm This will download the newer kernel and the kernel for your vms(this version is in the current testing repository which means it’s not the stable version yet(4.14* is). I’ve been using 4.19 for 2 weeks without a problem. You will then install it with sudo dnf install kernel-4.19* And dnf install kernel-qubes-vm-4.19* if it didn’t install it in the previous command. After that if you are in uefi , check in the xen.cfg that default= your new version of kernel Nouveau is enabled by default , you should add that to your kernel line : nouveau.modeset=0 rd.driver.blacklist=nouveau video=vesa:off. This will disable nouveau and your discrete card(nvidia). For the keyboard and mouse, Did you create a sys-usb vm(qube vm for usbs)? Can you show us the output of dmesg -l err ? Aly -- 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/8c811ae2-0dd8-4429-a35b-2545c74211b7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: sudo qubes-dom0-update downloads packages but abruptly ends with a "The downloaded packages were..."
It's like this but without the errors: https://pastebin.com/YVUFtid6 -- 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/d40be472-5b1c-40a8-a82a-4cf24382e86a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] sudo qubes-dom0-update downloads packages but abruptly ends with a "The downloaded packages were..."
I have no idea what's up with my dom0 It downloads the packages through sudo qubes-dom0-update but by Transaction Summary after showing Total Size and Installed Size it doesn't even ask me whether or not to continue the transaction but just says "DNF will only download packages for the transaction." Proceeds to download the packages then ends with a "Complete!" "The downloaded packages were saved in cache until the next successful transaction." Seems some setting about DNF got changed, how do I fix this? -- 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/27341873-f8f4-49bb-9c15-5dd78fcbddef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: ok, things are happening...
On 2/7/19 4:06 PM, Marcus Linsner wrote:
On Thursday, February 7, 2019 at 3:01:50 PM UTC, Marcus Linsner wrote:
first:
restarted, then couldn't launch any AppVMs due to:
[ 638.747910] systemd[1]: Starting Qubes memory management daemon...
[ 638.923606] qmemmand[3984]: Traceback (most recent call last):
[ 638.923980] qmemmand[3984]: File "/usr/bin/qmemmand", line 5, in
[ 638.924219] qmemmand[3984]: sys.exit(main())
[ 638.924465] qmemmand[3984]: File
"/usr/lib/python3.5/site-packages/qubes/tools/qmemmand.py", line 261, in main
[ 638.924697] qmemmand[3984]: qubes.utils.parse_size(config.get('global',
'vm-min-mem'))
[ 638.924908] qmemmand[3984]: File
"/usr/lib/python3.5/site-packages/qubes/utils.py", line 107, in parse_size
[ 638.925120] qmemmand[3984]: raise qubes.exc.QubesException("Invalid size:
{0}.".format(size))
[ 638.925331] qmemmand[3984]: qubes.exc.QubesException: Invalid size: 51MIB.
[ 638.941899] systemd[1]: qubes-qmemman.service: Main process exited,
code=exited, status=1/FAILURE
[ 638.942249] systemd[1]: Failed to start Qubes memory management daemon.
[ 638.942421] systemd[1]: qubes-qmemman.service: Unit entered failed state.
[ 638.942431] systemd[1]: qubes-qmemman.service: Failed with result
'exit-code'.
I don't remember updating /usr/lib/python3.5/site-packages/qubes/utils.py
but size = size.strip().upper() in this context:
def parse_size(size):
units = [
('K', 1000), ('KB', 1000),
('M', 1000 * 1000), ('MB', 1000 * 1000),
('G', 1000 * 1000 * 1000), ('GB', 1000 * 1000 * 1000),
('Ki', 1024), ('KiB', 1024),
('Mi', 1024 * 1024), ('MiB', 1024 * 1024),
('Gi', 1024 * 1024 * 1024), ('GiB', 1024 * 1024 * 1024),
]
size = size.strip().upper()
if size.isdigit():
return int(size)
for unit, multiplier in units:
if size.endswith(unit):
size = size[:-len(unit)].strip()
return int(size) * multiplier
raise qubes.exc.QubesException("Invalid size: {0}.".format(size))
I had to modify 'MiB' into 'MIB' up there.
$ cat /etc/qubes/qmemman.conf
# The only section in this file
[global]
# vm-min-mem - give at least this amount of RAM for dynamically managed VM
# Default: 200M
vm-min-mem = 51MiB
# dom0-mem-boost - additional memory given to dom0 for disk caches etc
# Default: 350M
dom0-mem-boost = 95MiB
# cache-margin-factor - calculate VM preferred memory as (used
memory)*cache-margin-factor
# Default: 1.3
cache-margin-factor = 1.3
on AppVM shutdown, dmesg:
[ 1306.534953] qubesd[2075]: unhandled exception while calling src=b'dom0'
meth=b'admin.vm.property.Get' dest=b'gmail-basedon-w-s-f-fdr28'
arg=b'start_time' len(untrusted_payload)=0
[ 1306.535337] qubesd[2075]: Traceback (most recent call last):
[ 1306.535568] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/__init__.py", line 225, in __get__
[ 1306.535797] qubesd[2075]: return getattr(instance, self._attr_name)
[ 1306.536014] qubesd[2075]: AttributeError: 'AppVM' object has no attribute
'_qubesprop_start_time'
[ 1306.536246] qubesd[2075]: During handling of the above exception, another
exception occurred:
[ 1306.536463] qubesd[2075]: Traceback (most recent call last):
[ 1306.536678] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 266, in respond
[ 1306.536898] qubesd[2075]: untrusted_payload=untrusted_payload)
[ 1306.537116] qubesd[2075]: File "/usr/lib64/python3.5/asyncio/futures.py",
line 381, in __iter__
[ 1306.537349] qubesd[2075]: yield self # This tells Task to wait for
completion.
[ 1306.537568] qubesd[2075]: File "/usr/lib64/python3.5/asyncio/tasks.py",
line 310, in _wakeup
[ 1306.537782] qubesd[2075]: future.result()
[ 1306.537993] qubesd[2075]: File "/usr/lib64/python3.5/asyncio/futures.py",
line 294, in result
[ 1306.538211] qubesd[2075]: raise self._exception
[ 1306.538467] qubesd[2075]: File "/usr/lib64/python3.5/asyncio/tasks.py",
line 240, in _step
[ 1306.538682] qubesd[2075]: result = coro.send(None)
[ 1306.538894] qubesd[2075]: File
"/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro
[ 1306.539119] qubesd[2075]: res = func(*args, **kw)
[ 1306.539343] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 155, in
vm_property_get
[ 1306.539564] qubesd[2075]: return self._property_get(self.dest)
[ 1306.539777] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 185, in
_property_get
[ 1306.539996] qubesd[2075]: value = getattr(dest, self.arg)
[ 1306.540208] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/__init__.py", line 228, in __get__
[ 1306.540433] qubesd[2075]: return self.get_default(instance)
[ 1306.540646] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/__init__.py", line 235, in get_default
[ 1306.540860] qubesd[2075]: return
[qubes-users] dom0 command to update multiple templates?
I tried a variation or two of: sudo qvm-run -u root fedora-29 dnf update && sudo qvm-run -u root debian-8 apt-get update but none of them worked. The little sun icon/updater doesnt seem to be working completely yet though it be nice to just have everything check for then update with one neat little script, possible? -- 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/0c44cda4-0eae-7717-b815-deb64a5ffc5f%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Upgrades for dom0-Qubes 4; on system reboot skips plymouth, usb kb dies, can't enter decrypt pw
On Monday, January 28, 2019 at 11:55:06 AM UTC-7, qubert wrote: > First visible error on screen: > [FAILED] Failed to start Setup Virtual Console > Second vis error: > [FAILED] Failed to start Show Plymouth Boot Screen. > > No problem, eh? Because a few lines later, it prompts me for the passphrase > for the encrypted disk. Awesome. > > But every time, as soon as it gets there, my keyboard light goes dead, and I > of course can't type anything in. > > I have tried four different keyboards. All keyboards are USB, three are > wired, one wireless. Have also tried multiple different usb ports, some usb > 2.0 and some usb 3. > Have been using the system just like this for many months with two different > usb keyboards. Nothing changed except running the dom0 upgrade (from qubes > manager right-click), and I rebooted immediately after. > > When I edit the boot options by eliminating "quiet" I get exactly the same > prompt for the luks decrypt password, except it adds this as the final > logging line (this line also overwrites the area in which I should be > entering the decrypt pw): > [ 3.407261] clocksource: Switched to clocksource tsc > > Removing 'rhgb' in addition to quiet eliminates the plymouth boot error, but > I still get dumped out onto the terminal password entry line and as soon as > that line comes up the keyboard light goes off every time! > > Obviously without a keyboard, I can't even get tty, much less enter the > unlock passphrase. > > I'm effectively locked out, and before I start messing with it and changing > things, thought I would ask to see if anyone out there knows what might be > wrong > > Thanks! Swapped out the nvidia for an amd card. No change. So, switched back. I'm running out of time. This has now been down over a week. Tons of research on plymouth boot and the other error, but nothing relevant. Ideas? -- 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/fde2d6ed-5c29-475b-b985-13e6e3377240%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] why mail-list?
Thank you all for your answers. Thank you for https://qubes-os.info/ I'm discovering it. There is now just one thing who is boring me : i don't like google and don't want to feed the monster. There are others free services for mailing lists, like the very nice Riseup. Whatever, good night and good luck. -- 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/40179877-08eb-5722-00c6-8bf0c8d602c0%40riseup.net. For more options, visit https://groups.google.com/d/optout. pEpkey.asc Description: application/pgp-keys
Re: [qubes-users] Re: How to set some DNS entries in /etc/hosts for some hosts?
Marcus Linsner wrote on 2/7/19 2:31 PM:
On Thursday, February 7, 2019 at 2:17:19 PM UTC, Marcus Linsner wrote:
On Thursday, February 7, 2019 at 1:44:00 PM UTC, Marcus Linsner wrote:
On Thursday, February 7, 2019 at 1:04:07 PM UTC, Marcus Linsner wrote:
On Thursday, February 7, 2019 at 12:57:39 PM UTC, Marcus Linsner wrote:
Sometimes github.com resolves to 192.30.253.112 and .113 and today(at least)
they don't allow port 22 ssh, so `git push` fails like
ssh: connect to host github.com port 22: No route to host
I noticed however that when it resolves to something like 140.82.112.40 (unsure
exactly the IP) then ssh works and `git push` succeeds!
the working IP is 140.82.118.3
grreat, now not even that IP works anymore:
ssh: connect to host github.com port 22: No route to host
i'm guessing some epic sshd bug is being exploited? :D silly speculation(s)
ok, it's because of Qubes because having a rule in Firewall like "github.com" "ssh" "tcp"
which apparently adds an iptables(?) rule based on resolved IP at the time(of AppVM start?), and github having changing
IPs ("We do not recommend whitelisting by IP address," from:
https://help.github.com/articles/about-github-s-ip-addresses/ )
so basically, it was my fault :)
oh and I forgot to mention that because ping always works even if everything
else is denied(in AppVM's Firewall tab), it threw me off :) it's a Qubes
feature, I know.
You probably figured out already that if you determine and add all
ofGithub's IPs to your SSH firewall rules, you can have what you're
looking for.
--
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/fe7531fb-8b15-67b8-3484-af1e904b55aa%40danwin1210.me.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: why mail-list?
On Thu, 7 Feb 2019 06:31:01 -0800 (PST) billol...@gmail.com wrote: >On Wednesday, February 6, 2019 at 11:36:12 AM UTC-5, unman wrote: >> On Wed, Feb 06, 2019 at 10:15:54AM -0600, John Goold wrote: >> > -BEGIN PGP SIGNED MESSAGE- >> > Hash: SHA256 >> > >> > On 2/6/19 1:12 AM, 'awokd' via qubes-users wrote: >> > > kitchm via Forum: >> > > >> > ... >> > >> It is currently illegal by federal law to clear your browser >> > >> history. >> > > >> > > Cite? >> > >> > What one does with one's browser history, even assuming one's browser >> > has a browser history, is clearly not governed by law, except perhaps >> > in countries like China and Russion. >> > -BEGIN PGP SIGNATURE- >> > >> > iQEzBAEBCAAdFiEEe8Wcf7Po7bts2Rl4jWN9/rQYsRwFAlxbCDgACgkQjWN9/rQY >> > sRwFfQf+MRGgCma20R/XDSkO0X94ul0kb8p/GfUBQbw7/bbdNKXtawkUtzGqe44I >> > IExLLsikRRTdHGIMvHVpBXNjQGm2Qh6MdL4v+cd/CN2vtj5Yh2ifk5OF5xt5hb0A >> > EX+8EYoo5GoF+2urI3IU6NTKBL0tCDiKIcjVIMuxg9ah0mo1QTO5+ewlX5AGlyLS >> > c2dVDHB3svCIKQ9xrHZxcNLL3WKL6lrOwP/oGuM6NLGJtnBDbS7ihkJA1GMu7m5H >> > 3hHQFq7vb8/6vNf6L8jqC3MPDbp/zXXwCk1UjLofnbUX+ExVDKPZF43qI8yMiGwN >> > UkdsgfCZfIQjh1jKGDXhJ2/xyhySvw== >> > =zjDq >> > -END PGP SIGNATURE- >> >> Actually, it may be governed by law in the US, but not in Russia. >> The FBI have interpreted Sarbanes-Oxley as creating a >> felony offence where one deletes browser history where there was >> reasonable expectation of investigation. >> It has been used against Matanov, a friend of the Boston bombers, and >> David Kernell, who hacked Sarah Palin's email. >> The EFF have highlighted this interpretation of Sarbanes Oxley as >> egregious, but no doubt the authorities deem it necessary. >> >> Note that it is NOT illegal in the US to clear your browser history: >> but it may prove a felony offence to do so. In the two cases cited there >> were reasonable grounds to suppose that a federal investigation would >> take place. > >It should probably be noted that those 2015 prosecutions were a bit novel, and >it has not become common practice. In fact, the Supreme Court reigned it in a >little with Yates v US (2015) in which they threw out the conviction of a >fisherman who threw away an illegal catch to avoid prosecution. >Sarbanes-Oxley was written for corporate stuff, to stop corporations from >deleting emails and shredding documents in order to hide a crime that they >knew would be, but had not yet been, moved forward for prosecution. The >application of this to conspiracy to commit terrorist acts is not too >far-fetched, but its application was novel, and was not tested in appeal as >far as I know. > >In terms of private citizens engaging in routine privacy measures, I know of >no such prosecution. Sure, an aggressive DA can charge anybody with anything >for any reason, and some pay no attention to truth, precedent or law at all. >But if someone has a case of someone as a private citizen who routinely cleans >up their files, I'd love to see it. > >Since Oxley Sarbanes requires the intent to interfere in the investigation of >a criminal act, it would seem to me that a private citizen who routinely >cleans house for privacy reasons while not engaged in such acts would have an >affirmative defense that continuing to do so does not indicate such specific >intent. For instance, as I mentioned, a professional organization I belong to >does not archive its mailinglist specifically to avoid people mining archives >to look for embarrassing quotes for use in the newspapers and in court. The >intent there is clearly *not* to cover up a crime, but instead to protect >privacy. I'm no lawyer, of course, but I find it hard to generalize the idea >that Oxley Sarbanes is that huge of a threat as it currently is enforced. > >I'll also point out that if anything were this kind of violation, then the >Hillary email stuff would have been ripe for prosecution under this law, and >the DoJ clearly said that the presumption is that there isn't criminal intent, >at least with respect to that kind of behavior. I suspect that most >prosecutors know this, which means that egregious overapplication of this law >will be unlikely, else it will be repealed -- since most Republicans hate the >law as it stands and are looking for an excuse to get rid of it. > Sarbanes/Oxley certainly has given me and a lot of other consultants...and auditors...a lot of work. :) -- 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/20190207133636.00eef430%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: ok, things are happening...
On Thursday, February 7, 2019 at 3:01:50 PM UTC, Marcus Linsner wrote:
> first:
> restarted, then couldn't launch any AppVMs due to:
>
> [ 638.747910] systemd[1]: Starting Qubes memory management daemon...
> [ 638.923606] qmemmand[3984]: Traceback (most recent call last):
> [ 638.923980] qmemmand[3984]: File "/usr/bin/qmemmand", line 5, in
> [ 638.924219] qmemmand[3984]: sys.exit(main())
> [ 638.924465] qmemmand[3984]: File
> "/usr/lib/python3.5/site-packages/qubes/tools/qmemmand.py", line 261, in main
> [ 638.924697] qmemmand[3984]:
> qubes.utils.parse_size(config.get('global', 'vm-min-mem'))
> [ 638.924908] qmemmand[3984]: File
> "/usr/lib/python3.5/site-packages/qubes/utils.py", line 107, in parse_size
> [ 638.925120] qmemmand[3984]: raise qubes.exc.QubesException("Invalid
> size: {0}.".format(size))
> [ 638.925331] qmemmand[3984]: qubes.exc.QubesException: Invalid size: 51MIB.
> [ 638.941899] systemd[1]: qubes-qmemman.service: Main process exited,
> code=exited, status=1/FAILURE
> [ 638.942249] systemd[1]: Failed to start Qubes memory management daemon.
> [ 638.942421] systemd[1]: qubes-qmemman.service: Unit entered failed state.
> [ 638.942431] systemd[1]: qubes-qmemman.service: Failed with result
> 'exit-code'.
>
>
> I don't remember updating /usr/lib/python3.5/site-packages/qubes/utils.py
> but size = size.strip().upper() in this context:
>
> def parse_size(size):
> units = [
> ('K', 1000), ('KB', 1000),
> ('M', 1000 * 1000), ('MB', 1000 * 1000),
> ('G', 1000 * 1000 * 1000), ('GB', 1000 * 1000 * 1000),
> ('Ki', 1024), ('KiB', 1024),
> ('Mi', 1024 * 1024), ('MiB', 1024 * 1024),
>
>
> ('Gi', 1024 * 1024 * 1024), ('GiB', 1024 * 1024 * 1024),
> ]
>
> size = size.strip().upper()
> if size.isdigit():
> return int(size)
>
> for unit, multiplier in units:
> if size.endswith(unit):
> size = size[:-len(unit)].strip()
> return int(size) * multiplier
>
> raise qubes.exc.QubesException("Invalid size: {0}.".format(size))
>
> I had to modify 'MiB' into 'MIB' up there.
>
> $ cat /etc/qubes/qmemman.conf
> # The only section in this file
> [global]
> # vm-min-mem - give at least this amount of RAM for dynamically managed VM
> # Default: 200M
> vm-min-mem = 51MiB
>
> # dom0-mem-boost - additional memory given to dom0 for disk caches etc
> # Default: 350M
> dom0-mem-boost = 95MiB
>
> # cache-margin-factor - calculate VM preferred memory as (used
> memory)*cache-margin-factor
> # Default: 1.3
> cache-margin-factor = 1.3
>
on AppVM shutdown, dmesg:
[ 1306.534953] qubesd[2075]: unhandled exception while calling src=b'dom0'
meth=b'admin.vm.property.Get' dest=b'gmail-basedon-w-s-f-fdr28'
arg=b'start_time' len(untrusted_payload)=0
[ 1306.535337] qubesd[2075]: Traceback (most recent call last):
[ 1306.535568] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/__init__.py", line 225, in __get__
[ 1306.535797] qubesd[2075]: return getattr(instance, self._attr_name)
[ 1306.536014] qubesd[2075]: AttributeError: 'AppVM' object has no attribute
'_qubesprop_start_time'
[ 1306.536246] qubesd[2075]: During handling of the above exception, another
exception occurred:
[ 1306.536463] qubesd[2075]: Traceback (most recent call last):
[ 1306.536678] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/api/__init__.py", line 266, in respond
[ 1306.536898] qubesd[2075]: untrusted_payload=untrusted_payload)
[ 1306.537116] qubesd[2075]: File "/usr/lib64/python3.5/asyncio/futures.py",
line 381, in __iter__
[ 1306.537349] qubesd[2075]: yield self # This tells Task to wait for
completion.
[ 1306.537568] qubesd[2075]: File "/usr/lib64/python3.5/asyncio/tasks.py",
line 310, in _wakeup
[ 1306.537782] qubesd[2075]: future.result()
[ 1306.537993] qubesd[2075]: File "/usr/lib64/python3.5/asyncio/futures.py",
line 294, in result
[ 1306.538211] qubesd[2075]: raise self._exception
[ 1306.538467] qubesd[2075]: File "/usr/lib64/python3.5/asyncio/tasks.py",
line 240, in _step
[ 1306.538682] qubesd[2075]: result = coro.send(None)
[ 1306.538894] qubesd[2075]: File
"/usr/lib64/python3.5/asyncio/coroutines.py", line 210, in coro
[ 1306.539119] qubesd[2075]: res = func(*args, **kw)
[ 1306.539343] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 155, in
vm_property_get
[ 1306.539564] qubesd[2075]: return self._property_get(self.dest)
[ 1306.539777] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/api/admin.py", line 185, in
_property_get
[ 1306.539996] qubesd[2075]: value = getattr(dest, self.arg)
[ 1306.540208] qubesd[2075]: File
"/usr/lib/python3.5/site-packages/qubes/__init__.py", line 228, in __get__
[ 1306.540433] qubesd[2075]: return
[qubes-users] ok, things are happening...
first:
restarted, then couldn't launch any AppVMs due to:
[ 638.747910] systemd[1]: Starting Qubes memory management daemon...
[ 638.923606] qmemmand[3984]: Traceback (most recent call last):
[ 638.923980] qmemmand[3984]: File "/usr/bin/qmemmand", line 5, in
[ 638.924219] qmemmand[3984]: sys.exit(main())
[ 638.924465] qmemmand[3984]: File
"/usr/lib/python3.5/site-packages/qubes/tools/qmemmand.py", line 261, in main
[ 638.924697] qmemmand[3984]: qubes.utils.parse_size(config.get('global',
'vm-min-mem'))
[ 638.924908] qmemmand[3984]: File
"/usr/lib/python3.5/site-packages/qubes/utils.py", line 107, in parse_size
[ 638.925120] qmemmand[3984]: raise qubes.exc.QubesException("Invalid
size: {0}.".format(size))
[ 638.925331] qmemmand[3984]: qubes.exc.QubesException: Invalid size: 51MIB.
[ 638.941899] systemd[1]: qubes-qmemman.service: Main process exited,
code=exited, status=1/FAILURE
[ 638.942249] systemd[1]: Failed to start Qubes memory management daemon.
[ 638.942421] systemd[1]: qubes-qmemman.service: Unit entered failed state.
[ 638.942431] systemd[1]: qubes-qmemman.service: Failed with result
'exit-code'.
I don't remember updating /usr/lib/python3.5/site-packages/qubes/utils.py
but size = size.strip().upper() in this context:
def parse_size(size):
units = [
('K', 1000), ('KB', 1000),
('M', 1000 * 1000), ('MB', 1000 * 1000),
('G', 1000 * 1000 * 1000), ('GB', 1000 * 1000 * 1000),
('Ki', 1024), ('KiB', 1024),
('Mi', 1024 * 1024), ('MiB', 1024 * 1024),
('Gi', 1024 * 1024 * 1024), ('GiB', 1024 * 1024 * 1024),
]
size = size.strip().upper()
if size.isdigit():
return int(size)
for unit, multiplier in units:
if size.endswith(unit):
size = size[:-len(unit)].strip()
return int(size) * multiplier
raise qubes.exc.QubesException("Invalid size: {0}.".format(size))
I had to modify 'MiB' into 'MIB' up there.
$ cat /etc/qubes/qmemman.conf
# The only section in this file
[global]
# vm-min-mem - give at least this amount of RAM for dynamically managed VM
# Default: 200M
vm-min-mem = 51MiB
# dom0-mem-boost - additional memory given to dom0 for disk caches etc
# Default: 350M
dom0-mem-boost = 95MiB
# cache-margin-factor - calculate VM preferred memory as (used
memory)*cache-margin-factor
# Default: 1.3
cache-margin-factor = 1.3
Then second:
can't start my git AppVM due to:
[ 754.926303] libvirtd[1800]: 2019-02-07 14:54:09.985+: 1831: error :
libxlDomainStart:1308 : internal error: libxenlight failed to create new domain
'gitsites-baseon-w-s-f-fdr28'
[ 754.927495] qubesd[2075]: Start failed: internal error: libxenlight failed
to create new domain 'gitsites-baseon-w-s-f-fdr28'
which in fairness, might be due to my newly compiled kernel 4.20.7 ...
but hey, this gmail AppVM works... so I don't even know anymore :D
--
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/267e04ff-1eb4-4ba6-905a-fc88b644e46a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to set some DNS entries in /etc/hosts for some hosts?
On Thursday, February 7, 2019 at 2:17:19 PM UTC, Marcus Linsner wrote:
> On Thursday, February 7, 2019 at 1:44:00 PM UTC, Marcus Linsner wrote:
> > On Thursday, February 7, 2019 at 1:04:07 PM UTC, Marcus Linsner wrote:
> > > On Thursday, February 7, 2019 at 12:57:39 PM UTC, Marcus Linsner wrote:
> > > > Sometimes github.com resolves to 192.30.253.112 and .113 and today(at
> > > > least) they don't allow port 22 ssh, so `git push` fails like
> > > > ssh: connect to host github.com port 22: No route to host
> > > >
> > > > I noticed however that when it resolves to something like 140.82.112.40
> > > > (unsure exactly the IP) then ssh works and `git push` succeeds!
> > >
> > > the working IP is 140.82.118.3
> >
> > grreat, now not even that IP works anymore:
> > ssh: connect to host github.com port 22: No route to host
> >
> > i'm guessing some epic sshd bug is being exploited? :D silly speculation(s)
>
> ok, it's because of Qubes because having a rule in Firewall like "github.com"
> "ssh" "tcp" which apparently adds an iptables(?) rule based on resolved IP at
> the time(of AppVM start?), and github having changing IPs ("We do not
> recommend whitelisting by IP address," from:
> https://help.github.com/articles/about-github-s-ip-addresses/ )
>
> so basically, it was my fault :)
oh and I forgot to mention that because ping always works even if everything
else is denied(in AppVM's Firewall tab), it threw me off :) it's a Qubes
feature, I know.
--
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/deddad62-b99d-45eb-9df2-317f4cf35bdc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: why mail-list?
On Wednesday, February 6, 2019 at 11:36:12 AM UTC-5, unman wrote: > On Wed, Feb 06, 2019 at 10:15:54AM -0600, John Goold wrote: > > -BEGIN PGP SIGNED MESSAGE- > > Hash: SHA256 > > > > On 2/6/19 1:12 AM, 'awokd' via qubes-users wrote: > > > kitchm via Forum: > > > > > ... > > >> It is currently illegal by federal law to clear your browser > > >> history. > > > > > > Cite? > > > > What one does with one's browser history, even assuming one's browser > > has a browser history, is clearly not governed by law, except perhaps > > in countries like China and Russion. > > -BEGIN PGP SIGNATURE- > > > > iQEzBAEBCAAdFiEEe8Wcf7Po7bts2Rl4jWN9/rQYsRwFAlxbCDgACgkQjWN9/rQY > > sRwFfQf+MRGgCma20R/XDSkO0X94ul0kb8p/GfUBQbw7/bbdNKXtawkUtzGqe44I > > IExLLsikRRTdHGIMvHVpBXNjQGm2Qh6MdL4v+cd/CN2vtj5Yh2ifk5OF5xt5hb0A > > EX+8EYoo5GoF+2urI3IU6NTKBL0tCDiKIcjVIMuxg9ah0mo1QTO5+ewlX5AGlyLS > > c2dVDHB3svCIKQ9xrHZxcNLL3WKL6lrOwP/oGuM6NLGJtnBDbS7ihkJA1GMu7m5H > > 3hHQFq7vb8/6vNf6L8jqC3MPDbp/zXXwCk1UjLofnbUX+ExVDKPZF43qI8yMiGwN > > UkdsgfCZfIQjh1jKGDXhJ2/xyhySvw== > > =zjDq > > -END PGP SIGNATURE- > > Actually, it may be governed by law in the US, but not in Russia. > The FBI have interpreted Sarbanes-Oxley as creating a > felony offence where one deletes browser history where there was > reasonable expectation of investigation. > It has been used against Matanov, a friend of the Boston bombers, and > David Kernell, who hacked Sarah Palin's email. > The EFF have highlighted this interpretation of Sarbanes Oxley as > egregious, but no doubt the authorities deem it necessary. > > Note that it is NOT illegal in the US to clear your browser history: > but it may prove a felony offence to do so. In the two cases cited there > were reasonable grounds to suppose that a federal investigation would > take place. It should probably be noted that those 2015 prosecutions were a bit novel, and it has not become common practice. In fact, the Supreme Court reigned it in a little with Yates v US (2015) in which they threw out the conviction of a fisherman who threw away an illegal catch to avoid prosecution. Sarbanes-Oxley was written for corporate stuff, to stop corporations from deleting emails and shredding documents in order to hide a crime that they knew would be, but had not yet been, moved forward for prosecution. The application of this to conspiracy to commit terrorist acts is not too far-fetched, but its application was novel, and was not tested in appeal as far as I know. In terms of private citizens engaging in routine privacy measures, I know of no such prosecution. Sure, an aggressive DA can charge anybody with anything for any reason, and some pay no attention to truth, precedent or law at all. But if someone has a case of someone as a private citizen who routinely cleans up their files, I'd love to see it. Since Oxley Sarbanes requires the intent to interfere in the investigation of a criminal act, it would seem to me that a private citizen who routinely cleans house for privacy reasons while not engaged in such acts would have an affirmative defense that continuing to do so does not indicate such specific intent. For instance, as I mentioned, a professional organization I belong to does not archive its mailinglist specifically to avoid people mining archives to look for embarrassing quotes for use in the newspapers and in court. The intent there is clearly *not* to cover up a crime, but instead to protect privacy. I'm no lawyer, of course, but I find it hard to generalize the idea that Oxley Sarbanes is that huge of a threat as it currently is enforced. I'll also point out that if anything were this kind of violation, then the Hillary email stuff would have been ripe for prosecution under this law, and the DoJ clearly said that the presumption is that there isn't criminal intent, at least with respect to that kind of behavior. I suspect that most prosecutors know this, which means that egregious overapplication of this law will be unlikely, else it will be repealed -- since most Republicans hate the law as it stands and are looking for an excuse to get rid of it. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ad11e3e4-4a4c-4bb1-9574-3f569043781d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to set some DNS entries in /etc/hosts for some hosts?
On Thursday, February 7, 2019 at 1:44:00 PM UTC, Marcus Linsner wrote:
> On Thursday, February 7, 2019 at 1:04:07 PM UTC, Marcus Linsner wrote:
> > On Thursday, February 7, 2019 at 12:57:39 PM UTC, Marcus Linsner wrote:
> > > Sometimes github.com resolves to 192.30.253.112 and .113 and today(at
> > > least) they don't allow port 22 ssh, so `git push` fails like
> > > ssh: connect to host github.com port 22: No route to host
> > >
> > > I noticed however that when it resolves to something like 140.82.112.40
> > > (unsure exactly the IP) then ssh works and `git push` succeeds!
> >
> > the working IP is 140.82.118.3
>
> grreat, now not even that IP works anymore:
> ssh: connect to host github.com port 22: No route to host
>
> i'm guessing some epic sshd bug is being exploited? :D silly speculation(s)
ok, it's because of Qubes because having a rule in Firewall like "github.com"
"ssh" "tcp" which apparently adds an iptables(?) rule based on resolved IP at
the time(of AppVM start?), and github having changing IPs ("We do not recommend
whitelisting by IP address," from:
https://help.github.com/articles/about-github-s-ip-addresses/ )
so basically, it was my fault :)
But still, I'd like to know an answer to my OP question: but I'm gonna guess
I'll have to use dnsmasq instead of any kind of /etc/hosts, that is, for global
effect.
--
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/047dce15-fbf4-4cb7-88f6-b65d06c94506%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to set some DNS entries in /etc/hosts for some hosts?
On Thursday, February 7, 2019 at 1:04:07 PM UTC, Marcus Linsner wrote: > On Thursday, February 7, 2019 at 12:57:39 PM UTC, Marcus Linsner wrote: > > Sometimes github.com resolves to 192.30.253.112 and .113 and today(at > > least) they don't allow port 22 ssh, so `git push` fails like > > ssh: connect to host github.com port 22: No route to host > > > > I noticed however that when it resolves to something like 140.82.112.40 > > (unsure exactly the IP) then ssh works and `git push` succeeds! > > the working IP is 140.82.118.3 grreat, now not even that IP works anymore: ssh: connect to host github.com port 22: No route to host i'm guessing some epic sshd bug is being exploited? :D silly speculation(s) -- 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/b76d8eaa-1aa2-4c18-af8c-65e74960386c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to set some DNS entries in /etc/hosts for some hosts?
On Thursday, February 7, 2019 at 12:57:39 PM UTC, Marcus Linsner wrote: > Sometimes github.com resolves to 192.30.253.112 and .113 and today(at least) > they don't allow port 22 ssh, so `git push` fails like > ssh: connect to host github.com port 22: No route to host > > I noticed however that when it resolves to something like 140.82.112.40 > (unsure exactly the IP) then ssh works and `git push` succeeds! the working IP is 140.82.118.3 -- 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/12ba1cc4-24ca-4145-9323-ae28a436c5dd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] How to set some DNS entries in /etc/hosts for some hosts?
Sometimes github.com resolves to 192.30.253.112 and .113 and today(at least) they don't allow port 22 ssh, so `git push` fails like ssh: connect to host github.com port 22: No route to host I noticed however that when it resolves to something like 140.82.112.40 (unsure exactly the IP) then ssh works and `git push` succeeds! Valid github IPs can be seen here: https://api.github.com/meta https://www.githubstatus.com/ currently reports all systems operational. So, what ami2do? :) I would need some global way to make sure github.com resolves to the working IP, but unsure how to make this work. Ideally this would be in sys-net's /etc/hosts but this of course doesn't have any effect: github.com still resolves to either of those .112 and .113 IPs. It only works if I put it in the current AppVM's /etc/hosts, of course. How can this be done globally? (Ideally, I would like to even bypass DNS completely, eventually, and only use /etc/hosts (kept up to date manually) but not in this post/thread.) -- 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/877926d2-5668-4ff5-9864-7eba8e97ca18%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: why mail-list?
Am Mittwoch, den 06.02.2019, 11:34 -0500 schrieb kitchm via Forum: > So did you not read Stuart's post where he states "My > current client has a court order to NEVER delete another > e-mail"? So you don't know the difference between a court order and a law? > Have you not read books by experts such as Kevin Mitnick? > We who have, know the truth, because we keep abreast of what > the experts say. *rofl* > Achim, you wrote "So what". regarding putting public discussions into a place where they are easily redistributable and archived > Really? You don't see the > significance in that? I do which is why I want to keep them in an easily archivable format for offline storage where I can keep them accessible in case of the original mechanism failing. Instead of putting it at the mercy of some "web forum". > BTW, you are certainly not polite, Definitely not to entitled snowflakes. Achim -- 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/c419beb83ffa419c5a334057b097b5e4edcc4295.camel%40noses.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Editing domains in virsh results in "Extra element os in interleave"
When I edit domains in virsh I get the message ``` error: XML document failed to validate against schema: Unable to validate doc against /usr/share/libvirt/schemas/domain.rng Extra element os in interleave Element domain failed to validate content ``` This happens even if I only change the amount of vcpu from 2 to 1. So I haven't added any elements. This is in Qubes 4. -- 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/35dee470-e6e1-4b70-a0fa-a01cfcca13e8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to do the extra configuration needed on a new template
On Tuesday, February 5, 2019 at 8:35:28 AM UTC+8, unman wrote: > On Sun, Feb 03, 2019 at 10:16:55PM -0800, Sphere wrote: > > So I got a new Fedora-29 template but the problem is that after assigning > > it to sys-net/sys-firewall all it shows is something similar to what you > > when you start a generic PC after BIOS POST. > > > > All that's in this link: > > https://www.qubes-os.org/news/2019/01/07/fedora-29-template-available/ > > > > Is how to get the template but I don't think I found anywhere detailing > > what to do afterwards. > > > > I'm not clear what you mean by this: "what you when you start a generic > PC after BIOS POST". > > Once you have installed the template (with dnf or qubes-dom0-update), > then all you have to do is assign it to qubes as required. Those qubes > will then start using the assigned template. > You can confirm this by opening a terminal in sys-net and observing > contents of /etc/fedora-release My bad about that. I meant to say was "what you see when you start a generic PC after BIOS POST" Hmm I tried it again today by assigning it to a test vm and surprisingly it worked. Not sure if a reboot did it but I haven't really touched it since February 4. In any case thank you for that. -- 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/09390c9c-e9a8-43bc-ac07-83890f15fbaf%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
