[qubes-users] Let's close this thread ...
On Thu, 4 Apr 2024, 19:45 Viktor Ransmayr, wrote: > Hello 'Haaber' & Qubes OS community, > > Am Di., 20. Feb. 2024 um 20:12 Uhr schrieb Viktor Ransmayr < > viktor.ransm...@gmail.com>: > >> ... >> Am Di., 20. Feb. 2024 um 11:10 Uhr schrieb 'haaber' via qubes-users < >> qubes-users@googlegroups.com>: >> >>> ... >>> >>> all updates go via tor network (sys-whonix) by default. You could click >>> on the blue qube widget -> sys-wonix -> run terminal and see if sys-whonix >>> has network. But I >>> >> It took much longer due to private reasons - but - I can report that I > was able to fully recover from the backups ! > > What I did different than suggested was that I started with a clean > re-install of Qubes OS 4.1 ... > Let's close this 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAAeSrGKe6ErPWJmi%2BbrC_hrvPBTiR-7m%3DjD0AUo6FnSKagPM7A%40mail.gmail.com.
Re: [qubes-users] Need help after a failed in-place upgrade attempt
Hello 'Haaber' & Qubes OS community,
Am Di., 20. Feb. 2024 um 20:12 Uhr schrieb Viktor Ransmayr <
viktor.ransm...@gmail.com>:
> ...
> Am Di., 20. Feb. 2024 um 11:10 Uhr schrieb 'haaber' via qubes-users <
> qubes-users@googlegroups.com>:
>
>> ...
>>
>> all updates go via tor network (sys-whonix) by default. You could click
>> on the blue qube widget -> sys-wonix -> run terminal and see if sys-whonix
>> has network. But I guess not. Here is why:
>>
>> https://www.qubes-os.org/doc/firewall/
>>
>> I wild-guess that you are in a "half-state" where one part of the system
>> expects iptables, another one nftables ...
>>
>> Did you download / start to download new (debian/fedora) Templates or are
>> they the "old" ones?
>>
>> I did not see any other user jump to your help, and I am not good enough
>> to fix that alone for you. So honestly, at your place I would
>>
>> (1) backup data (again)
>>
>> (2) extract the list of manually installed packages in each of your
>> templates and stock them on your backup drive
>>
>> ("apt-mark showmanual > manual.packages.list" in a terminal is your
>> friend, no root priv needed)
>>
>> (3) re-install a clean 4.2
>>
>> (4) replay your manual installs of packages in your templates:
>>
>> "cat manual.packages.list | apt-get install " or something of this
>> type should work (run as root)
>>
>> (5) restore your data.
>>
>> It's a pain and takes half a day, but I fear that it is, at the end of
>> the day, faster than any other solution...
>>
>> good luck!
>>
>
> Thanks a lot !
>
> This is exactly the feedback I was hoping for.
>
> I'll investigate further on my side & will provide an update from my side
> before the end of the week ...
>
It took much longer due to private reasons - but - I can report that I was
able to fully recover from the backups !
What I did different than suggested was that I started with a clean
re-install of Qubes OS 4.1 ...
Now I've started a second attempt of an in-place upgrade - and - are
already running into issues again at STAGE 1:
Here is the dom0 - log:
###
[vr@dom0 ~]$
[vr@dom0 ~]$ sudo qubes-dist-upgrade --update
WARNING: /!\ MAKE SURE YOU HAVE MADE A BACKUP OF ALL YOUR VMs AND dom0
DATA /!\
-> Launch upgrade process? [y/N] y
---> Allow shutdown of unnecessary VM (use --keep-running to exclude
some): fedora-feedly-vm fedora-qubes-study-vm? [y/N] y
---> (STAGE 1) Do you want to make a dom0 snapshot? [y/N] y
WARNING: Sum of all thin volume sizes (<2.83 TiB) exceeds the size of
thin pools and the size of whole volume group (<475.34 GiB).
Logical volume "Qubes41UpgradeBackup" created.
--> If upgrade to 4.2 fails, you can restore your dom0 snapshot with
sudo lvconvert --merge qubes_dom0/Qubes41UpgradeBackup. Reboot after
restoration.
---> (STAGE 1) Updating dom0...
Using sys-firewall as UpdateVM to download updates for Dom0; this may
take some time...
Qubes OS Repository for Dom02.9 MB/s | 3.0 kB
00:00
Qubes OS Repository for Dom06.7 MB/s | 192 kB
00:00
kernel-latest.x86_64 1000:6.7.7-1.qubes.fc32
qubes-dom0-cached
kernel-latest-devel.x86_641000:6.7.7-1.qubes.fc32
qubes-dom0-cached
kernel-latest-modules.x86_64 1000:6.7.7-1.qubes.fc32
qubes-dom0-cached
kernel-latest-qubes-vm.x86_64 1000:6.7.7-1.qubes.fc32
qubes-dom0-cached
qubes-usb-proxy-dom0.noarch 1.2.0-1.fc32
qubes-dom0-cached
Qubes OS Repository for Dom02.9 MB/s | 3.0 kB
00:00
Dependencies resolved.
PackageArch Version Repository
Size
Installing:
kernel-latest x86_64 1000:6.7.7-1.qubes.fc32
qubes-dom0-cached 12 M
kernel-latest-develx86_64 1000:6.7.7-1.qubes.fc32
qubes-dom0-cached 15 M
kernel-latest-modules x86_64 1000:6.7.7-1.qubes.fc32
qubes-dom0-cached 76 M
kernel-latest-qubes-vm x86_64 1000:6.7.7-1.qubes.fc32
qubes-dom0-cached 18 M
Upgrading:
qubes-usb-proxy-dom0 noarch 1.2.0-1.fc32
qubes-dom0-cached 25 k
Transaction Summary
Install 4 Packages
Upgrade 1 Package
Total size: 121 M
Is this ok [y/N]: y
Downloading Packages:
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transacti
Re: [qubes-users] Need help after a failed in-place upgrade attempt
Hello 'Haaber',
Am Di., 20. Feb. 2024 um 11:10 Uhr schrieb 'haaber' via qubes-users <
qubes-users@googlegroups.com>:
> ...
>
> all updates go via tor network (sys-whonix) by default. You could click on
> the blue qube widget -> sys-wonix -> run terminal and see if sys-whonix has
> network. But I guess not. Here is why:
>
> https://www.qubes-os.org/doc/firewall/
>
> I wild-guess that you are in a "half-state" where one part of the system
> expects iptables, another one nftables ...
>
> Did you download / start to download new (debian/fedora) Templates or are
> they the "old" ones?
>
> I did not see any other user jump to your help, and I am not good enough
> to fix that alone for you. So honestly, at your place I would
>
> (1) backup data (again)
>
> (2) extract the list of manually installed packages in each of your
> templates and stock them on your backup drive
>
> ("apt-mark showmanual > manual.packages.list" in a terminal is your
> friend, no root priv needed)
>
> (3) re-install a clean 4.2
>
> (4) replay your manual installs of packages in your templates:
>
> "cat manual.packages.list | apt-get install " or something of this
> type should work (run as root)
>
> (5) restore your data.
>
> It's a pain and takes half a day, but I fear that it is, at the end of the
> day, faster than any other solution...
>
> good luck!
>
Thanks a lot !
This is exactly the feedback I was hoping for.
I'll investigate further on my side & will provide an update from my side
before the end of the week ...
With kind regards,
Viktor
--
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/CAAeSrGLY7D08tXkpExUKgmCYYAQj7_TO1hzAijspG%3D2a2i%3DuAg%40mail.gmail.com.
Re: [qubes-users] Need help after a failed in-place upgrade attempt
Hello community, Am Sa., 17. Feb. 2024 um 08:10 Uhr schrieb 'haaber' via qubes-users < > qubes-users@googlegroups.com>: > >> Hi >> > I tried to upgrade my Qubes OS system from 4.1.2 to 4.2.0 using the >> > "qubes-dist-upgrade" script. >> ... >> > >> OK, I am not an expert on THIS question. Some general remarks: the >> network card seems to work, right? So you need to check where the chain >> breaks. >> >> - go to sys-net (open terminal via widget) type ping 8.8.8.8 and see if >> you come out >> > > Working. > > >> - go to sys-firewall (terminal via widget) and do the same. >> > > Working as well. > > >> if these two work, and an app-vm has no network, its config got lost. >> Look at network settings of the corresponding appVM. It should be >> sys-firewall in std setting, apart anon-whonix, of corse which uses >> sys-whonix. >> > > Not working. - I changed the settings from "default (sys-firewall) > (current)" to "sys-firewall" in one App-VM ... > > An additional / new info is, that an update check for 'dom0' does no > longer work ! > > I did not explicitely try that before ... > > Does it make sense to try to just restore 'dom0' as a start ? > Any feedback - or - any other ideas what I could try ? With kind regards, Viktor -- 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/CAAeSrGLtmnRxp4iEK4Y9tMHQ5Sio064P8T-i%2B%2BMFSq5_MPa1gg%40mail.gmail.com.
Re: [qubes-users] Need help after a failed in-place upgrade attempt
Hello 'Haaber', Am Sa., 17. Feb. 2024 um 08:10 Uhr schrieb 'haaber' via qubes-users < qubes-users@googlegroups.com>: > Hi > > I tried to upgrade my Qubes OS system from 4.1.2 to 4.2.0 using the > > "qubes-dist-upgrade" script. > > > > The upgrade failed - and - now the system is in a 'weird' state. > > > > None of the Fedora- or Debian-based VM have 'external / public' > > network access anymore. > > > > The 'anon-whonix' VM however still does have 'external / public' > > network access - and - the update of templates through the Qubes > > Updater is also still working ... > > > OK, I am not an expert on THIS question. Some general remarks: the > network card seems to work, right? So you need to check where the chain > breaks. > > - go to sys-net (open terminal via widget) type ping 8.8.8.8 and see if > you come out > Working. > - go to sys-firewall (terminal via widget) and do the same. > Working as well. > if these two work, and an app-vm has no network, its config got lost. > Look at network settings of the corresponding appVM. It should be > sys-firewall in std setting, apart anon-whonix, of corse which uses > sys-whonix. > Not working. - I changed the settings from "default (sys-firewall) (current)" to "sys-firewall" in one App-VM ... An additional / new info is, that an update check for 'dom0' does no longer work ! I did not explicitely try that before ... Does it make sense to try to just restore 'dom0' as a start ? With kind regards, Viktor -- 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/CAAeSrGJ4swRyu9rY_VD9P0Qr1S8S_9MkytKg-dH%3D1pmw%2BxE2xA%40mail.gmail.com.
[qubes-users] Need help after a failed in-place upgrade attempt
Hello community, I tried to upgrade my Qubes OS system from 4.1.2 to 4.2.0 using the "qubes-dist-upgrade" script. The upgrade failed - and - now the system is in a 'weird' state. None of the Fedora- or Debian-based VM have 'external / public' network access anymore. The 'anon-whonix' VM however still does have 'external / public' network access - and - the update of templates through the Qubes Updater is also still working ... I did perform a backup a backup of all VMs before starting the script - but - would like to skip a new install if possible ! - Any advice / ideas ? With kind regards, Viktor -- 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/ab1202ed-95e9-4b44-b4fb-11a087311141n%40googlegroups.com.
Re: [qubes-users] Update problem with a 'debian-12-minimal' based template
Hello Andrew, Viktor Ransmayr schrieb am Mittwoch, 27. September 2023 um 20:56:59 UTC+2: Am Mi., 27. Sept. 2023 um 08:23 Uhr schrieb Andrew David Wong < a...@qubes-os.org>: On 9/26/23 10:29 PM, Viktor Ransmayr wrote: > ... > Since I have not worked at all with Salt (yet) - and - also have not > 'touched' dom-0 at all, I'd be very grateful for any advice on how to > resolve this probem. It sounds like you might be hitting this bug: https://github.com/QubesOS/qubes-issues/issues/8440 Thanks a lot for this info. - I'll 'monitor' the progress on this issue. Just to confirm, that the update of 'debian-12-minimal' based template is working on my system now as well. Thanks a lot for your support. With kind regards, Viktor -- 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/da7a9772-24f1-4e54-b504-4513a4d4ecebn%40googlegroups.com.
Re: [qubes-users] Update problem with a 'debian-12-minimal' based template
Hello Andrew Am Mi., 27. Sept. 2023 um 08:23 Uhr schrieb Andrew David Wong < a...@qubes-os.org>: > On 9/26/23 10:29 PM, Viktor Ransmayr wrote: > > ... > > > > Since I have not worked at all with Salt (yet) - and - also have not > > 'touched' dom-0 at all, I'd be very grateful for any advice on how to > > resolve this probem. > > It sounds like you might be hitting this bug: > > https://github.com/QubesOS/qubes-issues/issues/8440 Thanks a lot for this info. - I'll 'monitor' the progress on this issue. With kind regards, Viktor -- 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/CAAeSrGJ2oih64Zx6acOkVNK9VwVY1uU0kVdEv7pW992TyXqntA%40mail.gmail.com.
[qubes-users] Update problem with a 'debian-12-minimal' based template
Hello community, I've started to update my Debian-based VMs from 11 to 12. As part of this exercise, I also switched from 'debian-11' to 'debian-12-minimal' as the initial template to clone from. In general I'm quite happy with the results in one working Test-VM. - However, when the system tries to update the new template, I consistently get the following error: Updating debian-12-vrsq Error on updating debian-12-vrsq: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=debian-12-vrsq', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20. debian-12-vrsq: -- _error: Failed to return clean data retcode: 1 stderr: Traceback (most recent call last): File "/var/tmp/.root_dd8a91_salt/salt-call", line 27, in salt_call() File "/var/tmp/.root_dd8a91_salt/pyall/salt/scripts.py", line 437, in salt_call import salt.cli.call File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/call.py", line 3, in import salt.cli.caller File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", line 12, in import salt.channel.client File "/var/tmp/.root_dd8a91_salt/pyall/salt/channel/client.py", line 13, in import salt.crypt File "/var/tmp/.root_dd8a91_salt/pyall/salt/crypt.py", line 26, in import salt.payload File "/var/tmp/.root_dd8a91_salt/pyall/salt/payload.py", line 12, in import salt.loader.context File "/var/tmp/.root_dd8a91_salt/pyall/salt/loader/__init__.py", line 15, in import salt.config File "/var/tmp/.root_dd8a91_salt/pyall/salt/config/__init__.py", line 107, in _DFLT_IPC_WBUFFER = int(_gather_buffer_space() * 0.5) ^^ File "/var/tmp/.root_dd8a91_salt/pyall/salt/config/__init__.py", line 95, in _gather_buffer_space import salt.grains.core File "/var/tmp/.root_dd8a91_salt/pyall/salt/grains/core.py", line 30, in import salt.modules.cmdmod File "/var/tmp/.root_dd8a91_salt/pyall/salt/modules/cmdmod.py", line 32, in import salt.utils.templates File "/var/tmp/.root_dd8a91_salt/pyall/salt/utils/templates.py", line 21, in import salt.utils.http File "/var/tmp/.root_dd8a91_salt/pyall/salt/utils/http.py", line 27, in import salt.ext.tornado.simple_httpclient File "/var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/simple_httpclient.py", line 9, in from salt.ext.tornado.http1connection import HTTP1Connection, HTTP1ConnectionParameters File "/var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/http1connection.py", line 31, in from salt.ext.tornado import iostream File "/var/tmp/.root_dd8a91_salt/pyall/salt/ext/tornado/iostream.py", line 42, in import urllib3.util.ssl_match_hostname ModuleNotFoundError: No module named 'urllib3' [ERROR ] An un-handled exception was caught by Salt's global exception handler: ModuleNotFoundError: No module named 'urllib3' Traceback (most recent call last): File "/var/tmp/.root_dd8a91_salt/salt-call", line 27, in salt_call() File "/var/tmp/.root_dd8a91_salt/pyall/salt/scripts.py", line 437, in salt_call import salt.cli.call File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/call.py", line 3, in import salt.cli.caller File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", line 12, in import salt.channel.client File "/var/tmp/.root_dd8a91_salt/pyall/salt/channel/client.py", line 13, in import salt.crypt File "/var/tmp/.root_dd8a91_salt/pyall/salt/crypt.py", line 26, in import salt.payload File "/var/tmp/.root_dd8a91_salt/pyall/salt/payload.py", line 12, in import salt.loader.context File "/var/tmp/.root_dd8a91_salt/pyall/salt/loader/__init__.py", line 15, in import salt.config File "/var/tmp/.root_dd8a91_salt/pyall/salt/config/__init__.py", line 107, in _DFLT_IPC_WBUFFER = int(_gather_buffer_space() * 0.5) ^^ File "/var/tmp/.root_dd8a91_salt/pyall/salt/config/__init__.py", line 95, in _gather_buffer_space import salt.grains.core File "/var/tmp/.root_dd8a91_salt/pyall/salt/grains/core.py", line 30, in import salt.modules.cmdmod File "/var/tmp/.root_dd8a91_salt/pyall/salt/modules/cmdmod.py", line 32, in import salt.utils.templates File
Re: [qubes-users] No editor at all in 'fedora-36-minimal' template?
Hello Unman, Am So., 9. Okt. 2022 um 15:08 Uhr schrieb 'unman' via qubes-users < qubes-users@googlegroups.com>: > On Sun, Oct 09, 2022 at 05:34:50AM -0700, Viktor Ransmayr wrote: > > Is it correct, that this template does not provide any editor 'package' > at > > all? > > No, there's nano > Thanks a lot. - Don't know why I did not see it myself ... With kind regards, Viktor -- 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/CAAeSrG%2BfP39bWOyuL9ht%3DvSScLdNEmSke8ZhOre%2BT4_hp_828w%40mail.gmail.com.
[qubes-users] No editor at all in 'fedora-36-minimal' template?
Is it correct, that this template does not provide any editor 'package' at all? I'm just wondering, if this is expected - and - I have to add for example 'vim-minimal' myself - or - if there's a specific issue with my installation / setup ... With kind regards, Viktor -- 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/1a966c87-d5c9-4e12-a176-71e6767c78b9n%40googlegroups.com.
[qubes-users] Re: Problems with Timesynchronization
Hello Community, No advice / feedback at all ? Viktor Ransmayr schrieb am Samstag, 23. Juli 2022 um 22:05:39 UTC+2: > Hello community, > > I do have issues with the timesychronization of VMs in my Qubes OS 4.1.1 > system. > > I was reading the information provided in [1] - and - verified that > 'sys-net' is my clock VM. > > However I was not able to resolve my issues ... > > Here are the logs: > > > > [vr@dom0 ~]$ qubes-prefs clockvm > sys-net > [vr@dom0 ~]$ > > > > > > [user@sys-net ~]$ > [user@sys-net ~]$ timedatectl >Local time: Sat 2022-07-23 19:54:36 CEST >Universal time: Sat 2022-07-23 17:54:36 UTC > RTC time: Sat 2022-07-23 17:54:36 > Time zone: Europe/Berlin (CEST, +0200) > System clock synchronized: no > NTP service: inactive > RTC in local TZ: no > [user@sys-net ~]$ > > > > > > [user@sys-net ~]$ > [user@sys-net ~]$ systemctl restart systemd-timesyncd > [user@sys-net ~]$ > [user@sys-net ~]$ > [user@sys-net ~]$ systemctl status systemd-timesyncd > ○ systemd-timesyncd.service - Network Time Synchronization > Loaded: loaded > (/usr/lib/systemd/system/systemd-timesyncd.service; enabled> > Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d > └─30_qubes.conf > Active: inactive (dead) > Condition: start condition failed at Sat 2022-07-23 20:06:48 CEST; > 14s ago > └─ ConditionPathExists=/var/run/qubes-service/clocksync > was not met >Docs: man:systemd-timesyncd.service(8) > lines 1-8/8 (END) > > [user@sys-net ~]$ > > > > > > [user@sys-net ~]$ > [user@sys-net ~]$ cd /var/run/qubes-service > [user@sys-net qubes-service]$ ls > network-manager qubes-network qubes-updates-proxy > qubes-firewall qubes-update-check > [user@sys-net qubes-service]$ > > > > Do you have any advice on how to continue from here - or - what else to > check? > Can you please comment on how it is possible, that "ConditionPathExists=/var/run/qubes-service/clocksync was not met" - and - ideally, how to resolve that issue. With kind regards, Viktor -- 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/28050d33-a4c4-4daf-8372-da94989f7644n%40googlegroups.com.
[qubes-users] Problems with Timesynchronization
Hello community, I do have issues with the timesychronization of VMs in my Qubes OS 4.1.1 system. I was reading the information provided in [1] - and - verified that 'sys-net' is my clock VM. However I was not able to resolve my issues ... Here are the logs: [vr@dom0 ~]$ qubes-prefs clockvm sys-net [vr@dom0 ~]$ [user@sys-net ~]$ [user@sys-net ~]$ timedatectl Local time: Sat 2022-07-23 19:54:36 CEST Universal time: Sat 2022-07-23 17:54:36 UTC RTC time: Sat 2022-07-23 17:54:36 Time zone: Europe/Berlin (CEST, +0200) System clock synchronized: no NTP service: inactive RTC in local TZ: no [user@sys-net ~]$ [user@sys-net ~]$ [user@sys-net ~]$ systemctl restart systemd-timesyncd [user@sys-net ~]$ [user@sys-net ~]$ [user@sys-net ~]$ systemctl status systemd-timesyncd ○ systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled> Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d └─30_qubes.conf Active: inactive (dead) Condition: start condition failed at Sat 2022-07-23 20:06:48 CEST; 14s ago └─ ConditionPathExists=/var/run/qubes-service/clocksync was not met Docs: man:systemd-timesyncd.service(8) lines 1-8/8 (END) [user@sys-net ~]$ [user@sys-net ~]$ [user@sys-net ~]$ cd /var/run/qubes-service [user@sys-net qubes-service]$ ls network-manager qubes-network qubes-updates-proxy qubes-firewall qubes-update-check [user@sys-net qubes-service]$ Do you have any advice on how to continue from here - or - what else to check? With kind regards, Viktor --- [1] https://github.com/Qubes-Community/Contents/blob/master/docs/system/clock-time.md -- 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/9d6644d7-4e4e-491e-a4d2-4a372304bc69n%40googlegroups.com.
[qubes-users] Number of different disposable VMs?
Hello everyone, I'm finishing my consolidation of App- & Template-VMs [1] after upgrading to R4.1. While doing so I realized that there are several '*-dvm' instances - and - it is not clear to me whether individual **disposable VMs** are required for each template type (i.e. Debian, Fedora, Whonix GW & WS). Can someone advice - or - point me to a URI to learn? With kind regards, Viktor --- [1] https://groups.google.com/g/qubes-users/c/gpku3AoioLw -- 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/e76e4f7f-5af6-4b07-924d-381972b26462n%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, Am Do., 16. Juni 2022 um 10:11 Uhr schrieb Demi Marie Obenour < d...@invisiblethingslab.com>: > > Congratulations! I guess you can disregard my last email. Be sure to > update your new template :) > Yes, I'm in the middle of consolidating all my App- & Template-VMs. Thanks a lot for your great support! With kind regards, Viktor -- 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/CAAeSrGKTd3EEhQwzHCuoY41DQRt0UkpmNO953ZTrLboFR0SASA%40mail.gmail.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, The never ending story took an unexpected turn ... Viktor Ransmayr schrieb am Donnerstag, 16. Juni 2022 um 07:34:42 UTC+2: > > It looks like I'm running out of options - and - I an now considering a > new installation from scratch as my only way going forward! > > Or do you still have any other suggestion? > For whatever reason I re-tried to install the 'fedora-35' template - and - succeeded. Based on the 'naming' ( * :4.0.6-202205081759) I initially thought that the repos were again pointing to R4.0 - but - they are pointing to R4.1 :-) See "Log-001" & "Log-002". ### Log-001 from 'dom0' [vr@dom0 ~]$ [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35 Redirecting to 'qvm-template install fedora-35' Downloading 'qubes-template-fedora-35-0:4.0.6-202205081759'... qubes-template-fedora-35-0:4.0.6-202205081759: 100%|▉| 1.75G/1.75G [06:25<00:00, Installing template 'fedora-35'... fedora-35: Importing data [vr@dom0 ~]$ ### Log-002 from 'fedora-35' template [user@fedora-35 ~]$ [user@fedora-35 ~]$ cd /etc/yum.repos.d [user@fedora-35 yum.repos.d]$ [user@fedora-35 yum.repos.d]$ [user@fedora-35 yum.repos.d]$ cat qubes-r4.repo [qubes-vm-r4.1-current] name = Qubes OS Repository for VM (updates) baseurl = https://yum.qubes-os.org/r4.1/current/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 repo_gpgcheck = 1 enabled=1 [qubes-vm-r4.1-current-testing] name = Qubes OS Repository for VM (updates-testing) baseurl = https://yum.qubes-os.org/r4.1/current-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 repo_gpgcheck = 1 enabled=0 [qubes-vm-r4.1-security-testing] name = Qubes OS Repository for VM (security-testing) baseurl = https://yum.qubes-os.org/r4.1/security-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/security-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 repo_gpgcheck = 1 enabled=0 [qubes-vm-r4.1-unstable] name = Qubes OS Repository for VM (unstable) baseurl = https://yum.qubes-os.org/r4.1/unstable/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/unstable/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable gpgcheck = 1 repo_gpgcheck = 1 enabled=0 [user@fedora-35 yum.repos.d]$ ### With kind regards, Viktor -- 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/6cc83641-b7e3-4da0-8194-bb90ee06162cn%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, The never ending story - episode 2 ;-) Demi Marie Obenour schrieb am Mittwoch, 15. Juni 2022 um 18:57:07 UTC+2: > > Don’t use -y, that way you can check what is going to happen before it > does. Also you might want to clone the VM first; feel free to delete > the clone once everything is working. > I cloned the template - and - revised the cmd until no further improvement suggestions were given. Unfortunately w/o success. - Below you find again my notes & logs: ### Notes Clone 'fedora-34' template - and - apply the revised dnf command - Not OK - See "Log-001". * Re-try command with the new additional option suggested - Not OK - See "Log-002". ### Log-001 [user@fedora-34-test ~]$ [user@fedora-34-test ~]$ sudo dnf --refresh --best --allowerasing upgrade Fedora 34 - x86_64 63 kB/s | 21 kB 00:00 Fedora 34 openh264 (From Cisco) - x86_64959 B/s | 989 B 00:01 Fedora 34 - x86_64 - Updates 80 kB/s | 19 kB 00:00 Qubes OS Repository for VM (updates) 16 kB/s | 3.8 kB 00:00 Error: Problem: cannot install the best update candidate for package qubes-gui-agent-4.1.25-1.fc34.x86_64 - problem with installed package qubes-gui-agent-4.1.25-1.fc34.x86_64 - cannot install the best update candidate for package qubes-libvchan-xen-4.0.9-1.fc34.x86_64 - package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libvchan-xen.so()(64bit), but none of the providers can be installed - package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires qubes-libvchan, but none of the providers can be installed - package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed - package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenvchan.so.4.14()(64bit), but none of the providers can be installed - cannot install both xen-libs-4.14.1-7.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64 - cannot install both xen-libs-4.14.5-1.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64 - package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libxengnttab.so.1()(64bit), but none of the providers can be installed - package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libxengnttab.so.1(VERS_1.0)(64bit), but none of the providers can be installed - cannot install the best update candidate for package xen-libs-2001:4.8.5-39.fc34.x86_64 (try to add '--skip-broken' to skip uninstallable packages) [user@fedora-34-test ~]$ ### Log-002 [user@fedora-34-test ~]$ [user@fedora-34-test ~]$ sudo dnf --refresh --best --allowerasing --skip-broken upgrade Fedora 34 - x86_64 75 kB/s | 21 kB 00:00 Fedora 34 openh264 (From Cisco) - x86_643.9 kB/s | 989 B 00:00 Fedora 34 - x86_64 - Updates 82 kB/s | 19 kB 00:00 Qubes OS Repository for VM (updates) 15 kB/s | 3.8 kB 00:00 Error: Problem: cannot install the best update candidate for package qubes-gui-agent-4.1.25-1.fc34.x86_64 - problem with installed package qubes-gui-agent-4.1.25-1.fc34.x86_64 - cannot install the best update candidate for package qubes-libvchan-xen-4.0.9-1.fc34.x86_64 - package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libvchan-xen.so()(64bit), but none of the providers can be installed - package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires qubes-libvchan, but none of the providers can be installed - package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed - package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenvchan.so.4.14()(64bit), but none of the providers can be installed - cannot install both xen-libs-4.14.1-7.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64 - cannot install both xen-libs-4.14.5-1.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64 - package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libxengnttab.so.1()(64bit), but none of the providers can be installed - package qubes-gui-agent-4.1.25-1.fc34.x86_64 requires libxengnttab.so.1(VERS_1.0)(64bit), but none of the providers can be installed - cannot install the best update candidate for package xen-libs-2001:4.8.5-39.fc34.x86_64 [user@fedora-34-test ~]$ ### It looks like I'm running out of options - and - I an now considering a new installation from scratch as my only way going forward! Or do you still have any other suggestion? With kind regards, Viktor -- 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
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, This turns into a never ending story ;-) Demi Marie Obenour schrieb am Dienstag, 14. Juni 2022 um 20:41:32 UTC+2: > > > >> > You were right - but - I have no clue what went wrong & what to do > next > > >> ... > > >> > > >> $ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo > > >> > > >> should fix that > > >> > > > > > > Upgrade of template is still running ... > > > > > > I'll provide another update as soon as it's finished. > > > > > > > It is still running, after more than 10 hours. - This should have > finished > > by now, correct? > > Yes, unless you have a very slow network connection. I recommend using > dnf interactively for this, not Salt; Salt’s lack of progress feedback > will make this extremely frustrating. > I performed the operation you suggested, but it did not succeed either ... Here's the log from dnf: [user@fedora-34 ~]$ [user@fedora-34 ~]$ sudo dnf -y --refresh upgrade Fedora 34 - x86_64 78 kB/s | 21 kB 00:00 Fedora 34 openh264 (From Cisco) - x86_641.0 kB/s | 989 B 00:00 Fedora 34 - x86_64 - Updates 93 kB/s | 20 kB 00:00 Qubes OS Repository for VM (updates) 13 kB/s | 3.8 kB 00:00 Dependencies resolved. Problem 1: package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed - package qubes-libvchan-xen-4.1.7-1.fc34.x86_64 requires libxenvchan.so.4.14()(64bit), but none of the providers can be installed - cannot install both xen-libs-4.14.1-7.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64 - cannot install both xen-libs-4.14.5-1.fc34.x86_64 and xen-libs-2001:4.8.5-39.fc34.x86_64 - cannot install the best update candidate for package qubes-libvchan-xen-4.0.9-1.fc34.x86_64 - problem with installed package xen-libs-2001:4.8.5-39.fc34.x86_64 Problem 2: package qubes-vm-dependencies-4.1.21-1.fc34.noarch requires xen-runtime, but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenguest.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxendevicemodel.so.1()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenlight.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxentoolcore.so.1()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxlutil.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenfsimage.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenhypfs.so.1()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenstat.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenvchan.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxencall.so.1(VERS_1.2)(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenfsimage.so.4.14(libfsimage.so.1.0)(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxengnttab.so.1(VERS_1.2)(64bit), but none of the providers can be installed - package xen-runtime-4.14.1-7.fc34.x86_64 requires libxenhypfs.so.1(VERS_1.0)(64bit), but none of the providers can be installed - package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenctrl.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenguest.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.5-1.fc34.x86_64 requires libxendevicemodel.so.1()(64bit), but none of the providers can be installed - package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenlight.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.5-1.fc34.x86_64 requires libxentoolcore.so.1()(64bit), but none of the providers can be installed - package xen-runtime-4.14.5-1.fc34.x86_64 requires libxlutil.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.5-1.fc34.x86_64 requires libxenfsimage.so.4.14()(64bit), but none of the providers can be installed - package xen-runtime-4.14.5-1.fc34.x86_64 requires
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, Viktor Ransmayr schrieb am Montag, 13. Juni 2022 um 21:14:57 UTC+2: > > On Sun, 12 Jun 2022, 22:59 Demi Marie Obenour, < > de...@invisiblethingslab.com> wrote: > >> >> > You were right - but - I have no clue what went wrong & what to do next >> ... >> >> $ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo >> >> should fix that >> > > Upgrade of template is still running ... > > I'll provide another update as soon as it's finished. > It is still running, after more than 10 hours. - This should have finished by now, correct? Here are my notes & logs: ### Change the template for 'sys-firewall' back from 'debian-11' to 'fedora-34'. * Close all Study-VMs - and - close the affected 'sys-whonix' VM ... ### 2022-06-13 ~ 18:48 (UTC) * Perform the template change - and - get back here ;-) ### 2022-06-13 ~ 18:51 (UTC) Open the 'fedora-34' template & apply the suggested change - OK? - See "Log-002". ### 2022-06-13 ~ 19:00 (UTC) Start the update of 'fedora-34' template suggested by Qubes Updater - See "Log-003". * 2022-06-13 ~ 19:15 (UTC) -> Still ongoing * 2022-06-13 ~ 19:30 (UTC) -> Still ongoing * 2022-06-13 ~ 20:00 (UTC) -> Still ongoing * 2022-06-13 ~ 21:00 (UTC) -> Still ongoing * ... * 2022-06-14 ~ 05:45 (UTC) -> Still ongoing ??? ### Log-002 [user@fedora-34 ~]$ cd /etc/yum.repos.d [user@fedora-34 yum.repos.d]$ cat qubes-r4.repo [qubes-vm-r4.0-current] name = Qubes OS Repository for VM (updates) baseurl = https://yum.qubes-os.org/r4.0/current/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=1 [qubes-vm-r4.0-current-testing] name = Qubes OS Repository for VM (updates-testing) baseurl = https://yum.qubes-os.org/r4.0/current-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.0-security-testing] name = Qubes OS Repository for VM (security-testing) baseurl = https://yum.qubes-os.org/r4.0/security-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/security-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.0-unstable] name = Qubes OS Repository for VM (unstable) baseurl = https://yum.qubes-os.org/r4.0/unstable/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/unstable/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable gpgcheck = 1 enabled=0 [user@fedora-34 yum.repos.d]$ [user@fedora-34 yum.repos.d]$ [user@fedora-34 yum.repos.d]$ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo [user@fedora-34 yum.repos.d]$ [user@fedora-34 yum.repos.d]$ [user@fedora-34 yum.repos.d]$ cat qubes-r4.repo [qubes-vm-r4.1-current] name = Qubes OS Repository for VM (updates) baseurl = https://yum.qubes-os.org/r4.1/current/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=1 [qubes-vm-r4.1-current-testing] name = Qubes OS Repository for VM (updates-testing) baseurl = https://yum.qubes-os.org/r4.1/current-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/current-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.1-security-testing] name = Qubes OS Repository for VM (security-testing) baseurl = https://yum.qubes-os.org/r4.1/security-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/security-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.1-unstable] name = Qubes OS Repository for VM (unstable) baseurl = https://yum.qubes-os.org/r4.1/unstable/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.1/unstable/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, On Sun, 12 Jun 2022, 22:59 Demi Marie Obenour, wrote: > > > You were right - but - I have no clue what went wrong & what to do next > ... > > $ sudo sed -i 's/4\.0/4.1/g' /etc/yum.repos.d/qubes-r4.repo > > should fix that > Upgrade of template is still running ... I'll provide another update as soon as it's finished. With kind regards Viktor > -- 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/CAAeSrGJpXF30vxeDYjTTYpdPfM-QGicFTVZXk2T61ZQNEr6uow%40mail.gmail.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, Am So., 12. Juni 2022 um 18:18 Uhr schrieb Demi Marie Obenour < d...@invisiblethingslab.com>: > > > What is the contents of /etc/yum.repos.d in your fedora-34 template? > > > You might have repositories pointing at the R4.0 repos. > > > > Here's the content: > > > > [user@fedora-34 ~]$ > > [user@fedora-34 ~]$ cd /etc/yum.repos.d > > [user@fedora-34 yum.repos.d]$ ls -all > > total 68 > > drwxr-xr-x 2 root root 4096 May 20 21:05 . > > drwxr-xr-x 114 root root 12288 Jun 12 17:11 .. > > -rw-r--r-- 1 root root 183 Oct 2 2021 adobe-linux-x86_64.repo > > -rw-r--r-- 1 root root 728 Apr 28 2021 > fedora-cisco-openh264.repo > > -rw-r--r-- 1 root root 1344 Apr 28 2021 > fedora-updates-testing.repo > > -rw-r--r-- 1 root root 1286 Apr 28 2021 fedora-updates.repo > > -rw-r--r-- 1 root root 1239 Apr 28 2021 fedora.repo > > -rw-r--r-- 1 root root 191 Oct 2 2021 google-chrome.repo > > -rw-r--r-- 1 root root 1483 May 5 02:00 qubes-r4.repo > > -rw-r--r-- 1 root root 1324 Oct 2 2021 > > rpmfusion-free-updates-testing.repo > > -rw-r--r-- 1 root root 1264 Oct 2 2021 > rpmfusion-free-updates.repo > > -rw-r--r-- 1 root root 1248 Oct 2 2021 rpmfusion-free.repo > > -rw-r--r-- 1 root root 1369 Oct 2 2021 > > rpmfusion-nonfree-updates-testing.repo > > -rw-r--r-- 1 root root 1309 Oct 2 2021 > > rpmfusion-nonfree-updates.repo > > -rw-r--r-- 1 root root 1312 Oct 2 2021 rpmfusion-nonfree.repo > > [user@fedora-34 yum.repos.d]$ > > > > With kind regards, > > Can you check that qubes-r4.repo points to the R4.1 repository and not > the R4.0 repository? The symptoms you are describing are consistent > with it pointing to the R4.0 repository. > Here's the content of this file: [user@fedora-34 yum.repos.d]$ [user@fedora-34 ~]$ cd /etc/yum.repos.d [user@fedora-34 yum.repos.d]$ cat qubes-r4.repo [qubes-vm-r4.0-current] name = Qubes OS Repository for VM (updates) baseurl = https://yum.qubes-os.org/r4.0/current/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=1 [qubes-vm-r4.0-current-testing] name = Qubes OS Repository for VM (updates-testing) baseurl = https://yum.qubes-os.org/r4.0/current-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/current-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.0-security-testing] name = Qubes OS Repository for VM (security-testing) baseurl = https://yum.qubes-os.org/r4.0/security-testing/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/security-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r4.0-unstable] name = Qubes OS Repository for VM (unstable) baseurl = https://yum.qubes-os.org/r4.0/unstable/vm/fc$releasever #baseurl = http://yum.qubesosfasa4zl44o4tws22di6kepyzfeqv3tg4e3ztknltfxqrymdad.onion/r4.0/unstable/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable gpgcheck = 1 enabled=0 [user@fedora-34 yum.repos.d]$ You were right - but - I have no clue what went wrong & what to do next ... With kind regards, Viktor -- 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/CAAeSrG%2BR7KxcsOLY9ORoZO9uH9NTgSO66E_4sTAWM7oRPooG5w%40mail.gmail.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, Demi Marie Obenour schrieb am Sonntag, 12. Juni 2022 um 16:48:52 UTC+2: > > What is the contents of /etc/yum.repos.d in your fedora-34 template? > You might have repositories pointing at the R4.0 repos. > Here's the content: [user@fedora-34 ~]$ [user@fedora-34 ~]$ cd /etc/yum.repos.d [user@fedora-34 yum.repos.d]$ ls -all total 68 drwxr-xr-x 2 root root 4096 May 20 21:05 . drwxr-xr-x 114 root root 12288 Jun 12 17:11 .. -rw-r--r-- 1 root root 183 Oct 2 2021 adobe-linux-x86_64.repo -rw-r--r-- 1 root root 728 Apr 28 2021 fedora-cisco-openh264.repo -rw-r--r-- 1 root root 1344 Apr 28 2021 fedora-updates-testing.repo -rw-r--r-- 1 root root 1286 Apr 28 2021 fedora-updates.repo -rw-r--r-- 1 root root 1239 Apr 28 2021 fedora.repo -rw-r--r-- 1 root root 191 Oct 2 2021 google-chrome.repo -rw-r--r-- 1 root root 1483 May 5 02:00 qubes-r4.repo -rw-r--r-- 1 root root 1324 Oct 2 2021 rpmfusion-free-updates-testing.repo -rw-r--r-- 1 root root 1264 Oct 2 2021 rpmfusion-free-updates.repo -rw-r--r-- 1 root root 1248 Oct 2 2021 rpmfusion-free.repo -rw-r--r-- 1 root root 1369 Oct 2 2021 rpmfusion-nonfree-updates-testing.repo -rw-r--r-- 1 root root 1309 Oct 2 2021 rpmfusion-nonfree-updates.repo -rw-r--r-- 1 root root 1312 Oct 2 2021 rpmfusion-nonfree.repo [user@fedora-34 yum.repos.d]$ With kind regards, Viktor -- 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/fcfef94e-5d8b-436f-9df8-c98b6df2084en%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Steve, stevenlc...@gmail.com schrieb am Samstag, 11. Juni 2022 um 17:52:19 UTC+2: > > It looks to me that your current sys-firewall template is not up to date > for your current R4.1 version, or just broken. If you have any other > templates on your system (e.g. debian-11, fc35-minimal, fc35-xfce ) you > might want to try switching sys-firewall to something else and then try to > use qvm-template to download a working template of the f35 flavor. > Your suggestion was obviously the next step I tried. - Unfortunately again it did not improve anything :-( Here are my logs & notes: ### Change the template for 'sys-firewall' from 'fedora-34' to 'debian-11'. * Close all Study-VMs - and - close the affected 'sys-whonix' VM ... * Perform the template change ... * Try now to download the new 'fedora-35' templates - Not OK - See "Log-001". ### Log-001 [vr@dom0 ~]$ [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35 Redirecting to 'qvm-template install fedora-35' [Qrexec] /bin/sh: 0: cannot open /etc/qubes-rpc/qubes.TemplateSearch: No such file ERROR: qrexec call 'qubes.TemplateSearch' failed. [vr@dom0 ~]$ [vr@dom0 ~]$ [vr@dom0 ~]$ sudo qubes-dom0-update --clean --console --show-output Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time... 0 files removed Unable to detect release version (use '--releasever' to specify release version) Fedora 32 - x86_64 - Updates6.3 MB/s | 35 MB 00:05 Fedora 32 - x86_64 6.3 MB/s | 63 MB 00:09 Qubes Dom0 Repository (updates) 572 kB/s | 3.8 MB 00:06 Last metadata expiration check: 0:00:05 ago on Sun Jun 12 09:48:13 2022. Dependencies resolved. Nothing to do. Complete! No packages downloaded No updates available [vr@dom0 ~]$ ### Thanks a lot for your support in trying to find a solution for my problem. With kind regards, Viktor -- 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/5b35079a-abba-4671-a732-8cddfc0a0842n%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, Demi Marie Obenour schrieb am Samstag, 11. Juni 2022 um 19:03:38 UTC+2: > > Do you have any further suggestions, what I could still try? > > You should be able to manually change your DNF repositories in > sys-firewall’s template. “dnf --best --refresh distro-sync” should then > take care of the rest, unless I have missed something. > This sounded like a very simple exercise, however it did not improve anything :-( Here are my logs & notes: ### I have not changed the templates for the 'sys- * ' VMs - and - I have also not yet created any specific 'sys- * ' VMs. * Therfore this needs to be applied to the 'fedora-34' template - OK - See "Log-001". * Close all Study-VMs - and - close / restart the affected 'sys- * ' VMs ... ### 2022-06-12 ~ 08:30 (UTC) Try now to download the new 'fedora-35' templates again - OK? - See "Log-002". ### Log-001 [user@fedora-34 ~]$ [user@fedora-34 ~]$ dnf --best --refresh distro-sync Error: This command has to be run with superuser privileges (under the root user on most systems). [user@fedora-34 ~]$ sudo dnf --best --refresh distro-sync Fedora 34 - x86_64 73 kB/s | 21 kB 00:00 Fedora 34 openh264 (From Cisco) - x86_643.9 kB/s | 989 B 00:00 Fedora 34 - x86_64 - Updates 18 kB/s | 19 kB 00:01 Qubes OS Repository for VM (updates) 14 kB/s | 3.8 kB 00:00 Qubes OS Repository for VM (updates)121 kB/s | 210 kB 00:01 Dependencies resolved. PackageArchitecture VersionRepository Size Downgrading: dkms noarch 3.0.2-1.fc34 updates 58 k Transaction Summary Downgrade 1 Package Total download size: 58 k Is this ok [y/N]: y Downloading Packages: dkms-3.0.2-1.fc34.noarch.rpm194 kB/s | 58 kB 00:00 Total37 kB/s | 58 kB 00:01 Running transaction check Transaction check succeeded. Running transaction test Transaction test succeeded. Running transaction Preparing: 1/1 Downgrading : dkms-3.0.2-1.fc34.noarch 1/2 Running scriptlet: dkms-3.0.2-1.fc34.noarch 1/2 Running scriptlet: dkms-3.0.3-1.fc34.noarch 2/2 Cleanup : dkms-3.0.3-1.fc34.noarch 2/2 Running scriptlet: dkms-3.0.3-1.fc34.noarch 2/2 Verifying: dkms-3.0.2-1.fc34.noarch 1/2 Verifying: dkms-3.0.3-1.fc34.noarch 2/2 Notifying dom0 about installed applications Downgraded: dkms-3.0.2-1.fc34.noarch Complete! [user@fedora-34 ~]$ ### Log-002 [vr@dom0 ~]$ [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35 Redirecting to 'qvm-template install fedora-35' [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory ERROR: qrexec call 'qubes.TemplateSearch' failed. [vr@dom0 ~]$ [vr@dom0 ~]$ [vr@dom0 ~]$ sudo qubes-dom0-update Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time... No updates available [vr@dom0 ~]$ sudo qubes-dom0-update --clean --console --show-output Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time... warning: Converting database from bdb_ro to sqlite backend 0 files removed Fedora 32 - x86_64 6.8 MB/s | 70 MB 00:10 Fedora 32 - x86_64 - Updates6.2 MB/s | 30 MB 00:04 Qubes Dom0 Repository (updates) 947 kB/s | 3.8 MB 00:04 Last metadata expiration check: 0:00:03 ago on Sun Jun 12 08:40:15 2022. Dependencies resolved. Nothing to do. Complete! No packages downloaded No updates available [vr@dom0 ~]$ ### I really do appreciate your personal support - as well as - the one from the Qubes OS community in general. I'm using these troubles ( I'm having / making ;-) to learn more about Qubes OS - and - hope that eventually I'll be able to give back myself ... With kind regards, Viktor -- You received this message because you are subscribed to the
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Demi, Demi Marie Obenour schrieb am Freitag, 10. Juni 2022 um 23:42:57 UTC+2: > > >> I've not modified anything - and - the "Global Settings" look OK. > > >> > > >> I tried to open a console in 'sys-firewall' - but - can't login :-( > > >> > > >> I had expected that I could do so, using my credentials, i.e. user > 'vr' > > >> plus my password ... > > >> > > At least in the default setup (no sys-gui-gpu), your credentials are > specific to dom0. Everything else will let you log in on the console > as any valid user without a password. “root” will give you a root > shell, while “user” will give you a shell as the same user that GUI > programs run as. > Thanks for that clear explanation. > > > I tried to open a console in 'sys-firewall' - and - could not login. > > > > > > However, I (obviously) could open a terminal in 'sys-firewall' ... > > > > > > Here's the content of /etc/qubes-rpc/ : > > > > > > [user@sys-firewall ~]$ cd /etc/qubes-rpc/ > > > [user@sys-firewall qubes-rpc]$ ls > > > qubes.Backup qubes.PdfConvert qubes.SuspendPostAll > > > qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre > > > qubes.DetachPciDevice qubes.ResizeDisk qubes.SuspendPreAll > > > qubes.Filecopy qubes.Restore qubes.USB > > > qubes.GetAppmenus qubes.SaltLinuxVM qubes.USBAttach > > > qubes.GetDate qubes.SelectDirectory qubes.USBDetach > > > qubes.GetImageRGBA qubes.SelectFile qubes.UpdatesProxy > > > qubes.Gpg qubes.SetDateTime qubes.VMRootShell > > > qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell > > > qubes.InstallUpdatesGUI qubes.ShowInTerminal qubes.WaitForSession > > > qubes.OpenInVM qubes.StartApp > > > qubes.OpenURL qubes.SuspendPost > > > [user@sys-firewall qubes-rpc]$ > > > > > > > With Fedora 34 having reached EOL now, is there anything else I can do, > > other than a complete new installation of Qubes OS R4.1 ? > > Installing “qubes-core-agent-dom0-updates” in sys-firewall’s template > should fix the problem. > I checked which 'qubes-core' packages are installed in the 'sys-firewall' VM on my system. Here are the results: [user@sys-firewall ~]$ [user@sys-firewall ~]$ dnf list --installed | grep qubes-core qubes-core-agent.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-dom0-updates.x86_644.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-nautilus.x86_644.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-network-manager.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-networking.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-passwordless-root.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-qrexec.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current qubes-core-agent-systemd.x86_64 4.0.65-1.fc34 @qubes-vm-r4.0-current [user@sys-firewall ~]$ So the package is installed - but - it is on version '4.0.65-1.fc34'. - That does not look right to me ... Do you have any further suggestions, what I could still try? Or should I just wait until the dev-team will release Qubes OS version 4.1.1? With kind regards, Viktor -- 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/d82121f8-a944-4707-892b-952cb1505dfen%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello user 'catacombs', Catacombs schrieb am Freitag, 10. Juni 2022 um 14:56:48 UTC+2: > > HI, I am not an extremely knowledgeable Qubes user, but, I did not want > your post to go on like no one cared. I am pretty sure the developers do > care, they just need to spend their time working on --- stuff. And that > might include exactly what will be helpful to you. > > I had some problems installing and using Fedora 35, and then updating it > later. Sigh. > > When I originally installed Qubes 4.1, I chose the option to update over > Tor. Used to be I needed to start the Tor Browser for that to work. If > nothing else, Tor Browser downloads really slowly. I once started to > download an iso of like a gigabyte, and it would take hours. I am > suggesting that in some cases, trying to download can have timing issues > where some things drop out. And I can guess the system set up by our > Qubes developers is not supposed to do that. and I can not prove that it > does. Just when it rains here. My connection hiccups. I am just > tolerant and try again. > > I like the solution I think the developers are working on right now. > > https://github.com/QubesOS/qubes-issues/issues/7544 > > Which explains itself. > Thnaks for making me aware about the planned release of Qubes OS 4.1.1. With kind regards, Viktor -- 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/b0f8b444-e0f7-4ad4-ada6-6c51f3c0b150n%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello Qubes Community, Viktor Ransmayr schrieb am Montag, 30. Mai 2022 um 11:31:56 UTC+2: > Viktor Ransmayr schrieb am Montag, 30. Mai 2022 um 10:37:56 UTC+2: > >> stevenlc...@gmail.com schrieb am Sonntag, 29. Mai 2022 um 20:45:29 UTC+2: >> >>> On Sun, May 29, 2022 at 4:39 AM Viktor Ransmayr >>> wrote: >>> >>>> stevenlc...@gmail.com schrieb am Samstag, 28. Mai 2022 um 21:54:40 >>>> UTC+2: >>>> >>>>> >>>>> Thanks for your quick reply! >>>> >>>> However, when I try to list the available templates using the >>>> 'qvm-template' command, I get the same error message: >>>> >>>> [vr@dom0 ~]$ qvm-template list >>>> [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file >>>> or directory >>>> ERROR: qrexec call 'qubes.TemplateSearch' failed. >>>> [vr@dom0 ~]$ >>>> >>>> >>>> >>> I just checked my own system and ran a python3 trace on the command. The >>> file /etc/qubes-rpc/qubes.TemplateSearch should be on the sys-firewall >>> , assuming the default configuration. If you use a different OS or changed >>> your "Dom0 update qube" in the "Global Settings" for dom0 updates then that >>> update VM may not have this file installed. I would start by looking >>> there. >>> >> >> I've not modified anything - and - the "Global Settings" look OK. >> >> I tried to open a console in 'sys-firewall' - but - can't login :-( >> >> I had expected that I could do so, using my credentials, i.e. user 'vr' >> plus my password ... >> > > I tried to open a console in 'sys-firewall' - and - could not login. > > However, I (obviously) could open a terminal in 'sys-firewall' ... > > Here's the content of /etc/qubes-rpc/ : > > [user@sys-firewall ~]$ cd /etc/qubes-rpc/ > [user@sys-firewall qubes-rpc]$ ls > qubes.Backup qubes.PdfConvertqubes.SuspendPostAll > qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre > qubes.DetachPciDevicequbes.ResizeDiskqubes.SuspendPreAll > qubes.Filecopy qubes.Restore qubes.USB > qubes.GetAppmenusqubes.SaltLinuxVM qubes.USBAttach > qubes.GetDatequbes.SelectDirectory qubes.USBDetach > qubes.GetImageRGBA qubes.SelectFilequbes.UpdatesProxy > qubes.Gpgqubes.SetDateTime qubes.VMRootShell > qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell > qubes.InstallUpdatesGUI qubes.ShowInTerminalqubes.WaitForSession > qubes.OpenInVM qubes.StartApp > qubes.OpenURLqubes.SuspendPost > [user@sys-firewall qubes-rpc]$ > With Fedora 34 having reached EOL now, is there anything else I can do, other than a complete new installation of Qubes OS R4.1 ? With kind regards, Viktor -- 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/dba459a1-2ecf-41a1-9b51-dc93e20dca67n%40googlegroups.com.
Re: [qubes-users] Re: How to check that an 'in-place upgrade' from Qubes R4.0 to R4.1 was successful?
Hello Demi & Qubes Community, Viktor Ransmayr schrieb am Donnerstag, 2. Juni 2022 um 22:09:41 UTC+2: > Demi Marie Obenour schrieb am Donnerstag, 2. Juni 2022 um 15:08:17 UTC+2: > >> On Thu, Jun 02, 2022 at 03:24:50AM -0700, Viktor Ransmayr wrote: >> > Demi Marie Obenour schrieb am Donnerstag, 2. Juni 2022 um 01:18:35 >> UTC+2: >> > > On Wed, Jun 01, 2022 at 10:03:14PM +, Qubes OS Users Mailing List >> > > wrote: >> > > > On Tue, May 31, 2022 at 11:54:24PM -0700, Viktor Ransmayr wrote: >> > > > > I've performed the same task today - and - the same 14 packages >> were >> > > > > removed again ... >> > > > > >> > > > > So it's clear now that something went wrong with my 'in-place >> upgrade' >> > > ! >> > > > > >> > > > > Anything that I could try, beside a completely fresh installation >> of >> > > Qubes >> > > > > OS R4.1 ? >> > > > >> > > > I've had similar issues: >> > > > https://github.com/QubesOS/qubes-issues/issues/7503 >> > > > >> > > > Maybe try some of the ideas suggested there? >> > > >> > > The Python 2 packages should be safe to remove, unless I have missed >> > > something. >> > > >> > >> > It's unclear to me, why I should ... >> > >> > If I would manually delete those packages, would they not get >> re-installed >> > the next day? >> >> In dom0, this is leftover cruft from R4.0. It serves no purpose in >> R4.1. My R4.1 dom0 does not even have a Python 2 interpreter. >> > > OK, I'll try - and - will report back tomorrow, when another 'dom0' update > notification will be sent. > Thanks, it looks like the problem of packages, which were reported for removal, is resolved. Now the only problem that remains, is that ... * I can not install the Fedora 35 templates - and - that ... * I still have doubts about the status of my system, after the 'in-place upgrade' operation ;-) With kind regards, Viktor -- 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/fafeec73-d544-4d3a-bd53-80f2eefb7a11n%40googlegroups.com.
Re: [qubes-users] Re: How to check that an 'in-place upgrade' from Qubes R4.0 to R4.1 was successful?
Hello Demi, Demi Marie Obenour schrieb am Donnerstag, 2. Juni 2022 um 15:08:17 UTC+2: > On Thu, Jun 02, 2022 at 03:24:50AM -0700, Viktor Ransmayr wrote: > > Hello Demi, > > > > Demi Marie Obenour schrieb am Donnerstag, 2. Juni 2022 um 01:18:35 > UTC+2: > > > > > On Wed, Jun 01, 2022 at 10:03:14PM +, Qubes OS Users Mailing List > > > wrote: > > > > On Tue, May 31, 2022 at 11:54:24PM -0700, Viktor Ransmayr wrote: > > > > > I've performed the same task today - and - the same 14 packages > were > > > > > removed again ... > > > > > > > > > > So it's clear now that something went wrong with my 'in-place > upgrade' > > > ! > > > > > > > > > > Anything that I could try, beside a completely fresh installation > of > > > Qubes > > > > > OS R4.1 ? > > > > > > > > I've had similar issues: > > > > https://github.com/QubesOS/qubes-issues/issues/7503 > > > > > > > > Maybe try some of the ideas suggested there? > > > > > > The Python 2 packages should be safe to remove, unless I have missed > > > something. > > > > > > > It's unclear to me, why I should ... > > > > If I would manually delete those packages, would they not get > re-installed > > the next day? > > In dom0, this is leftover cruft from R4.0. It serves no purpose in > R4.1. My R4.1 dom0 does not even have a Python 2 interpreter. > OK, I'll try - and - will report back tomorrow, when another 'dom0' update notification will be sent. With kind regards, Viktor -- 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/bacac066-35b1-45ff-8687-57ffd4ab3099n%40googlegroups.com.
Re: [qubes-users] Re: How to check that an 'in-place upgrade' from Qubes R4.0 to R4.1 was successful?
Hello Demi, Demi Marie Obenour schrieb am Donnerstag, 2. Juni 2022 um 01:18:35 UTC+2: > On Wed, Jun 01, 2022 at 10:03:14PM +, Qubes OS Users Mailing List > wrote: > > On Tue, May 31, 2022 at 11:54:24PM -0700, Viktor Ransmayr wrote: > > > I've performed the same task today - and - the same 14 packages were > > > removed again ... > > > > > > So it's clear now that something went wrong with my 'in-place upgrade' > ! > > > > > > Anything that I could try, beside a completely fresh installation of > Qubes > > > OS R4.1 ? > > > > I've had similar issues: > > https://github.com/QubesOS/qubes-issues/issues/7503 > > > > Maybe try some of the ideas suggested there? > > The Python 2 packages should be safe to remove, unless I have missed > something. > It's unclear to me, why I should ... If I would manually delete those packages, would they not get re-installed the next day? Or asked differently: If they are not needed in R4.1 / Fedora 32 for dom0, why have they been included in the first place? With kind regards, Viktor -- 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/d094f220-7642-435e-9775-d8fc2207f049n%40googlegroups.com.
Re: [qubes-users] Re: How to check that an 'in-place upgrade' from Qubes R4.0 to R4.1 was successful?
Hello user 'tetrahedras', tetra...@danwin1210.de schrieb am Donnerstag, 2. Juni 2022 um 00:03:42 UTC+2: > On Tue, May 31, 2022 at 11:54:24PM -0700, Viktor Ransmayr wrote: > >I've performed the same task today - and - the same 14 packages were > >removed again ... > > > >So it's clear now that something went wrong with my 'in-place upgrade' ! > > > >Anything that I could try, beside a completely fresh installation of > Qubes > >OS R4.1 ? > > I've had similar issues: > https://github.com/QubesOS/qubes-issues/issues/7503 > Thanks for sharing this info! - It does look like my issue is the same / very similar ... > Maybe try some of the ideas suggested there? > Which one? - After reading all comments, I do agree with your last statement / summary. - See * https://github.com/QubesOS/qubes-issues/issues/7503#issuecomment-1125152541 As you can see from my Logs: * Update VM is 'sys-firewall' -> which is using the 'fedora-34' template With kind regards, Viktor -- 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/b7817c8d-b450-41be-b4ce-601028fb0d15n%40googlegroups.com.
[qubes-users] Re: How to check that an 'in-place upgrade' from Qubes R4.0 to R4.1 was successful?
Hello Qubes Community, Viktor Ransmayr schrieb am Dienstag, 31. Mai 2022 um 08:53:29 UTC+2: > I have reported problems installing the new Fedora 35 templates late last > week [1] - and - also reported in the thread, that the 'in-place upgrade' > of my system from 4.0 to 4.1 was only two weeks ago. > > One additional thing that I noticed today, is that a dom0 update does not > install any new packages - but - for the second(?) time only deletes 14 (?) > packages. > > Yesterday I was not able to collect the precise info from the Update VM, > but today I succeeded. - Here's the output: > > > [vr@dom0 ~]$ > [vr@dom0 ~]$ sudo qubes-dom0-update --clean --console --show-output > Using sys-firewall as UpdateVM to download updates for Dom0; this may > take some time... > warning: Converting database from bdb_ro to sqlite backend > 25 files removed > Fedora 32 - x86_64 5.2 MB/s | 70 MB > 00:13 > Fedora 32 - x86_64 - Updates4.1 MB/s | 30 MB > 00:07 > Qubes Dom0 Repository (updates) 2.0 MB/s | 3.8 MB > 00:01 > Last metadata expiration check: 0:00:02 ago on Tue May 31 07:48:22 > 2022. > Dependencies resolved. > > > Package ArchVersion > RepositorySize > > > Removing dependent packages: > python2-backports_abc noarch 0.5-1.fc25 @System > 30 k > python2-futures noarch 3.1.1-1.fc25@System > 91 k > python2-lxmlx86_64 4.1.1-1.fc25@System >4.5 M > python2-msgpack x86_64 0.4.8-1.fc25@System >276 k > python2-nosenoarch 1.3.7-11.fc25 @System >1.1 M > python2-pycurl x86_64 7.43.0-6.fc25 @System >891 k > python2-pygpgme x86_64 0.3-18.fc25 @System >306 k > python2-pysocks noarch 1.6.7-1.fc25@System > 79 k > python2-requestsnoarch 2.10.0-4.fc25 @System >369 k > python2-singledispatch noarch 3.4.0.3-5.fc25 @System > 46 k > python2-systemd x86_64 234-5.1.fc25@System >263 k > python2-tornado x86_64 4.4.2-1.fc25@System >3.9 M > python2-urllib3 noarch 1.15.1-3.fc25 @System >443 k > python2-zmq x86_64 15.3.0-2.fc25 @System >1.5 M > > Transaction Summary > > > Remove 14 Packages > > Freed space: 14 M > DNF will only download packages for the transaction. > Complete! > No packages downloaded > No updates available > [vr@dom0 ~]$ > > I've performed the same task today - and - the same 14 packages were removed again ... So it's clear now that something went wrong with my 'in-place upgrade' ! Anything that I could try, beside a completely fresh installation of Qubes OS R4.1 ? With kind regards, Viktor -- 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/0b3b9279-f0f1-4c54-ad94-1493de4480a4n%40googlegroups.com.
[qubes-users] How to check that an 'in-place upgrade' from Qubes R4.0 to R4.1 was successful?
Hello Qubes Community, I have reported problems installing the new Fedora 35 templates late last week [1] - and - also reported in the thread, that the 'in-place upgrade' of my system from 4.0 to 4.1 was only two weeks ago. One additional thing that I noticed today, is that a dom0 update does not install any new packages - but - for the second(?) time only deletes 14 (?) packages. Yesterday I was not able to collect the precise info from the Update VM, but today I succeeded. - Here's the output: [vr@dom0 ~]$ [vr@dom0 ~]$ sudo qubes-dom0-update --clean --console --show-output Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time... warning: Converting database from bdb_ro to sqlite backend 25 files removed Fedora 32 - x86_64 5.2 MB/s | 70 MB 00:13 Fedora 32 - x86_64 - Updates4.1 MB/s | 30 MB 00:07 Qubes Dom0 Repository (updates) 2.0 MB/s | 3.8 MB 00:01 Last metadata expiration check: 0:00:02 ago on Tue May 31 07:48:22 2022. Dependencies resolved. Package ArchVersion Repository Size Removing dependent packages: python2-backports_abc noarch 0.5-1.fc25 @System 30 k python2-futures noarch 3.1.1-1.fc25@System 91 k python2-lxmlx86_64 4.1.1-1.fc25@System 4.5 M python2-msgpack x86_64 0.4.8-1.fc25@System 276 k python2-nosenoarch 1.3.7-11.fc25 @System 1.1 M python2-pycurl x86_64 7.43.0-6.fc25 @System 891 k python2-pygpgme x86_64 0.3-18.fc25 @System 306 k python2-pysocks noarch 1.6.7-1.fc25@System 79 k python2-requestsnoarch 2.10.0-4.fc25 @System 369 k python2-singledispatch noarch 3.4.0.3-5.fc25 @System 46 k python2-systemd x86_64 234-5.1.fc25@System 263 k python2-tornado x86_64 4.4.2-1.fc25@System 3.9 M python2-urllib3 noarch 1.15.1-3.fc25 @System 443 k python2-zmq x86_64 15.3.0-2.fc25 @System 1.5 M Transaction Summary Remove 14 Packages Freed space: 14 M DNF will only download packages for the transaction. Complete! No packages downloaded No updates available [vr@dom0 ~]$ Now finally my question again: Is there a way to test that the upgrade from Qubes R4.0 to R4.1 was complete - and - successful? With kind regards, Viktor --- [1] https://groups.google.com/g/qubes-users/c/gpku3AoioLw -- 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/093a5516-564a-4757-b4ed-ebf9ef917ffdn%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello everyone, A small but important clarification ! Viktor Ransmayr schrieb am Montag, 30. Mai 2022 um 10:37:56 UTC+2: > Hello slcoleman & Qubes Community, > > stevenlc...@gmail.com schrieb am Sonntag, 29. Mai 2022 um 20:45:29 UTC+2: > >> On Sun, May 29, 2022 at 4:39 AM Viktor Ransmayr >> wrote: >> >>> stevenlc...@gmail.com schrieb am Samstag, 28. Mai 2022 um 21:54:40 >>> UTC+2: >>> >>>> >>>> Thanks for your quick reply! >>> >>> However, when I try to list the available templates using the >>> 'qvm-template' command, I get the same error message: >>> >>> [vr@dom0 ~]$ qvm-template list >>> [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file >>> or directory >>> ERROR: qrexec call 'qubes.TemplateSearch' failed. >>> [vr@dom0 ~]$ >>> >>> >>> >> I just checked my own system and ran a python3 trace on the command. The >> file /etc/qubes-rpc/qubes.TemplateSearch should be on the sys-firewall >> , assuming the default configuration. If you use a different OS or changed >> your "Dom0 update qube" in the "Global Settings" for dom0 updates then that >> update VM may not have this file installed. I would start by looking >> there. >> > > I've not modified anything - and - the "Global Settings" look OK. > > I tried to open a console in 'sys-firewall' - but - can't login :-( > > I had expected that I could do so, using my credentials, i.e. user 'vr' > plus my password ... > I tried to open a console in 'sys-firewall' - and - could not login. However, I (obviously) could open a terminal in 'sys-firewall' ... Here's the content of /etc/qubes-rpc/ : [user@sys-firewall ~]$ cd /etc/qubes-rpc/ [user@sys-firewall qubes-rpc]$ ls qubes.Backup qubes.PdfConvertqubes.SuspendPostAll qubes.ConnectTCP qubes.PostInstall qubes.SuspendPre qubes.DetachPciDevicequbes.ResizeDiskqubes.SuspendPreAll qubes.Filecopy qubes.Restore qubes.USB qubes.GetAppmenusqubes.SaltLinuxVM qubes.USBAttach qubes.GetDatequbes.SelectDirectory qubes.USBDetach qubes.GetImageRGBA qubes.SelectFilequbes.UpdatesProxy qubes.Gpgqubes.SetDateTime qubes.VMRootShell qubes.GpgImportKey qubes.SetMonitorLayout qubes.VMShell qubes.InstallUpdatesGUI qubes.ShowInTerminalqubes.WaitForSession qubes.OpenInVM qubes.StartApp qubes.OpenURLqubes.SuspendPost [user@sys-firewall qubes-rpc]$ With kind regards, Viktor -- 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/aa4bd9f5-8ec0-459a-8678-5ce12dc8f07an%40googlegroups.com.
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello slcoleman & Qubes Community, stevenlc...@gmail.com schrieb am Sonntag, 29. Mai 2022 um 20:45:29 UTC+2: > On Sun, May 29, 2022 at 4:39 AM Viktor Ransmayr > wrote: > >> stevenlc...@gmail.com schrieb am Samstag, 28. Mai 2022 um 21:54:40 UTC+2: >> >>> >>> Thanks for your quick reply! >> >> However, when I try to list the available templates using the >> 'qvm-template' command, I get the same error message: >> >> [vr@dom0 ~]$ qvm-template list >> [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file >> or directory >> ERROR: qrexec call 'qubes.TemplateSearch' failed. >> [vr@dom0 ~]$ >> >> >> > I just checked my own system and ran a python3 trace on the command. The > file /etc/qubes-rpc/qubes.TemplateSearch should be on the sys-firewall , > assuming the default configuration. If you use a different OS or changed > your "Dom0 update qube" in the "Global Settings" for dom0 updates then that > update VM may not have this file installed. I would start by looking > there. > I've not modified anything - and - the "Global Settings" look OK. I tried to open a console in 'sys-firewall' - but - can't login :-( I had expected that I could do so, using my credentials, i.e. user 'vr' plus my password ... FYI-#1: I have performed an 'in-place-upgrade' from 4.0 to 4.1 a little bit over a week ago - and - did not notice any issues, other than this one ... FYI-#2: Here are the installed packages from dom0: xen_version: 4.14.5 Linux 5.10.112-1.fc32.qubes.x86_64 Installed Packages: grub2-qubes-theme.x86_64 5.14.4-2.fc32 kernel-qubes-vm.x86_64 1000:5.4.156-1.fc25.qubes kernel-qubes-vm.x86_64 1000:5.4.190-1.fc25.qubes kernel-qubes-vm.x86_64 1000:5.10.112-1.fc32.qubes python2-qubesadmin.noarch 4.0.32-1.fc25 python2-qubesimgconverter.x86_64 4.0.31-1.fc25 python3-qubesadmin.noarch 4.1.23-1.fc32 python3-qubesdb.x86_644.1.13-1.fc32 python3-qubesimgconverter.x86_64 4.1.16-1.fc32 qubes-anaconda-addon.noarch 4.1.8-1.fc32 qubes-artwork.noarch 4.1.12-1.fc32 qubes-artwork-plymouth.noarch 4.1.12-1.fc32 qubes-audio-daemon.x86_64 4.1.21-1.fc32 qubes-audio-dom0.x86_64 4.1.21-1.fc32 qubes-core-admin-addon-whonix.noarch 4.1.1-1.fc32 qubes-core-admin-client.noarch4.1.23-1.fc32 qubes-core-dom0.noarch4.1.27-1.fc32 qubes-core-dom0-linux.x86_64 4.1.21-1.fc32 qubes-core-dom0-linux-kernel-install.x86_64 4.1.21-1.fc32 qubes-core-qrexec.x86_64 4.1.18-1.fc32 qubes-core-qrexec-dom0.x86_64 4.1.18-1.fc32 qubes-core-qrexec-libs.x86_64 4.1.18-1.fc32 qubes-db.x86_64 4.1.13-1.fc32 qubes-db-dom0.x86_64 4.1.13-1.fc32 qubes-db-libs.x86_64 4.1.13-1.fc32 qubes-desktop-linux-common.noarch 4.1.12-1.fc32 qubes-desktop-linux-manager.noarch4.1.14-1.fc32 qubes-dist-upgrade.noarch 4.0.6-1.fc25 qubes-gpg-split-dom0.x86_64 2.0.59-1.fc32 qubes-gui-daemon.x86_64 4.1.21-1.fc32 qubes-gui-dom0.x86_64 4.1.21-1.fc32 qubes-img-converter-dom0.x86_64 1.2.11-1.fc32 qubes-input-proxy.x86_64 1.0.26-1.fc32 qubes-input-proxy-receiver.x86_64 1.0.26-1.fc32 qubes-libvchan-xen.x86_64 4.1.7-1.fc32 qubes-manager.noarch 4.1.23-1.fc32 qubes-menus.noarch4.1.12-1.fc32 qubes-mgmt-salt.noarch4.1.14-1.fc32 qubes-mgmt-salt-admin-tools.noarch4.1.14-1.fc32 qubes-mgmt-salt-base.noarch 4.1.4-1.fc32 qubes-mgmt-salt-base-config.noarch4.1.1-1.fc32 qubes-mgmt-salt-base-overrides-libs.noarch4.0.2-1.fc25 qubes-mgmt-salt-base-topd.noarch 4.1.3-1.fc32 qubes-mgmt-salt-config.noarch 4.1.14-1.fc32 qubes-mgmt-salt-dom0.noarch 4.1.14-1.fc32 qubes-mgmt-salt-dom0-qvm.noarch 4.1.4-1.fc32 qubes-mgmt-salt-dom0-update.noarch4.1.8-
Re: [qubes-users] Problems with announced Fedora 35 templates
Hello slcoleman, stevenlc...@gmail.com schrieb am Samstag, 28. Mai 2022 um 21:54:40 UTC+2: > > On Sat, May 28, 2022, 3:28 PM Viktor Ransmayr > wrote: > >> Hello Qubes Community, >> >> I run into a problem already in the very first step of the standard >> installation method: >> >> If I perform "sudo qubes-dom0-update qubes-template-fedora-35" in a >> 'dom0' terminal, I receive the following error msg: >> >> [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35 >> Redirecting to 'qvm-template install fedora-35' >> [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or >> directory >> ERROR: qrexec call 'qubes.TemplateSearch' failed. >> [vr@dom0 ~]$ >> >> My Qubes R4.1 system so far had two 'dom0' updates, which successfully >> finished using the Qubes Updater ... >> >> If I try it manually, I always receive the following feedback: >> >> [vr@dom0 ~]$ >> [vr@dom0 ~]$ sudo qubes-dom0-update >> Using sys-firewall as UpdateVM to download updates for Dom0; this may >> take some time... >> No updates available >> [vr@dom0 ~]$ >> >> Any ideas on why the template is not found - and - what I should >> additionally check on my system? >> >> > I reported a similar problem a few days ago. At the time the f35 templates > were not appearing on some indexes and the devs were looking into it. > > I just used a browser to download the rpm's from itl and installed them > locally. > > Note : You should be using qvm-template command with R4.1, which is why > the forwarding message. > Thanks for your quick reply! However, when I try to list the available templates using the 'qvm-template' command, I get the same error message: [vr@dom0 ~]$ qvm-template list [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory ERROR: qrexec call 'qubes.TemplateSearch' failed. [vr@dom0 ~]$ With kind regards, Viktor -- 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/e401d5aa-3837-4beb-bd23-1e8dcc6853b8n%40googlegroups.com.
[qubes-users] Problems with announced Fedora 35 templates
Hello Qubes Community, I run into a problem already in the very first step of the standard installation method: If I perform "sudo qubes-dom0-update qubes-template-fedora-35" in a 'dom0' terminal, I receive the following error msg: [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-35 Redirecting to 'qvm-template install fedora-35' [Qrexec] /bin/sh: /etc/qubes-rpc/qubes.TemplateSearch: No such file or directory ERROR: qrexec call 'qubes.TemplateSearch' failed. [vr@dom0 ~]$ My Qubes R4.1 system so far had two 'dom0' updates, which successfully finished using the Qubes Updater ... If I try it manually, I always receive the following feedback: [vr@dom0 ~]$ [vr@dom0 ~]$ sudo qubes-dom0-update Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time... No updates available [vr@dom0 ~]$ Any ideas on why the template is not found - and - what I should additionally check on my system? With kind regards, Viktor -- 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/5b11cb95-eedc-42f6-acd8-ebf77d5a3159n%40googlegroups.com.
Re: [qubes-users] Re: Qubes Update does not work for Whonix 16 templates ...
Hello awokd, awokd schrieb am Samstag, 20. November 2021 um 17:47:44 UTC+1: > Viktor Ransmayr: > > > I don't want to adjust the time for the two Whonix templates manually to > > the (wrong?) CET values, whenever an update is necessary. > > > > I don't think I had this issue with Whonix 15 & believe it only started > > with Whonix 16. > > > > Do you have any ideas or suggestions? > > Check dom0's clockvm with "qubes-prefs" in a terminal. It's probably > sys-net. Yes it is. Here are the complete preferences: [vr@dom0 ~]$ qubes-prefs check_updates_vm D True clockvm - sys-net default_dispvm- fedora-34-dvm default_kernel- 5.4.143-1.fc25 default_netvm - sys-firewall default_pool D lvm default_pool_kernel - linux-kernel default_pool_private D lvm default_pool_root D lvm default_pool_volatile D lvm default_qrexec_timeoutD 60 default_shutdown_timeout D 60 default_template - fedora-34 management_dispvm - default-mgmt-dvm stats_intervalD 3 updatevm - sys-firewall [vr@dom0 ~]$ Confirm the timezone and time are set correctly inside sys-net > (or your clockvm if different). Here are the results of 'timedatectl': [user@sys-net ~]$ timedatectl Local time: Sat 2021-11-20 18:34:11 CET Universal time: Sat 2021-11-20 17:34:11 UTC RTC time: Sat 2021-11-20 17:34:11 Time zone: Europe/Berlin (CET, +0100) System clock synchronized: no NTP service: inactive RTC in local TZ: no [user@sys-net ~]$ If that doesn't do it, and you can > afford it, might try a fresh install of 4.1rc2, and making sure to set > the correct timezone on install. Hard to know which time zone setting is > incorrect. > A check with / upgrade to 4.1rc2 is not an option for me. - At least not in November ... With kind regards, Viktor -- 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/b929b00b-c159-4c55-a60b-4f13f239eaffn%40googlegroups.com.
[qubes-users] Re: Qubes Update does not work for Whonix 16 templates ...
Viktor Ransmayr schrieb am Sonntag, 7. November 2021 um 13:07:14 UTC+1: > I've installed Whonix 16 on my Qubes OS R4.0 system - and - have switched > 'sys-whonix' to 'whonix-gw-16' as well as 'anon-whonix' to 'whonix-ws-16'. > > Everything seems to work fine - but - Qubes Updater reports that updates > are available for 'whonix-[gw | ws]-16' but always fails to update the > templates with error msgs similar to > > ### > > Updating whonix-gw-16 > > Error on updating whonix-gw-16: Command '['sudo', 'qubesctl', > '--skip-dom0', '--targets=whonix-gw-16', '--show-output', 'state.sls', > 'update.qubes-vm']' returned non-zero exit status 20 > whonix-gw-16: > -- > ID: update > Function: pkg.uptodate > Result: False >Comment: E: Release file for tor+ > https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease is > not valid yet (invalid for another 14min 36s). Updates for this repository > will not be applied. >Started: 11:15:16.396556 > Duration: 8366.294 ms >Changes: > -- > ID: notify-updates > Function: cmd.run > Name: /usr/lib/qubes/upgrades-status-notify > Result: False >Comment: Command "/usr/lib/qubes/upgrades-status-notify" run >Started: 11:15:24.765086 > Duration: 2514.791 ms >Changes: > -- > pid: > 1782 > retcode: > 100 > stderr: > stdout: > > Summary for whonix-gw-16 > > Succeeded: 0 (changed=1) > Failed:2 > > Total states run: 2 > Total run time: 10.881 s > > Updating whonix-ws-16 > > Error on updating whonix-ws-16: Command '['sudo', 'qubesctl', > '--skip-dom0', '--targets=whonix-ws-16', '--show-output', 'state.sls', > 'update.qubes-vm']' returned non-zero exit status 20 > whonix-ws-16: > -- > ID: update > Function: pkg.uptodate > Result: False >Comment: E: Release file for tor+ > https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease is > not valid yet (invalid for another 16min 48s). Updates for this repository > will not be applied. >Started: 11:13:10.907970 > Duration: 2607.219 ms >Changes: > -- > ID: notify-updates > Function: cmd.run > Name: /usr/lib/qubes/upgrades-status-notify > Result: False >Comment: Command "/usr/lib/qubes/upgrades-status-notify" run >Started: 11:13:13.517469 > Duration: 2907.295 ms >Changes: > -- > pid: > 1789 > retcode: > 100 > stderr: > stdout: > > Summary for whonix-ws-16 > > Succeeded: 0 (changed=1) > Failed:2 > > Total states run: 2 > Total run time: 5.515 s > > ### > > What are the recommended steps to resolve this issue? > > With kind regards, > > Viktor > > PS: I obviously tried this several time - but - the error msg stays the > same - only - with changing "invalid for ..." times ... > This time I have new information on the reported issue. - Template updates were reported for 'fedora-33' as well as 'whonix-gw-16'. I started Qubes Updater w/o adjusting the time in both templates. - The update of 'fedora-33' succeeded, while 'whonix-gw-16' failed. Relevant log from 'fedora-33': Updating fedora-33 fedora-33: -- ID: dnf-and-rpm Function: pkg.installed Result: True Comment: All specified packages are already installed and are at the desired version Started: 17:24:48.153995 Duration: 1836.538 ms Changes: Relevant log from 'whonix-gw-16': Updating whonix-gw-16 Error on updating whonix-gw-16: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=whonix-gw-16', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20 whonix-gw-16: -- ID: update Function: pkg.uptodate Result: False Comment: E: Release file for tor+https://fasttrack
Re: [qubes-users] Qubes Update does not work for Whonix 16 templates ...
Am Di., 9. Nov. 2021 um 22:19 Uhr schrieb TheGardner : > managed the download on 4.0.4 in the last days without any issues. Just > did it with the qubes-dom0-update command and the enablerepo=community > switch. No other commands or work. It just went through like it always do > with downloads & installs of new templates. > Sorry, if I couldn't help more. > > viktor@gmail.com schrieb am Dienstag, 9. November 2021 um 14:49:04 > UTC-5: > >> Viktor Ransmayr schrieb am Sonntag, 7. November 2021 um 19:53:54 UTC+1: >> >>> Hello 'unman', >>> >>> unman schrieb am Sonntag, 7. November 2021 um 15:36:50 UTC+1: >>> >>>> On Sun, Nov 07, 2021 at 04:07:13AM -0800, Viktor Ransmayr wrote: >>>> > I've installed Whonix 16 on my Qubes OS R4.0 system - and - have >>>> switched >>>> > 'sys-whonix' to 'whonix-gw-16' as well as 'anon-whonix' to >>>> 'whonix-ws-16'. >>>> > >>>> > Everything seems to work fine - but - Qubes Updater reports that >>>> updates >>>> > are available for 'whonix-[gw | ws]-16' but always fails to update >>>> the >>>> > templates with error msgs similar to >>>> > >>>> > ### >>>> > >>>> > Updating whonix-gw-16 >>>> > >>>> > Error on updating whonix-gw-16: Command '['sudo', 'qubesctl', >>>> > '--skip-dom0', '--targets=whonix-gw-16', '--show-output', >>>> 'state.sls', >>>> > 'update.qubes-vm']' returned non-zero exit status 20 >>>> > whonix-gw-16: >>>> > -- >>>> > ID: update >>>> > Function: pkg.uptodate >>>> > Result: False >>>> > Comment: E: Release file for >>>> > tor+ >>>> https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease >>>> > is not valid yet (invalid for another 14min 36s). Updates for this >>>> > repository will not be applied. >>>> > Started: 11:15:16.396556 >>>> > Duration: 8366.294 ms >>>> > Changes: >>>> > -- >>>> > ID: notify-updates >>>> > Function: cmd.run >>>> > Name: /usr/lib/qubes/upgrades-status-notify >>>> > Result: False >>>> > Comment: Command "/usr/lib/qubes/upgrades-status-notify" run >>>> > Started: 11:15:24.765086 >>>> > Duration: 2514.791 ms >>>> > Changes: >>>> > -- >>>> > pid: >>>> > 1782 >>>> > retcode: >>>> > 100 >>>> > stderr: >>>> > stdout: >>>> > >>>> > Summary for whonix-gw-16 >>>> > >>>> > Succeeded: 0 (changed=1) >>>> > Failed: 2 >>>> > >>>> > Total states run: 2 >>>> > Total run time: 10.881 s >>>> > >>>> > Updating whonix-ws-16 >>>> > >>>> > Error on updating whonix-ws-16: Command '['sudo', 'qubesctl', >>>> > '--skip-dom0', '--targets=whonix-ws-16', '--show-output', >>>> 'state.sls', >>>> > 'update.qubes-vm']' returned non-zero exit status 20 >>>> > whonix-ws-16: >>>> > -- >>>> > ID: update >>>> > Function: pkg.uptodate >>>> > Result: False >>>> > Comment: E: Release file for >>>> > tor+ >>>> https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease >>>> > is not valid yet (invalid for another 16min 48s). Updates for this >>>> > repository will not be applied. >>>> > Started: 11:13:10.907970 >>>> > Duration: 2607.219 ms >>>> > Changes: >>>> > -- >>>> > ID: notify-updates >>>> > Function: cmd.run >>>> > Name: /usr/lib/qubes/upgrades-status-notify >>>> > Result: False >>>> > Comment: Command "/usr/lib/qubes/upgrades-status-notify" run >>>> > Started: 11:13:13.517469 >>>> > Duration: 2907.295 ms >>>> > Changes: >>>> > -- >>>> > pid: >>>> > 1789 >>>> > retcode: >>>> > 100 >>>> > stderr: >>>> > stdout: >>>> > >>>> > Summary for whonix-ws-16 >>>> > >>>> &
Re: [qubes-users] Qubes Update does not work for Whonix 16 templates ...
Hello 'unman', unman schrieb am Sonntag, 7. November 2021 um 15:36:50 UTC+1: > On Sun, Nov 07, 2021 at 04:07:13AM -0800, Viktor Ransmayr wrote: > > I've installed Whonix 16 on my Qubes OS R4.0 system - and - have > switched > > 'sys-whonix' to 'whonix-gw-16' as well as 'anon-whonix' to > 'whonix-ws-16'. > > > > Everything seems to work fine - but - Qubes Updater reports that updates > > are available for 'whonix-[gw | ws]-16' but always fails to update the > > templates with error msgs similar to > > > > ### > > > > Updating whonix-gw-16 > > > > Error on updating whonix-gw-16: Command '['sudo', 'qubesctl', > > '--skip-dom0', '--targets=whonix-gw-16', '--show-output', 'state.sls', > > 'update.qubes-vm']' returned non-zero exit status 20 > > whonix-gw-16: > > -- > > ID: update > > Function: pkg.uptodate > > Result: False > > Comment: E: Release file for > > tor+ > https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease > > is not valid yet (invalid for another 14min 36s). Updates for this > > repository will not be applied. > > Started: 11:15:16.396556 > > Duration: 8366.294 ms > > Changes: > > -- > > ID: notify-updates > > Function: cmd.run > > Name: /usr/lib/qubes/upgrades-status-notify > > Result: False > > Comment: Command "/usr/lib/qubes/upgrades-status-notify" run > > Started: 11:15:24.765086 > > Duration: 2514.791 ms > > Changes: > > -- > > pid: > > 1782 > > retcode: > > 100 > > stderr: > > stdout: > > > > Summary for whonix-gw-16 > > > > Succeeded: 0 (changed=1) > > Failed: 2 > > > > Total states run: 2 > > Total run time: 10.881 s > > > > Updating whonix-ws-16 > > > > Error on updating whonix-ws-16: Command '['sudo', 'qubesctl', > > '--skip-dom0', '--targets=whonix-ws-16', '--show-output', 'state.sls', > > 'update.qubes-vm']' returned non-zero exit status 20 > > whonix-ws-16: > > -- > > ID: update > > Function: pkg.uptodate > > Result: False > > Comment: E: Release file for > > tor+ > https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease > > is not valid yet (invalid for another 16min 48s). Updates for this > > repository will not be applied. > > Started: 11:13:10.907970 > > Duration: 2607.219 ms > > Changes: > > -- > > ID: notify-updates > > Function: cmd.run > > Name: /usr/lib/qubes/upgrades-status-notify > > Result: False > > Comment: Command "/usr/lib/qubes/upgrades-status-notify" run > > Started: 11:13:13.517469 > > Duration: 2907.295 ms > > Changes: > > -- > > pid: > > 1789 > > retcode: > > 100 > > stderr: > > stdout: > > > > Summary for whonix-ws-16 > > > > Succeeded: 0 (changed=1) > > Failed: 2 > > > > Total states run: 2 > > Total run time: 5.515 s > > > > ### > > > > What are the recommended steps to resolve this issue? > > > > With kind regards, > > > > Viktor > > > > PS: I obviously tried this several time - but - the error msg stays the > > same - only - with changing "invalid for ..." times ... > > > > Fix the time on your update qube,( and possibly your target). It is, as > you can see, wrong. > Thanks a lot for your feedback! - Using 'timedatectl set-time ...' for 'whonix-[gw | ws]-16' did resolve the issue. I started to read more on this topic now - but - did not (yet) find best practice recommendations on how to ensure that AppVMs & TemplateVMs are time-synced automatically, when they are started. Do you have any recommendation? With kind regards, Viktor -- 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/56c69f16-55cb-4450-9724-bdf00c6810dan%40googlegroups.com.
[qubes-users] Qubes Update does not work for Whonix 16 templates ...
I've installed Whonix 16 on my Qubes OS R4.0 system - and - have switched 'sys-whonix' to 'whonix-gw-16' as well as 'anon-whonix' to 'whonix-ws-16'. Everything seems to work fine - but - Qubes Updater reports that updates are available for 'whonix-[gw | ws]-16' but always fails to update the templates with error msgs similar to ### Updating whonix-gw-16 Error on updating whonix-gw-16: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=whonix-gw-16', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20 whonix-gw-16: -- ID: update Function: pkg.uptodate Result: False Comment: E: Release file for tor+https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease is not valid yet (invalid for another 14min 36s). Updates for this repository will not be applied. Started: 11:15:16.396556 Duration: 8366.294 ms Changes: -- ID: notify-updates Function: cmd.run Name: /usr/lib/qubes/upgrades-status-notify Result: False Comment: Command "/usr/lib/qubes/upgrades-status-notify" run Started: 11:15:24.765086 Duration: 2514.791 ms Changes: -- pid: 1782 retcode: 100 stderr: stdout: Summary for whonix-gw-16 Succeeded: 0 (changed=1) Failed:2 Total states run: 2 Total run time: 10.881 s Updating whonix-ws-16 Error on updating whonix-ws-16: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=whonix-ws-16', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20 whonix-ws-16: -- ID: update Function: pkg.uptodate Result: False Comment: E: Release file for tor+https://fasttrack.debian.net/debian/dists/bullseye-fasttrack/InRelease is not valid yet (invalid for another 16min 48s). Updates for this repository will not be applied. Started: 11:13:10.907970 Duration: 2607.219 ms Changes: -- ID: notify-updates Function: cmd.run Name: /usr/lib/qubes/upgrades-status-notify Result: False Comment: Command "/usr/lib/qubes/upgrades-status-notify" run Started: 11:13:13.517469 Duration: 2907.295 ms Changes: -- pid: 1789 retcode: 100 stderr: stdout: Summary for whonix-ws-16 Succeeded: 0 (changed=1) Failed:2 Total states run: 2 Total run time: 5.515 s ### What are the recommended steps to resolve this issue? With kind regards, Viktor PS: I obviously tried this several time - but - the error msg stays the same - only - with changing "invalid for ..." times ... -- 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/0ba6fc35-5cc7-4bac-a1bc-7ed2d3c8ba52n%40googlegroups.com.
Re: [qubes-users] Question related to Qubes Updater of dom0
unman schrieb am Sonntag, 11. Juli 2021 um 12:52:51 UTC+2: > On Sun, Jul 11, 2021 at 01:13:04AM -0700, Viktor Ransmayr wrote: > > Can you please elaborate a bit more! - What were you looking for? > > I was looking for a problem with the update process. > There has been a long thread in the forum about why you should use the > updated tool instead of updating locally. In brief, it's used to apply > other things (e.g. configuration changes) besides raw updates. > Looks like I should subscribe to the new forum ! > > > - Why is 'qubes updater' notified in the first place, if nothing needs > > to be done? - OR - > > > > > > - If something got done 'locally', why isn't at least a minimal > > information about the performed activity returned? > > > > This inconsistency / uncertainty is confusing (at least to me ). > > Because the updater does more than just update, it is possible that > there are things not applied. > > What's the situation here? What Qubes version are you on? Qubes version is 4.0 - for more info I've attached the info from 'qubes manager' below. > Do you mean > that dom0 is always marked a requiring updates in the updater tool? > No, not always. - But lately multiple updates have been requested for dom-0, which I performed - but- the system did not provide any change info ... Is it still showing that updates are required? > No, currently there is no notification active about a required update for dom-0. With kind regards, Viktor xen_version: 4.8.5-34.fc25 Linux 5.4.125-1.fc25.qubes.x86_64 Installed Packages: kernel-qubes-vm.x86_64 1000:5.4.107-1.fc25.qubes kernel-qubes-vm.x86_64 1000:5.4.120-1.fc25.qubes kernel-qubes-vm.x86_64 1000:5.4.125-1.fc25.qubes python2-qubesadmin.noarch 4.0.32-1.fc25 python2-qubesimgconverter.x86_64 4.0.31-1.fc25 python3-qubesadmin.noarch 4.0.32-1.fc25 python3-qubesdb.x86_644.0.16-1.fc25 python3-qubesimgconverter.x86_64 4.0.34-1.fc25 qubes-anaconda-addon.noarch 4.0.11-1.fc25 qubes-artwork.noarch 4.0.1-2.fc25 qubes-core-admin-addon-whonix.noarch 4.0.2-1.fc25 qubes-core-admin-client.noarch4.0.32-1.fc25 qubes-core-dom0.x86_644.0.58-1.fc25 qubes-core-dom0-linux.x86_64 4.0.30-1.fc25 qubes-core-dom0-linux-kernel-install.x86_64 qubes-db.x86_64 4.0.16-1.fc25 qubes-db-dom0.x86_64 4.0.16-1.fc25 qubes-db-libs.x86_64 4.0.16-1.fc25 qubes-desktop-linux-common.noarch 4.0.22-1.fc25 qubes-desktop-linux-manager.noarch4.0.25-1.fc25 qubes-gpg-split-dom0.x86_64 2.0.50-1.fc25 qubes-gui-dom0.x86_64 4.0.13-1.fc25 qubes-img-converter-dom0.x86_64 1.2.10-1.fc25 qubes-input-proxy.x86_64 1.0.23-1.fc25 qubes-input-proxy-receiver.x86_64 1.0.23-1.fc25 qubes-libvchan-xen.x86_64 4.0.9-1.fc25 qubes-manager.noarch 4.0.45-1.fc25 qubes-menus.noarch4.0.22-1.fc25 qubes-mgmt-salt.noarch4.0.26-1.fc25 qubes-mgmt-salt-admin-tools.noarch4.0.26-1.fc25 qubes-mgmt-salt-base.noarch 4.0.4-1.fc25 qubes-mgmt-salt-base-config.noarch4.0.2-1.fc25 qubes-mgmt-salt-base-overrides.noarch 4.0.2-1.fc25 qubes-mgmt-salt-base-overrides-libs.noarch qubes-mgmt-salt-base-topd.noarch 4.0.2-1.fc25 qubes-mgmt-salt-config.noarch 4.0.26-1.fc25 qubes-mgmt-salt-dom0.noarch 4.0.26-1.fc25 qubes-mgmt-salt-dom0-qvm.noarch 4.0.10-1.fc25 qubes-mgmt-salt-dom0-update.noarch4.0.10-1.fc25 qubes-mgmt-salt-dom0-virtual-machines.noarch qubes-pdf-converter-dom0.x86_64 2.1.12-1.fc25 qubes-release.noarch 4.0-10 qubes-release-notes.noarch4.0-10 qubes-rpm-oxide.x86_640.2.2-1.fc25 qubes-template-debian-10.noarch 4.0.1-201910230150 qubes-template-fedora-33.noarch 4.0.6-202012100255 qubes-template-whonix-gw-15.noarch4.0.1-202003070901 qubes-template-whonix-ws-15.noarch4.
Re: [qubes-users] Question related to Qubes Updater of dom0
Hello unman, unman schrieb am Samstag, 10. Juli 2021 um 16:57:43 UTC+2: > Looks good to me > Can you please elaborate a bit more! - What were you looking for? - Why is 'qubes updater' notified in the first place, if nothing needs to be done? - OR - - If something got done 'locally', why isn't at least a minimal information about the performed activity returned? This inconsistency / uncertainty is confusing (at least to me ). With kind regards, Viktor -- 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/b57c9589-9d33-4e4c-afa7-c1556364268fn%40googlegroups.com.
Re: [qubes-users] Question related to Qubes Updater of dom0
unman schrieb am Samstag, 10. Juli 2021 um 14:48:58 UTC+2: > On Fri, Jul 09, 2021 at 12:22:29PM -0700, Viktor Ransmayr wrote: > > Viktor Ransmayr schrieb am Donnerstag, 8. Juli 2021 um 23:11:33 UTC+2 > > > > > Am Do., 8. Juli 2021 um 22:05 Uhr schrieb Mike Keehan < > mi...@keehan.net>: > > > > > >> On 7/8/21 7:27 PM, Viktor Ransmayr wrote: > > >> > Hello Qubes Community, > > >> > > > >> > I have received multiple requests to accept an update of 'dom0' > content > > >> > lately. > > >> > > > >> > The only info I've received after performing these updates has > been: > > >> > > > >> > ### > > >> > > > >> > Updating dom0 > > >> > > > >> > local: > > >> > -- > > >> > > > >> > ### > > >> > > > >> > Can someone provide an explanation, a link to read more about it - > or - > > >> > should I be worried? > > >> > > >> Have you "blacklisted" any packages. I get the same messages as above > > >> but that is because I have told RPM to ignore the intel video driver > > >> update - it hangs my screen after a random time interval. > > >> > > > > > > No I have not "blacklisted" any packages. > > > > > > > Same behaviour happened again just now! > > > > Is there any way to get more information (i.e. announcements, logs, > > notifications etc.)? > > What's the result of running `sudo qubes-dom0-update` in dom0 terminal? > Here's the log: [vr@dom0 ~]$ sudo qubes-dom0-update Using sys-firewall as UpdateVM to download updates for Dom0; this may take some time... warning: Converting database from bdb to sqlite backend Warning: Enforcing GPG signature check globally as per active RPM security policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message) Fedora 25 - x86_64 7.7 MB/s | 50 MB 00:06 Fedora 25 - x86_64 - Updates7.3 MB/s | 24 MB 00:03 Qubes Dom0 Repository (updates) 604 kB/s | 2.4 MB 00:04 determining the fastest mirror (14 hosts).. done.-- B/s | 0 B --:-- ETA Qubes Templates repository 4.9 kB/s | 5.9 kB 00:01 Dependencies resolved. Nothing to do. Complete! No packages downloaded Qubes OS Repository for Dom0 24 MB/s | 29 kB 00:00 [vr@dom0 ~]$ Viktor -- 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/40cf09e9-47be-455c-b854-557a45022709n%40googlegroups.com.
Re: [qubes-users] Question related to Qubes Updater of dom0
Viktor Ransmayr schrieb am Donnerstag, 8. Juli 2021 um 23:11:33 UTC+2 > Am Do., 8. Juli 2021 um 22:05 Uhr schrieb Mike Keehan : > >> On 7/8/21 7:27 PM, Viktor Ransmayr wrote: >> > Hello Qubes Community, >> > >> > I have received multiple requests to accept an update of 'dom0' content >> > lately. >> > >> > The only info I've received after performing these updates has been: >> > >> > ### >> > >> > Updating dom0 >> > >> > local: >> > -- >> > >> > ### >> > >> > Can someone provide an explanation, a link to read more about it - or - >> > should I be worried? >> >> Have you "blacklisted" any packages. I get the same messages as above >> but that is because I have told RPM to ignore the intel video driver >> update - it hangs my screen after a random time interval. >> > > No I have not "blacklisted" any packages. > Same behaviour happened again just now! Is there any way to get more information (i.e. announcements, logs, notifications etc.)? Viktor -- 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/4a120e50-e62b-429b-99fd-3f1c285f409cn%40googlegroups.com.
Re: [qubes-users] Question related to Qubes Updater of dom0
Hello Mike, Am Do., 8. Juli 2021 um 22:05 Uhr schrieb Mike Keehan : > On 7/8/21 7:27 PM, Viktor Ransmayr wrote: > > Hello Qubes Community, > > > > I have received multiple requests to accept an update of 'dom0' content > > lately. > > > > The only info I've received after performing these updates has been: > > > > ### > > > > Updating dom0 > > > > local: > > -- > > > > ### > > > > Can someone provide an explanation, a link to read more about it - or - > > should I be worried? > > Have you "blacklisted" any packages. I get the same messages as above > but that is because I have told RPM to ignore the intel video driver > update - it hangs my screen after a random time interval. > No I have not "blacklisted" any packages. With kind regards, Viktor -- 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/CAAeSrGKQDm%3DmzjEXe4rW-BV_nAtdmicv4aVb%3DA3LbVn_36qBSA%40mail.gmail.com.
[qubes-users] Question related to Qubes Updater of dom0
Hello Qubes Community, I have received multiple requests to accept an update of 'dom0' content lately. The only info I've received after performing these updates has been: ### Updating dom0 local: -- ### Can someone provide an explanation, a link to read more about it - or - should I be worried? With kind regards, Viktor -- 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/6b5d9d70-5c5e-420e-aaf4-f7c81ef63d0en%40googlegroups.com.
Re: [qubes-users] Re: New App Menu Survey! 5-10 minutes of your time (from Nina)
Hello Nina, Am Di., 4. Mai 2021 um 03:59 Uhr schrieb Nina Alter : > Hi Viktor! > > No sound. My only recommendation is to enlarge them to full-screen size. > > Thank you for your interest in helping us with feedback! > Thanks for your clarification! Somehow, probably as part of the expected narrative around the two main characters, I automatically assumed / wished for sound as well ;-) With kind regards, Viktor -- 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/CAAeSrGJR0DxbaPdT-YrFsurfR83C2wLsJ_7EO32o-AgEhQ3MKg%40mail.gmail.com.
Re: [qubes-users] Re: New App Menu Survey! 5-10 minutes of your time (from Nina)
Hello Andrew, Am Di., 4. Mai 2021 um 03:22 Uhr schrieb Andrew David Wong : > On 5/2/21 9:13 AM, Viktor Ransmayr wrote: > > Hello community, > > > > a...@qubes-os.org schrieb am Samstag, 1. Mai 2021 um 12:58:17 UTC+2: > > > >> > >> I bring the following message from Nina Eleanor Alter, our resident > >> expert on design and user research: > >> > >> - > >> > >> Hello! This survey will only remain live for 14 days, so please take a > >> few moments, if you are so inclined, to let us know your thoughts on our > >> work so far on designing a new App Menu specific to Qubes OS. Former > >> users, new users, longtime users, technical users, and non-technical > >> users -- we would love to hear from as many folks as possible who have > >> used or are currently using Qubes. > >> > >> https://survey.qubes-os.org/index.php?r=survey/index=434783=en > >> > > > > Am I the only one having problems with the two videos about Bessie ( > > https://vimeo.com/542041258 ) & Jackie ( https://vimeo.com/541946756 )? > > > > What do I have to do to enable sound for MP4 content in Firefox? > > > > With kind regards, > > > > Viktor > > > > It is not entirely clear to me whether there is supposed to be sound in > the videos. As far as I can tell, I do not think there is supposed to be > any. > Thanks for your feedback, that I've expected to much. With kind regards, Viktor -- 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/CAAeSrGLGeAbq-j8JndiAK4Y4F9FAmNBjOAfp_WX0cC4wSuurGw%40mail.gmail.com.
[qubes-users] Re: New App Menu Survey! 5-10 minutes of your time (from Nina)
Hello community, a...@qubes-os.org schrieb am Samstag, 1. Mai 2021 um 12:58:17 UTC+2: > > I bring the following message from Nina Eleanor Alter, our resident > expert on design and user research: > > - > > Hello! This survey will only remain live for 14 days, so please take a > few moments, if you are so inclined, to let us know your thoughts on our > work so far on designing a new App Menu specific to Qubes OS. Former > users, new users, longtime users, technical users, and non-technical > users -- we would love to hear from as many folks as possible who have > used or are currently using Qubes. > > https://survey.qubes-os.org/index.php?r=survey/index=434783=en > Am I the only one having problems with the two videos about Bessie ( https://vimeo.com/542041258 ) & Jackie ( https://vimeo.com/541946756 )? What do I have to do to enable sound for MP4 content in Firefox? With kind regards, Viktor -- 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/ca4dfa70-4884-4670-a590-0e66a97d833bn%40googlegroups.com.
Re: [qubes-users] Help for Qubes updater problem with Fedora-32?
vic...@gmail.com schrieb am Sonntag, 20. Dezember 2020 um 18:08:45 UTC+1: > On Sat, 2020-12-19 at 07:15 -0800, Viktor Ransmayr wrote: > > vic...@gmail.com schrieb am Samstag, 19. Dezember 2020 um 14:26:10 > > UTC+1: > > > On Sat, 2020-12-19 at 02:01 -0800, Viktor Ransmayr wrote: > > > > Since this morning Qubes Updater does not succeed updating the > > > > 'fedora-32' template multiple times, while it did work for > > > 'whonix- > > > > gw-15' w/o any issues ... > > > > > > > > The log, that is returned, does not provide me enough information > > > to > > > > decide what to do next - or - how to resolve this issue: > > > > > > Try running an upgrade from Qubes Manager, or start a terminal in > > > that template and run dnf upgrade, see what that tells you. > > > > Performing the upgrade via Qubes Manager did resolve the issue > > immediately. - Thanks a lot for your help! > > > > Out of curiosity: Why are the actions 'triggered / used' by Qubes > > Manager (QM) and Qubes Updater (QU) different? > > Qubes Manager, as far as I know, launches a terminal, in which it > launches system tools, be it apt or dnf or something else. How is it > determined which one to use, I wasn't yet able to find. > Qubes Updater uses qubesctl, which under the hood uses salt, with it's > tools and libraries. > @viq: Thanks a lot for this info! Re-reading the available documentation I now also found the FAQ entry [1], where this procedure / workaround is described ... Turning this into something positive: I'm confident, that I'll remember what to do, the next time a similar situation occurs ;-) With kind regards, Viktor --- [1] https://www.qubes-os.org/faq/#my-dom0-andor-templatevm-update-stalls-when-attempting-to-update-via-the-gui-tool-what-should-i-do -- 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/3467755b-475f-4e34-aeac-d0bbe169cc7dn%40googlegroups.com.
Re: [qubes-users] Help for Qubes updater problem with Fedora-32?
vic...@gmail.com schrieb am Samstag, 19. Dezember 2020 um 14:26:10 UTC+1: > On Sat, 2020-12-19 at 02:01 -0800, Viktor Ransmayr wrote: > > Since this morning Qubes Updater does not succeed updating the > > 'fedora-32' template multiple times, while it did work for 'whonix- > > gw-15' w/o any issues ... > > > > The log, that is returned, does not provide me enough information to > > decide what to do next - or - how to resolve this issue: > > Try running an upgrade from Qubes Manager, or start a terminal in that > template and run dnf upgrade, see what that tells you. > Performing the upgrade via Qubes Manager did resolve the issue immediately. - Thanks a lot for your help! Out of curiosity: Why are the actions 'triggered / used' by Qubes Manager (QM) and Qubes Updater (QU) different? With kind regards, Viktor -- 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/4dd4b91c-2732-4b53-8ab1-c4f4e4fffea5n%40googlegroups.com.
[qubes-users] Help for Qubes updater problem with Fedora-32?
Since this morning Qubes Updater does not succeed updating the 'fedora-32' template multiple times, while it did work for 'whonix-gw-15' w/o any issues ... The log, that is returned, does not provide me enough information to decide what to do next - or - how to resolve this issue: ### Updating fedora-32 Error on updating fedora-32: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=fedora-32', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20 fedora-32: -- ID: dnf list updates --refresh >/dev/null Function: cmd.run Result: True Comment: Command "dnf list updates --refresh >/dev/null" run Started: 07:51:50.141364 Duration: 27200.776 ms Changes: -- pid: 1077 retcode: 0 stderr: stdout: -- ID: update Function: pkg.uptodate Result: False Comment: Problem encountered upgrading packages. Additional info follows: result: -- pid: 1223 retcode: -11 stderr: Running scope as unit: run-r66efc5e9dbff48a29f0addb90047401b.scope stdout: Started: 07:52:19.863226 Duration: 27344.911 ms Changes: -- ID: notify-updates Function: cmd.run Name: /usr/lib/qubes/upgrades-status-notify Result: True Comment: Command "/usr/lib/qubes/upgrades-status-notify" run Started: 07:52:47.208388 Duration: 4470.826 ms Changes: -- pid: 1235 retcode: 0 stderr: stdout: Summary for fedora-32 Succeeded: 2 (changed=2) Failed:1 Total states run: 3 Total run time: 59.017 s Updating whonix-gw-15 whonix-gw-15: -- ID: dsa-4371-update Function: cmd.script Result: True Comment: Nothing to do, apt already fixed. Started: 06:53:02.881055 Duration: 139.51 ms Changes: -- ID: update Function: pkg.uptodate Result: True Comment: Upgrade ran successfully Started: 06:53:04.748657 Duration: 21569.53 ms Changes: -- hardened-malloc: -- new: 3.0.6-1 old: 3.0.5-1 security-misc: -- new: 3:19.7-1 old: 3:19.4-1 usability-misc: -- new: 3:8.2-1 old: 3:8.1-1 -- ID: notify-updates Function: cmd.run Name: /usr/lib/qubes/upgrades-status-notify Result: True Comment: Command "/usr/lib/qubes/upgrades-status-notify" run Started: 06:53:26.319354 Duration: 3495.149 ms Changes: -- pid: 3961 retcode: 0 stderr: stdout: Summary for whonix-gw-15 Succeeded: 3 (changed=2) Failed:0 Total states run: 3 Total run time: 25.204 s ### I searched for "Error on updating fedora-32: Command '[ ... ]' returned non-zero exit status 20" but the first five results returned, did not help me either :-( Any ideas or suggestions? With kind regards, Viktor -- 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/481860ba-ca11-40b3-a42c-18359accd5ccn%40googlegroups.com.
Re: [qubes-users] Qubes updater icon never gets cleared
Viktor Ransmayr schrieb am Sonntag, 6. Dezember 2020 um 12:18:17 UTC+1: > > Viktor Ransmayr schrieb am Samstag, 5. Dezember 2020 um 22:59:57 UTC+1: > >> >> a...@qubes-os.org schrieb am Samstag, 5. Dezember 2020 um 22:29:45 UTC+1: >> >>> On 12/5/20 1:36 AM, Viktor Ransmayr wrote: >>> > Hello Qubes community, >>> > >>> > I noticed since yesterday, that the icon, which indicates that updates >>> are >>> > available, never gets cleared on my system, although I obviously try >>> to >>> > launch the updater in a timely fashion - and - the operation succeeds >>> ... >>> > >>> > Here's the log from the latest attempt: >>> > >>> > ### >>> > >>> > Updating fedora-32 >>> > >>> > fedora-32: >>> > -- >>> > ID: dnf list updates --refresh >/dev/null >>> > Function: cmd.run >>> > Result: True >>> > Comment: Command "dnf list updates --refresh >/dev/null" run >>> > Started: 09:00:59.753451 >>> > Duration: 8745.114 ms >>> > Changes: >>> > -- >>> > pid: >>> > 1077 >>> > retcode: >>> > 0 >>> > stderr: >>> > stdout: >>> > -- >>> > ID: update >>> > Function: pkg.uptodate >>> > Result: True >>> > Comment: Upgrade ran successfully >>> > Started: 09:01:10.612928 >>> > Duration: 24382.315 ms >>> > Changes: >>> > -- >>> > ID: notify-updates >>> > Function: cmd.run >>> > Name: /usr/lib/qubes/upgrades-status-notify >>> > Result: True >>> > Comment: Command "/usr/lib/qubes/upgrades-status-notify" run >>> > Started: 09:01:34.995429 >>> > Duration: 3878.256 ms >>> > Changes: >>> > -- >>> > pid: >>> > 1148 >>> > retcode: >>> > 0 >>> > stderr: >>> > stdout: >>> > >>> > Summary for fedora-32 >>> > >>> > Succeeded: 3 (changed=2) >>> > Failed: 0 >>> > >>> > Total states run: 3 >>> > Total run time: 37.006 s >>> > >>> > ### >>> > >>> > Does anyone have an explanation - or - a suggestion what else to try? >>> - TIA! >>> > >>> > Viktor >>> > >>> >>> This is probably: >>> >>> https://github.com/QubesOS/qubes-issues/issues/6234 >>> >>> In which case, it's a known bug, and the fix is in current-testing. >>> >> >> Thanks for the link to this issue. - I'll spend some time tomorrow >> reading it in detail & will report back here ... >> > > Yes, it looks like that this is / was most likely the reason for the > 'hickup' on my system as well. > > In the meantime the situation has changed however on my system again! > > As I did report already initially I update my system in a timely fashion - > and - continued to do so, even while waiting for an anwer / response > related to "sudo dnf update --best --allowerasing" ... > > Today two more updates related to 'fedora-32' and 'whonix-gw-15' were > performed ... > > Result: Update of template 'whonix-gw-15' succeeded immediately - and - > the partial update of 'fedora-32' succeeded after multiple 'hickups'. - > However the Qubes Updater icon is still active - but - when I perform 'sudo > dnf update' in Dom0 the system now only reports: > > [vr@dom0 ~]$ sudo dnf update ### <- Layer-8 error ;-) - Should have > checked against [user@fedora-32] !!! > > Qubes OS Repository for Dom0 80 MB/s | 82 kB > 00:00 > Dependencies resolved. > Nothing to do. > Complete! > [vr@dom0 ~]$ > > while running the update of the 'fedora-32' template using the updater > still reports: > > Updating fedora-32 > > fedora-32: > -- > ID: dnf list updates --refresh >/dev/null > Function: cmd.run > Result: True >Comment: Command "dnf list updates --refresh >/dev/null" run >Started: 10:17:20.752975 > Duration: 8103.878 ms >Changes: > -- > pid: > 1076 > > retcode: &g
Re: [qubes-users] Qubes updater icon never gets cleared
Hello Andrew, hello Community Viktor Ransmayr schrieb am Samstag, 5. Dezember 2020 um 22:59:57 UTC+1: > > a...@qubes-os.org schrieb am Samstag, 5. Dezember 2020 um 22:29:45 UTC+1: > >> On 12/5/20 1:36 AM, Viktor Ransmayr wrote: >> > Hello Qubes community, >> > >> > I noticed since yesterday, that the icon, which indicates that updates >> are >> > available, never gets cleared on my system, although I obviously try to >> > launch the updater in a timely fashion - and - the operation succeeds >> ... >> > >> > Here's the log from the latest attempt: >> > >> > ### >> > >> > Updating fedora-32 >> > >> > fedora-32: >> > -- >> > ID: dnf list updates --refresh >/dev/null >> > Function: cmd.run >> > Result: True >> > Comment: Command "dnf list updates --refresh >/dev/null" run >> > Started: 09:00:59.753451 >> > Duration: 8745.114 ms >> > Changes: >> > -- >> > pid: >> > 1077 >> > retcode: >> > 0 >> > stderr: >> > stdout: >> > -- >> > ID: update >> > Function: pkg.uptodate >> > Result: True >> > Comment: Upgrade ran successfully >> > Started: 09:01:10.612928 >> > Duration: 24382.315 ms >> > Changes: >> > -- >> > ID: notify-updates >> > Function: cmd.run >> > Name: /usr/lib/qubes/upgrades-status-notify >> > Result: True >> > Comment: Command "/usr/lib/qubes/upgrades-status-notify" run >> > Started: 09:01:34.995429 >> > Duration: 3878.256 ms >> > Changes: >> > -- >> > pid: >> > 1148 >> > retcode: >> > 0 >> > stderr: >> > stdout: >> > >> > Summary for fedora-32 >> > >> > Succeeded: 3 (changed=2) >> > Failed: 0 >> > >> > Total states run: 3 >> > Total run time: 37.006 s >> > >> > ### >> > >> > Does anyone have an explanation - or - a suggestion what else to try? - >> TIA! >> > >> > Viktor >> > >> >> This is probably: >> >> https://github.com/QubesOS/qubes-issues/issues/6234 >> >> In which case, it's a known bug, and the fix is in current-testing. >> > > Thanks for the link to this issue. - I'll spend some time tomorrow reading > it in detail & will report back here ... > Yes, it looks like that this is / was most likely the reason for the 'hickup' on my system as well. In the meantime the situation has changed however on my system again! As I did report already initially I update my system in a timely fashion - and - continued to do so, even while waiting for an anwer / response related to "sudo dnf update --best --allowerasing" ... Today two more updates related to 'fedora-32' and 'whonix-gw-15' were performed ... Result: Update of template 'whonix-gw-15' succeeded immediately - and - the partial update of 'fedora-32' succeeded after multiple 'hickups'. - However the Qubes Updater icon is still active - but - when I perform 'sudo dnf update' in Dom0 the system now only reports: [vr@dom0 ~]$ sudo dnf update Qubes OS Repository for Dom0 80 MB/s | 82 kB 00:00 Dependencies resolved. Nothing to do. Complete! [vr@dom0 ~]$ while running the update of the 'fedora-32' template using the updater still reports: Updating fedora-32 fedora-32: -- ID: dnf list updates --refresh >/dev/null Function: cmd.run Result: True Comment: Command "dnf list updates --refresh >/dev/null" run Started: 10:17:20.752975 Duration: 8103.878 ms Changes: -- pid: 1076 retcode: 0 stderr: stdout: -- ID: update Function: pkg.uptodate Result: True Comment: Upgrade ran successfully Started: 10:17:30.963450 Duration: 26434.827 ms Changes: -- ID: notify-updates Function: cmd.run Name: /usr/lib/qubes/upgrades-status-notify Result: True Comment: Command "/usr/lib/qubes/upgrades-status-notify" run Started: 10:17:57.398477 Duration: 3940.383 ms Changes: -- pid: 1148 retcode: 0 stderr: stdout: Summary for fedora-32 Succeeded: 3 (changed=2) Failed:0 Total states run: 3 Total run time: 38.479 s FYI: If it is important & interesting, I've logged the details of each operation & can report them here or in the issue ... With kind regards, Viktor -- 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/dd2e9c93-e1f0-489f-bd02-34b5bd86db40n%40googlegroups.com.
Re: [qubes-users] Qubes updater icon never gets cleared
Hello Andrew a...@qubes-os.org schrieb am Samstag, 5. Dezember 2020 um 22:29:45 UTC+1: > On 12/5/20 1:36 AM, Viktor Ransmayr wrote: > > Hello Qubes community, > > > > I noticed since yesterday, that the icon, which indicates that updates > are > > available, never gets cleared on my system, although I obviously try to > > launch the updater in a timely fashion - and - the operation succeeds > ... > > > > Here's the log from the latest attempt: > > > > ### > > > > Updating fedora-32 > > > > fedora-32: > > -- > > ID: dnf list updates --refresh >/dev/null > > Function: cmd.run > > Result: True > > Comment: Command "dnf list updates --refresh >/dev/null" run > > Started: 09:00:59.753451 > > Duration: 8745.114 ms > > Changes: > > -- > > pid: > > 1077 > > retcode: > > 0 > > stderr: > > stdout: > > -- > > ID: update > > Function: pkg.uptodate > > Result: True > > Comment: Upgrade ran successfully > > Started: 09:01:10.612928 > > Duration: 24382.315 ms > > Changes: > > -- > > ID: notify-updates > > Function: cmd.run > > Name: /usr/lib/qubes/upgrades-status-notify > > Result: True > > Comment: Command "/usr/lib/qubes/upgrades-status-notify" run > > Started: 09:01:34.995429 > > Duration: 3878.256 ms > > Changes: > > -- > > pid: > > 1148 > > retcode: > > 0 > > stderr: > > stdout: > > > > Summary for fedora-32 > > > > Succeeded: 3 (changed=2) > > Failed: 0 > > > > Total states run: 3 > > Total run time: 37.006 s > > > > ### > > > > Does anyone have an explanation - or - a suggestion what else to try? - > TIA! > > > > Viktor > > > > This is probably: > > https://github.com/QubesOS/qubes-issues/issues/6234 > > In which case, it's a known bug, and the fix is in current-testing. > Thanks for the link to this issue. - I'll spend some time tomorrow reading it in detail & will report back here ... With kind regards, Viktor -- 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/029b69a1-f18b-454b-bb89-4903ca5a8d29n%40googlegroups.com.
Re: [qubes-users] Qubes updater icon never gets cleared
TheGardner schrieb am Samstag, 5. Dezember 2020 um 20:49:30 UTC+1: > Worked for me! Update sign is gone at the taskbar. > Thanks a bunch Victor. > I did NOT yet perform the second part of the recommended procedure from 'taran1s' ... Here's my output: > > [user@fedora-32 ~]$ sudo dnf update --best --allowerasing > Last metadata expiration check: 0:11:37 ago on Sat Dec 5 20:32:06 2020. > Dependencies resolved. > > === > > Package Arch Version > Repository Size > > === > Upgrading: > > pulseaudio x86_64 14.0-1.fc32 > updates1.0 M > pulseaudio-libs x86_64 14.0-1.fc32 > updates690 k > pulseaudio-libs-glib2 x86_64 14.0-1.fc32 > updates 18 k > > pulseaudio-module-bluetooth x86_64 14.0-1.fc32 > updates 78 k > pulseaudio-module-x11 x86_64 14.0-1.fc32 > updates 31 k > pulseaudio-utilsx86_64 14.0-1.fc32 > updates 72 k > Removing dependent packages: > pulseaudio-qubesx86_64 4.0.31-1.fc32 > @qubes-vm-r4.0-current 41 k > qubes-vm-recommendednoarch 4.0.7-1.fc32 > @qubes-builder-vm-r4.0-current-testing 0 > > Transaction Summary > > === > Upgrade 6 Packages > Remove 2 Packages > > Total download size: 1.9 M > Is this ok [y/N]: y > Downloading Packages: > (1/6): > pulseaudio-libs-glib2-14.0-1.fc32.x86_64.rpm 15 > kB/s | 18 kB 00:01 > (2/6): > pulseaudio-libs-14.0-1.fc32.x86_64.rpm 331 > kB/s | 690 kB 00:02 > (3/6): > pulseaudio-14.0-1.fc32.x86_64.rpm 421 > kB/s | 1.0 MB 00:02 > (4/6): > pulseaudio-module-bluetooth-14.0-1.fc32.x86_64.rpm 63 > kB/s | 78 kB 00:01 > (5/6): > pulseaudio-module-x11-14.0-1.fc32.x86_64.rpm 76 > kB/s | 31 kB 00:00 > (6/6): > pulseaudio-utils-14.0-1.fc32.x86_64.rpm 217 > kB/s | 72 kB 00:00 > > --- > Total > > 431 kB/s | 1.9 MB 00:04 > Running transaction check > Transaction check succeeded. > Running transaction test > Transaction test succeeded. > Running transaction > Preparing > : > > 1/1 > Upgrading: > pulseaudio-libs-14.0-1.fc32.x86_64 > > 1/14 > Running scriptlet: > pulseaudio-libs-14.0-1.fc32.x86_64 > > 1/14 > Running scriptlet: > pulseaudio-14.0-1.fc32.x86_64 > > 2/14 > Upgrading: > pulseaudio-14.0-1.fc32.x86_64 > > 2/14 > Running scriptlet: > pulseaudio-14.0-1.fc32.x86_64 > > 2/14 > Upgrading: > pulseaudio-utils-14.0-1.fc32.x86_64 > > 3/14 > Upgrading: > pulseaudio-module-x11-14.0-1.fc32.x86_64 > > 4/14 > Upgrading: > pulseaudio-module-bluetooth-14.0-1.fc32.x86_64 > > 5/14 > Upgrading: > pulseaudio-libs-glib2-14.0-1.fc32.x86_64 > > 6/14 > Cleanup : > pulseaudio-module-x11-13.99.1-4.fc32.x86_64 > > 7/14 > Cleanup : > pulseaudio-module-bluetooth-13.99.1-4.fc32.x86_64 > > 8/14 > Cleanup : > pulseaudio-utils-13.99.1-4.fc32.x86_64 > > 9/14 > Cleanup : > pulseaudio-libs-glib2-13.99.1-4.fc32.x86_64 > > 10/14 > Erasing : > qubes-vm-recommended-4.0.7-1.fc32.noarch > > 11/14 > Erasing : >
Re: [qubes-users] Qubes updater icon never gets cleared
cubit schrieb am Samstag, 5. Dezember 2020 um 13:37:58 UTC+1: > Dec 5, 2020, 11:16 by qubes...@googlegroups.com: > > It happened to me as well and is most probably an issue with the > pulseaudio. > > Does it happen with fedora-32 template only or is it the case for other > templates too? > > If only with fedora-32, try to directly open the fedora-32 template and > execute: > $ sudo dnf update > > If it says anything about pulseaudio, try to execute: > > $ sudo dnf update --best --allowerasing > > This should solve the issue. > > > I have the same persistent notification due to pulseaudio updates. Do > you recall what packages it said it will remove when you run with --best > --allowerasing. > > I am told it will remove > > Removing dependent packages: > - pulseaudio-qubes > - qubes-vm-recommended > > Which at least the second one sounds important for qubes operation so > feeling a bit cautious > Thanks a lot for your answer & warning as well. Let's see, what the response to my other message will be ... With kind regards, Viktor -- 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/8c1ce42e-e465-450d-9e5a-51f699187433n%40googlegroups.com.
Re: [qubes-users] Qubes updater icon never gets cleared
taran1s schrieb am Samstag, 5. Dezember 2020 um 12:17:26 UTC+1: > It happened to me as well and is most probably an issue with the > pulseaudio. > Thanks a lot for your quick feedback & suggestion! Does it happen with fedora-32 template only or is it the case for other > templates too? > Only for fedora-32. If only with fedora-32, try to directly open the fedora-32 template and > execute: > $ sudo dnf update Here's the output running that command: ### [user@fedora-32 ~]$ sudo dnf update Fedora Modular 32 - x86_64 - Updates 20 kB/s | 7.4 kB 00:00 Fedora 32 - x86_64 - Updates 17 kB/s | 15 kB 00:00 Dependencies resolved. Problem 1: package pulseaudio-qubes-4.0.31-1.fc32.x86_64 requires pulseaudio = 13.99.1, but none of the providers can be installed - cannot install both pulseaudio-14.0-1.fc32.x86_64 and pulseaudio-13.99.1-4.fc32.x86_64 - cannot install both pulseaudio-13.99.1-3.fc32.x86_64 and pulseaudio-14.0-1.fc32.x86_64 - cannot install the best update candidate for package pulseaudio-qubes-4.0.31-1.fc32.x86_64 - cannot install the best update candidate for package pulseaudio-13.99.1-4.fc32.x86_64 Problem 2: problem with installed package pulseaudio-qubes-4.0.31-1.fc32.x86_64 - package pulseaudio-qubes-4.0.31-1.fc32.x86_64 requires pulseaudio = 13.99.1, but none of the providers can be installed - package pulseaudio-13.99.1-4.fc32.x86_64 requires pulseaudio-libs(x86-64) = 13.99.1-4.fc32, but none of the providers can be installed - package pulseaudio-13.99.1-3.fc32.x86_64 requires pulseaudio-libs(x86-64) = 13.99.1-3.fc32, but none of the providers can be installed - cannot install both pulseaudio-libs-14.0-1.fc32.x86_64 and pulseaudio-libs-13.99.1-4.fc32.x86_64 - cannot install both pulseaudio-libs-13.99.1-3.fc32.x86_64 and pulseaudio-libs-14.0-1.fc32.x86_64 - cannot install the best update candidate for package pulseaudio-libs-13.99.1-4.fc32.x86_64 Problem 3: package qubes-vm-recommended-4.0.7-1.fc32.noarch requires pulseaudio-qubes, but none of the providers can be installed - package pulseaudio-qubes-4.0.31-1.fc32.x86_64 requires pulseaudio = 13.99.1, but none of the providers can be installed - package pulseaudio-qubes-4.0.29-1.fc32.x86_64 requires pulseaudio = 13.99.1, but none of the providers can be installed - package pulseaudio-qubes-4.0.30-1.fc32.x86_64 requires pulseaudio = 13.99.1, but none of the providers can be installed - cannot install both pulseaudio-14.0-1.fc32.x86_64 and pulseaudio-13.99.1-4.fc32.x86_64 - cannot install both pulseaudio-13.99.1-3.fc32.x86_64 and pulseaudio-14.0-1.fc32.x86_64 - package pulseaudio-module-bluetooth-14.0-1.fc32.x86_64 requires libpulsecore-14.0.so()(64bit), but none of the providers can be installed - package pulseaudio-module-bluetooth-14.0-1.fc32.x86_64 requires pulseaudio(x86-64) = 14.0-1.fc32, but none of the providers can be installed - cannot install the best update candidate for package qubes-vm-recommended-4.0.7-1.fc32.noarch - cannot install the best update candidate for package pulseaudio-module-bluetooth-13.99.1-4.fc32.x86_64 Problem 4: problem with installed package qubes-vm-recommended-4.0.7-1.fc32.noarch - package qubes-vm-recommended-4.0.7-1.fc32.noarch requires pulseaudio-qubes, but none of the providers can be installed - package pulseaudio-qubes-4.0.31-1.fc32.x86_64 requires pulseaudio = 13.99.1, but none of the providers can be installed - package pulseaudio-qubes-4.0.29-1.fc32.x86_64 requires pulseaudio = 13.99.1, but none of the providers can be installed - package pulseaudio-qubes-4.0.30-1.fc32.x86_64 requires pulseaudio = 13.99.1, but none of the providers can be installed - cannot install both pulseaudio-14.0-1.fc32.x86_64 and pulseaudio-13.99.1-4.fc32.x86_64 - cannot install both pulseaudio-13.99.1-3.fc32.x86_64 and pulseaudio-14.0-1.fc32.x86_64 - package pulseaudio-module-x11-14.0-1.fc32.x86_64 requires libpulsecore-14.0.so()(64bit), but none of the providers can be installed - package pulseaudio-module-x11-14.0-1.fc32.x86_64 requires pulseaudio(x86-64) = 14.0-1.fc32, but none of the providers can be installed - cannot install the best update candidate for package pulseaudio-module-x11-13.99.1-4.fc32.x86_64 Package Arch Version Repository Size Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): pulseaudio x86_64 13.99.1-3.fc32 fedora 1.0 M pulseaudio x86_64 14.0-1.fc32 updates 1.0 M pulseaudio-libs x86_64 13.99.1-3.fc32 fedora 707 k pulseaudio-libs x86_64 14.0-1.fc32 updates 690 k
[qubes-users] Qubes updater icon never gets cleared
Hello Qubes community, I noticed since yesterday, that the icon, which indicates that updates are available, never gets cleared on my system, although I obviously try to launch the updater in a timely fashion - and - the operation succeeds ... Here's the log from the latest attempt: ### Updating fedora-32 fedora-32: -- ID: dnf list updates --refresh >/dev/null Function: cmd.run Result: True Comment: Command "dnf list updates --refresh >/dev/null" run Started: 09:00:59.753451 Duration: 8745.114 ms Changes: -- pid: 1077 retcode: 0 stderr: stdout: -- ID: update Function: pkg.uptodate Result: True Comment: Upgrade ran successfully Started: 09:01:10.612928 Duration: 24382.315 ms Changes: -- ID: notify-updates Function: cmd.run Name: /usr/lib/qubes/upgrades-status-notify Result: True Comment: Command "/usr/lib/qubes/upgrades-status-notify" run Started: 09:01:34.995429 Duration: 3878.256 ms Changes: -- pid: 1148 retcode: 0 stderr: stdout: Summary for fedora-32 Succeeded: 3 (changed=2) Failed:0 Total states run: 3 Total run time: 37.006 s ### Does anyone have an explanation - or - a suggestion what else to try? - TIA! Viktor -- 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/bc8c5f91-980b-4ebc-8c99-8248bcc6dd95n%40googlegroups.com.
[qubes-users] Re: salt management issues since last qubes (dom0?) upgrade
balin schrieb am Freitag, 13. November 2020 um 19:33:36 UTC+1: > Ok. More detail: > > When calling (as root and in dom0): > qubesctl --target=fedora-32 state.highstate, > I get > fedora-32: ERROR (exit code 20, details in > /var/log/qubes/mgmt-fedora-32.log) > > The relevant part in the referenced log reads: > 2020-11-13 19:27:51,237 calling 'state.highstate'... > 2020-11-13 19:28:13,123 output: fedora-32: > 2020-11-13 19:28:13,125 output: -- > 2020-11-13 19:28:13,125 output: _error: > 2020-11-13 19:28:13,125 output: Failed to return clean data > 2020-11-13 19:28:13,125 output: retcode: > 2020-11-13 19:28:13,125 output: 1 > 2020-11-13 19:28:13,125 output: stderr: > 2020-11-13 19:28:13,125 output: Traceback (most recent call > last): > 2020-11-13 19:28:13,125 output: File > "/usr/lib/qubes-vm-connector/ssh-wrapper/ssh", line 101, in > 2020-11-13 19:28:13,125 output: sys.exit(main()) > 2020-11-13 19:28:13,125 output: File > "/usr/lib/qubes-vm-connector/ssh-wrapper/ssh", line 94, in main > 2020-11-13 19:28:13,125 output: return ssh(args) > 2020-11-13 19:28:13,125 output: File > "/usr/lib/qubes-vm-connector/ssh-wrapper/ssh", line 29, in ssh > 2020-11-13 19:28:13,126 output: assert args[1] == '/bin/sh' > 2020-11-13 19:28:13,126 output: AssertionError > 2020-11-13 19:28:13,126 output: stdout: > 2020-11-13 19:28:13,126 exit code: 20 > > What is going on here? why did this stop working? > Just an additional confirmation from my side: I receive the same error message, when I try to do the same via the (GUI) Qubes Updater. This problem started yesterday morning on my system. -- 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/7185d131-f7d5-4417-8ce9-502dd3f006d5n%40googlegroups.com.
Re: [qubes-users] Re: update error: Jinja variable 'dict object' has no attribute 'os'
Viktor Ransmayr schrieb am Samstag, 25. Juli 2020 um 10:29:30 UTC+2: > > Emily schrieb am Sonntag, 19. Juli 2020 um 22:36:31 UTC+2: > >> >> I see the following error in the Qubes Update widget window after >>> attempting to upgrade a Fedora 32 template: >>> >>> Rendering SLS 'base:update.qubes-vm' failed: Jinja variable 'dict >>> object' has no attribute 'os' >>> >>> I switched the dvm template to fedora 32 as described in: >>> >>> https://www.qubes-os.org/news/2020/06/30/fedora-32-templates-available/ >>> https://www.qubes-os.org/doc/templates/#switching >>> >>> I was not able to find an open issue about this on GH >>> https://github.com/QubesOS/qubes-issues/issues >>> >>> Do you see the same error? >>> >> >> > Yes, I do receive the same error, if I accept the update request from >> the top-level menu icon. >> > The same operation succeeds however, if I trigger it explicitely via >> the Qube Manager, i.e. >> > "Start Qube Manager > Select 'fedora-32' > Update qube" ... >> >> You can also use a simple command line script for this: >> >> qvm-run -u root fedora-32 "sudo dnf update -y" ; qvm-shutdown fedora-32 >> > > I can confirm that the CLI-based Dom0 variant does also work for the > 'fedora-32' as well as for the 'fedora-32-minimal' template. > > But that should not come as a really surprise, after what I had reported > earlier concerning the Qube Manager variant! > > Since the original issue reported for the Qubes Update widget window still > persists - It just happened again today on my system - the question is now: > > Should I raise a bug report - or - is there something else I should check > / do before? > FYI: Since yesterday, when a combined dom0 & fedora-32 update occured, the error when using the Qubes Update widget window method is gone. With kind regards, VR -- 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/4252074a-e1d8-4612-a0b7-2e4681481e38n%40googlegroups.com.
Re: [qubes-users] Re: update error: Jinja variable 'dict object' has no attribute 'os'
Hello Emily Emily schrieb am Sonntag, 19. Juli 2020 um 22:36:31 UTC+2: > > I see the following error in the Qubes Update widget window after >> attempting to upgrade a Fedora 32 template: >> >> Rendering SLS 'base:update.qubes-vm' failed: Jinja variable 'dict object' >> has no attribute 'os' >> >> I switched the dvm template to fedora 32 as described in: >> >> https://www.qubes-os.org/news/2020/06/30/fedora-32-templates-available/ >> https://www.qubes-os.org/doc/templates/#switching >> >> I was not able to find an open issue about this on GH >> https://github.com/QubesOS/qubes-issues/issues >> >> Do you see the same error? >> > > > Yes, I do receive the same error, if I accept the update request from > the top-level menu icon. > > The same operation succeeds however, if I trigger it explicitely via the > Qube Manager, i.e. > > "Start Qube Manager > Select 'fedora-32' > Update qube" ... > > You can also use a simple command line script for this: > > qvm-run -u root fedora-32 "sudo dnf update -y" ; qvm-shutdown fedora-32 > I can confirm that the CLI-based Dom0 variant does also work for the 'fedora-32' as well as for the 'fedora-32-minimal' template. But that should not come as a really surprise, after what I had reported earlier concerning the Qube Manager variant! Since the original issue reported for the Qubes Update widget window still persists - It just happened again today on my system - the question is now: Should I raise a bug report - or - is there something else I should check / do before? With kind regards, VR -- 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/f1dc7f3b-c02a-4b86-a668-3c92af657f2an%40googlegroups.com.
[qubes-users] Re: update error: Jinja variable 'dict object' has no attribute 'os'
qubes...@riseup.net schrieb am Samstag, 18. Juli 2020 um 09:59:26 UTC+2: > > I see the following error in the Qubes Update widget window after > attempting to upgrade a Fedora 32 template: > > Rendering SLS 'base:update.qubes-vm' failed: Jinja variable 'dict object' > has no attribute 'os' > > I switched the dvm template to fedora 32 as described in: > > https://www.qubes-os.org/news/2020/06/30/fedora-32-templates-available/ > https://www.qubes-os.org/doc/templates/#switching > > I was not able to find an open issue about this on GH > https://github.com/QubesOS/qubes-issues/issues > > Do you see the same error? > Yes, I do receive the same error, if I accept the update request from the top-level menu icon. The same operation succeeds however, if I trigger it explicitely via the Qube Manager, i.e. "Start Qube Manager > Select 'fedora-32' > Update qube" ... With kind regards, VR -- 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/4f23194b-8627-4c6a-9cde-46eeeb226b00n%40googlegroups.com.
Re: [qubes-users] Next question related to cloning of Minimal TemplateVMs
Hello unman, On Sat, May 30, 2020, 19:49 unman wrote: > On Sat, May 30, 2020 at 10:21:16AM -0700, viktor.ransm...@gmail.com wrote: > > Now that I have resolved (?) my problem concerning copying text from > xterm > > sessions, I'm running into the next strange behavior :-( > > > > The short version, is a simple question: > > > > *Are you able to create a clone from 'fedora-31-minimal' and extend it > with > > packages?* > > > > > > Thanks for the detailed report. > The minimal template does not contain the qubes-passwordless-root > package. The full template does. > Read this: > https://www.qubes-os.org/doc/templates/minimal/#passwordless-root Thanks for this link. - Now it's clear. With kind regards, VR -- 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/CAAeSrGJVjhr4A89RRndeeEu6VEHJVkFjhNJrHGbbQGgmXdX4Vw%40mail.gmail.com.
[qubes-users] Next question related to cloning of Minimal TemplateVMs
Hello community, Now that I have resolved (?) my problem concerning copying text from xterm sessions, I'm running into the next strange behavior :-( The short version, is a simple question: *Are you able to create a clone from 'fedora-31-minimal' and extend it with packages?* The longer version contains some details on what I experienced today on my Qubes OS system: The obvious next step for me was to create a clone of 'fedora-31-minimal' and extend it with additional packages. Since I do all my documentation in reST & transforming it into HTML as output format, I'll require a web browser in most of my VMs. Therefore I wanted to have 'Firefox' available - but - this was not possible :-( Here's the log of what I did (including logs at the end): ### Create a new template based on 'Fedora-31-Minimal' with Firefox added. - Not OK. - See "Log-001" * Unable to `sudo dnf install firefox` ... * Restart the Qube OS system ... ### 2020-05-30 ~ 14:05 (UTC) * Start 'fedora-31-minimal-firefox' & try to `sudo dnf install firefox` - Again not OK. * Delete the clone 'fedora-31-minimal'. ### 2020-05-30 ~ 14:15 (UTC) Create a new template clone based on 'Fedora-31-Minimal' - OK. * Start & update 'fedora-31-minimal-firefox' * Try to `sudo dnf install firefox` - Again not OK ... ### 2020-05-30 ~ 14:30 (UTC) Create a new template clone based on 'Fedora-31' - OK. * Start & update 'fedora-31-java' * Try to `sudo dnf install java-11` - OK. - See "Log-002". ### [user@fedora-31-minimal-firefox ~]$ pwd /home/user [user@fedora-31-minimal-firefox ~]$ ls -al total 44 drwx-- 3 user user 4096 May 30 16:43 . drwxr-xr-x 3 root root 4096 May 27 04:17 .. -rw-rw-r-- 1 user user 34 May 30 16:43 .Xresources -rw--- 1 user user 284 May 30 16:44 .bash_history -rw-r--r-- 1 user user 18 Dec 6 13:06 .bash_logout -rw-r--r-- 1 user user 141 Dec 6 13:06 .bash_profile -rw-r--r-- 1 user user 376 Dec 6 13:06 .bashrc drwxr-xr-x 3 user user 4096 May 27 04:17 .local -rw-rw-r-- 1 user user 4322 May 30 16:44 .xsession-errors -rw--- 1 user user 60 May 30 14:32 XTerm2020-05-30.14:32:53 [user@fedora-31-minimal-firefox ~]$ sudo dnf install firefox We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. [sudo] password for user: Sorry, try again. [sudo] password for user: Sorry, try again. [sudo] password for user: sudo: 3 incorrect password attempts [user@fedora-31-minimal-firefox ~]$ Obviously I typed in the correct PW - otherwise - I would not be able to use the rest of the system ... To confirm that this is not a simple issue on my side I created a clone of 'fedora-31' with Java 11 added to the default. That's working w/o an issue! [user@fedora-31-java ~]$ sudo dnf install java-11 Last metadata expiration check: 0:21:11 ago on Sat May 30 14:18:32 2020. Dependencies resolved. Package Arch Version Repository Size Installing: java-11-openjdk x86_641:11.0.7.10-0.fc31 updates 249 k Installing dependencies: copy-jdk-configsnoarch3.7-4.fc31 fedora 24 k java-11-openjdk-headlessx86_641:11.0.7.10-0.fc31 updates 38 M javapackages-filesystem noarch5.3.0-6.fc31fedora 11 k lksctp-toolsx86_641.0.18-3.fc31 updates 95 k lua x86_645.3.5-6.fc31fedora 181 k lua-posix x86_6433.3.1-14.fc31 fedora 174 k tzdata-java noarch2020a-1.fc31updates 156 k Transaction Summary Install 8 Packages Total download size: 39 M Installed size: 175 M Is this ok [y/N]: y Downloading Packages: (1/8): lksctp-tools-1.0.18-3.fc31.x86_64.rpm285 kB/s | 95 kB 00:00 (2/8): java-11-openjdk-11.0.7.10-0.fc31.x86_64. 667 kB/s | 249 kB 00:00 (3/8): copy-jdk-configs-3.7-4.fc31.noarch.rpm29 kB/s | 24 kB 00:00 (4/8): tzdata-java-2020a-1.fc31.noarch.rpm 172 kB/s | 156 kB 00:00 (5/8): javapackages-filesystem-5.3.0-6.fc31.noa 13 kB/s | 11 kB 00:00 (6/8): lua-5.3.5-6.fc31.x86_64.rpm 152 kB/s | 181 kB 00:01 (7/8): lua-posix-33.3.1-14.fc31.x86_64.rpm 104 kB/s | 174 kB 00:01 (8/8): java-11-openjdk-headless-11.0.7.10-0.fc3 7.9 MB/s | 38 MB 00:04 Total 5.2 MB/s | 39 MB 00:07
Re: [qubes-users] Another newbie question related to TemplateVMs
Hello WillyPillow, Am Samstag, 30. Mai 2020 07:00:50 UTC+2 schrieb WillyPillow: > > On Saturday, May 30, 2020 6:48 AM, 'Jackie' via qubes-users < > qubes...@googlegroups.com > wrote: > > > On 2020-05-29 18:26, viktor@gmail.com wrote: > > > > Am Freitag, 29. Mai 2020 14:01:46 UTC+2 schrieb Frédéric Pierret: > > > > On 2020-05-29 13:53, viktor@gmail.com wrote: > > > > > > > > > > I'm trying to continue my journey into the various Qubes OS > options from the smaller - and not - from the larger template POV. > > > > > > > > > > I'm not asking for any additions to the provided packages > available for example in 'fedora-31-minimal'. > > > > > > > > > > All I'm asking for is help to resolve the following question: > > > > > > > > > > *What do I need to do in order to activate / enable the copy > / paste pattern via copy-c/v for xterm? > > > > > > > > Control+Middle mouse clic -> Select to Clipboard. Then, you can > you QubesOS clipboard shortcut (Control+Shift+C). > > > > > > > > It may be obvious to you, but for me - coming from the Windows > world - it is not really clear ... > > > > > > The middle click simply the wheel click but indeed, with only left and > right buttons it's both at the same time. Here when hold Control in > addition to left and right mouse button (keep holding) on xterm, it makes > appearing a little menu where the selection is made by unholding mouse > buttons. On this little menu you would see the 'Select to Clipboard' > option. > > > > For what it's worth i can't get this to work on xterm either. I use > > gnome-terminal which lets you right click -> copy (or edit -> copy), > > > > then qubes copy/paste shortcuts work like normal. > > To enable simulating middle clicks that way, I had to follow > < > https://unix.stackexchange.com/questions/9973/configuring-mouse-for-rightleft-button-simulating-middle-click-for-copy-paste>. > > > > Alternatively, you should be able to add `XTerm.vt100.selectToClipboard: > 1` > to `~/.Xresources` and run `xrdb -merge ~/.Xresources` to enable the > Select to Clipboard feature by default. > Your second recommendation worked out fine for me. When I ran the `xrdb` command it returned the warning "/home/user/.Xresources:0: warning: Unknown encoding: C.UTF-8" However when I opened a new xterm and tried to copy with `ctrl-c` & the rest of the Qubes-specific copy/paste commands b/w VMs it worked w/o any issue ... Thanks a lot for your help! With kind regards, VR -- 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/9a808394-40b9-4d6c-b8e2-fb83bafc8e29%40googlegroups.com.
Re: [qubes-users] Another newbie question related to TemplateVMs
Hello Jackie, Am Samstag, 30. Mai 2020 00:49:01 UTC+2 schrieb Jackie: > > On 2020-05-29 18:26, viktor@gmail.com wrote: > >> Am Freitag, 29. Mai 2020 14:01:46 UTC+2 schrieb Frédéric Pierret: > >> > >> On 2020-05-29 13:53, viktor@gmail.com wrote: > >> > > >> > I'm trying to continue my journey into the various Qubes OS > options from the smaller - and not - from the larger template POV. > >> > > >> > I'm not asking for any additions to the provided packages > available for example in 'fedora-31-minimal'. > >> > > >> > All I'm asking for is help to resolve the following question: > >> > > >> > *What do I need to do in order to activate / enable the copy / > paste pattern via copy-c/v for xterm? > >> > * > >> > >> Control+Middle mouse clic -> Select to Clipboard. Then, you can > you QubesOS clipboard shortcut (Control+Shift+C). > >> > >> > >> It may be obvious to you, but for me - coming from the Windows world - > it is not really clear ... > > > > The middle click simply the wheel click but indeed, with only left and > right buttons it's both at the same time. Here when hold Control in > addition to left and right mouse button (keep holding) on xterm, it makes > appearing a little menu where the selection is made by unholding mouse > buttons. On this little menu you would see the 'Select to Clipboard' > option. > > For what it's worth i can't get this to work on xterm either. I use > gnome-terminal which lets you right click -> copy (or edit -> copy), > then qubes copy/paste shortcuts work like normal. > Thanks for sending a confirmation, that I'm not the only one having a problem with the approach described & recommended by Frederic. Concerning your mention of gnome-terminal. - I'm aware of it, I'm using it in my 'regular' Qubes - but - in this specific case I don't want to start with including the whole Gnome Desktop up front. As I said in my first message: I'l like to start with as few packages as possible for some qubes ... With kind regards, VR -- 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/bbeb0240-5232-4c4b-8928-1bb9b0174536%40googlegroups.com.
Re: [qubes-users] Another newbie question related to TemplateVMs
Hello Frederic,
Am Freitag, 29. Mai 2020 19:00:55 UTC+2 schrieb Frédéric Pierret:
> On 2020-05-29 18:26, viktor@gmail.com wrote:
> > Am Freitag, 29. Mai 2020 14:01:46 UTC+2 schrieb Frédéric Pierret:
> >
> > On 2020-05-29 13:53, viktor@gmail.com wrote:
> > >
> > > I'm trying to continue my journey into the various Qubes OS
> options from the smaller - and not - from the larger template POV.
> > >
> > > I'm not asking for any additions to the provided packages
> available for example in 'fedora-31-minimal'.
> > >
> > > All I'm asking for is help to resolve the following question:
> > >
> > > *What do I need to do in order to activate / enable the copy /
> paste pattern via copy-c/v for xterm?
> > > *
> >
> > Control+Middle mouse clic -> Select to Clipboard. Then, you can you
> QubesOS clipboard shortcut (Control+Shift+C).
> >
> >
> > It may be obvious to you, but for me - coming from the Windows world -
> it is not really clear ...
>
> The middle click simply the wheel click but indeed, with only left and
> right buttons it's both at the same time. Here when hold Control in
> addition to left and right mouse button (keep holding) on xterm, it makes
> appearing a little menu where the selection is made by unholding mouse
> buttons. On this little menu you would see the 'Select to Clipboard' option.
>
Which version of Qubes OS - and - of Fedora are you using?
Have you made any changes to the 'default' X environment coming with the
Fedora template?
The reason why I ask, is that I re-tried your suggestion in both qubes,
i.e. 'f31-min-test-vm' and in 'f31-test-vm'.
In 'f31-min-test-vm' a not so small menu is opening up ("Main Options") but
it does not contain a 'Select to Clipboard' option!
And if I try the same on 'f31-test-vm', i.e. a fresh AppVM created from the
default 'Fedora-31' template I get no menu at all ...
With kind regards,
VR
--
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/2cff7abe-695d-4152-a18c-95a04234e109%40googlegroups.com.
Re: [qubes-users] Another newbie question related to TemplateVMs
Hello Frederic, Am Freitag, 29. Mai 2020 14:01:46 UTC+2 schrieb Frédéric Pierret: > On 2020-05-29 13:53, viktor@gmail.com wrote: > > > > I'm trying to continue my journey into the various Qubes OS options from > the smaller - and not - from the larger template POV. > > > > I'm not asking for any additions to the provided packages available for > example in 'fedora-31-minimal'. > > > > All I'm asking for is help to resolve the following question: > > > > *What do I need to do in order to activate / enable the copy / paste > pattern via copy-c/v for xterm? > > * > > Control+Middle mouse clic -> Select to Clipboard. Then, you can you > QubesOS clipboard shortcut (Control+Shift+C). > It may be obvious to you, but for me - coming from the Windows world - it is not really clear ... I searched for 'middle mouse clic' & I was told that on a regular two button mouse, this maps / translates to pressing both left & right mouse at the same time. However in the xterm started from the qube 'f31-min-test-vm' this does not create any result :-( Whenever I try to perform a Control+Shift+C operation afterwards, it reports ZERO bytes ... What am I missing? > > > I do know, that this is not a Qubes OS specific question - but - it > seems to be a Qubes OS/ Minimal TemplateVM related question. > > > > I tried several options recommended to me, when I searched the Internet > for "copy text from xterm [fedora]". - Unfortunately w/o success :-( > > > > Additional information, just for the record: > > > > I created a qube, which I called 'f31-min-test-vm' based on the template > 'fedora-31-minimal' > > > > I start the xterm - and - would like to retrieve the content of all all > installed packages, i.e. 'rpm -qa | sort', to start adding necessary > packages for my use-case(s) ... > > > > Again for information only: > > > > When I execute 'rpm -qa | wc - l' in an xterm, it reports only > > > > * 431 for 'f31-min-test-vm' - but - > > * 1142 for 'f31-test-vm' ... > > > > *Any suggestions to my initial question? > > What is 'f31-test-vm'? You only spoke about f31-min-test-vm. > You are right, I should have mentioned 'f31-test-vm' explicitly as well. I created this qube fresh from the 'fedora-31' template, simply to get the number of packages which are installed, if I would base any cloned template on it. I just mentioned it as an argument, why *I* want to start from the smaller - and not - from the larger template. With kind regards, VR -- 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/07a939fe-0884-45af-81bf-7a87b3c9b26c%40googlegroups.com.
[qubes-users] Another newbie question related to TemplateVMs
Hello community, I'm trying to continue my journey into the various Qubes OS options from the smaller - and not - from the larger template POV. I'm not asking for any additions to the provided packages available for example in 'fedora-31-minimal'. All I'm asking for is help to resolve the following question: *What do I need to do in order to activate / enable the copy / paste pattern via copy-c/v for xterm?* I do know, that this is not a Qubes OS specific question - but - it seems to be a Qubes OS/ Minimal TemplateVM related question. I tried several options recommended to me, when I searched the Internet for "copy text from xterm [fedora]". - Unfortunately w/o success :-( Additional information, just for the record: I created a qube, which I called 'f31-min-test-vm' based on the template 'fedora-31-minimal' I start the xterm - and - would like to retrieve the content of all all installed packages, i.e. 'rpm -qa | sort', to start adding necessary packages for my use-case(s) ... Again for information only: When I execute 'rpm -qa | wc - l' in an xterm, it reports only * 431 for 'f31-min-test-vm' - but - * 1142 for 'f31-test-vm' ... *Any suggestions to my initial question?* With kind regards, VR -- 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/c9dfac76-2e5b-4d89-8675-aad2647d97e2%40googlegroups.com.
Re: [qubes-users] Removing Template VMs?
Am Dienstag, 5. Mai 2020 20:39:52 UTC+2 schrieb viktor@gmail.com: > Am Montag, 4. Mai 2020 22:25:13 UTC+2 schrieb dhorf-hfr...@hashmail.org: >> >> On Mon, May 04, 2020 at 12:28:27PM -0700, viktor@gmail.com wrote: >> > If I'd like to remove any old & **unused** Template VMs (e.g. Debian 9, >> > Fedora 29, etc.) all I have to do is to start the Qubes Manager, select >> the >> > template I'd like to remove - and - select 'Delete qube' ... >> >> this should not work for templates that were installed by rpm. >> you will have to use "rpm -e qubes-template-fedora-23" (or similar). > > > I'm a new user of Qubes OS. - I started to use it only with R4.0. > > *Does any of the above concern me?* > > this will also require you clean up anything depending on these >> templates first, like switching all VMs using them to something else, >> removing related dvm templates ... >> > > I'm aware/ took care of that/ already. - This is why I referred to 'remove > old & unused Template VMs'. > > i recommend to keep your one-generation-outdated mainline-template >> around (even if it is EOL) if you can spare the diskspace. >> if you manage to wreck your new mainline template some way, it is >> easier to recover from that with an outdated than with no template. >> > > This advice of yours I don't fully understand - but - I'll defer it to > another message. > I could spare the disk space - but - why should I do that? My understanding from reading the documentation is, that I could re-create the deleted Template VM later in time anyhow, should the need arise ... For example I could execute [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-29 in order to re-create a Template VM, which is used by an 'old' backup-ed App VM, that I've deleted in my current Qubes OS setup. Thanks already in advance for any answers & insights on what I might be missing! With kind regards, VR -- 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/43489590-fb4e-4992-bbd9-0d3d74586627%40googlegroups.com.
Re: [qubes-users] Removing Template VMs?
Thanks for your feedback. Am Montag, 4. Mai 2020 22:25:13 UTC+2 schrieb dhorf-hfr...@hashmail.org: > > On Mon, May 04, 2020 at 12:28:27PM -0700, viktor@gmail.com > wrote: > > If I'd like to remove any old & **unused** Template VMs (e.g. Debian 9, > > Fedora 29, etc.) all I have to do is to start the Qubes Manager, select > the > > template I'd like to remove - and - select 'Delete qube' ... > > this should not work for templates that were installed by rpm. > you will have to use "rpm -e qubes-template-fedora-23" (or similar). I'm a new user of Qubes OS. - I started to use it only with R4.0. *Does any of the above concern me?* this will also require you clean up anything depending on these > templates first, like switching all VMs using them to something else, > removing related dvm templates ... > I'm aware/ took care of that/ already. - This is why I referred to 'remove old & unused *** Template VMs'. i recommend to keep your one-generation-outdated mainline-template > around (even if it is EOL) if you can spare the diskspace. > if you manage to wreck your new mainline template some way, it is > easier to recover from that with an outdated than with no template. > This advice of yours I don't fully understand - but - I'll defer it to another message. With kind regards, VR -- 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/0f75ad8e-df0e-4432-aabb-d25cfd470ad8%40googlegroups.com.
[qubes-users] Removing Template VMs?
Hello community, If I'd like to remove any old & **unused** Template VMs (e.g. Debian 9, Fedora 29, etc.) all I have to do is to start the Qubes Manager, select the template I'd like to remove - and - select 'Delete qube' ... Is this approach OK - or - am I missing something? With kind regards, VR -- 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/a6ef732a-6866-4dad-b378-532643235454%40googlegroups.com.
Re: [qubes-users] Newbie question on package management in a Fedora-based AppVM?
Hello unman, Am Sonntag, 12. April 2020 18:16:39 UTC+2 schrieb unman: > > On Sun, Apr 12, 2020 at 08:20:23AM -0700, viktor@gmail.com > wrote: > > Hello Qubes community, > > > > I'm only a short-term user of Qubes-OS - and - I'm still struggling with > > all the details you have to know & understand. > > > > *How could it be explained, that a package, which was manually installed > > into an freshly created AppVM, get's removed?* > > > > ... > > Welcome to Qubes > > When you use an appVM it is based on a template - almost all the file > system is derived from the template except for files and directories > stored in /rw which includes /home. > This means that when you close down the qube and restart it you get a > clean copy of the rest of the filesystem but any changes in /home/user > will be maintained. > If you install applications in the qube, they will (in most cases) > disappear on a reboot. > To avoid this you need to install the application in the template used > by the qube. > > This is a core feature in Qubes and you can read about it at > https://www.qubes-os.org/doc/template-implementation > I misunderstood the responsibility split b/w TemplateVM & AppVM completely :-( Thanks for your explanation & the link to the relevant documentation! With kind regards, VR -- 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/0d73a258-cf7d-422b-b80d-744dddc72ed4%40googlegroups.com.
Re: [qubes-users] Newbie question on package management in a Fedora-based AppVM?
Hello Fred, Am Sonntag, 12. April 2020 18:10:29 UTC+2 schrieb facethefrag: > > > On 4/12/20 5:20 PM, viktor@gmail.com wrote: > > Hello Qubes community, > > I'm only a short-term user of Qubes-OS - and - I'm still struggling with > all the details you have to know & understand. > > *How could it be explained, that a package, which was manually installed > into an freshly created AppVM, get's removed?* > > ... > > Hello Viktor, > > I'm not so old as a Qubes user too, but as far as I understand, is you > install a packet with dnf (fedora) or apt (debian) in your appVM, it will > disapear once you turn off the AppVM. > > To keep your package from one reboot to another, you have to start a > terminal on the TemplateVM your AppVM is based on. > Then you can add your package in the Template, power off the Template > (don't forget this before next step) and start your AppVM. > > This should work. > I assumed, that I understood what is provided by the TemplateVM - and - what can / is taken care of by the AppVM. I was wrong ... Thanks for your explanation. With kind regards, VR -- 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/989be10d-b88e-4095-ab22-e98c80beaa12%40googlegroups.com.
[qubes-users] Newbie question on package management in a Fedora-based AppVM?
Hello Qubes community, I'm only a short-term user of Qubes-OS - and - I'm still struggling with all the details you have to know & understand. *How could it be explained, that a package, which was manually installed into an freshly created AppVM, get's removed?* I've tried to find an answer or explanation both in the Qubes - as well as - Fedora documentation myself, unfortunately without success. Here's the timeline of the activities I performed in that particular AppVM: ### 2020-04-10 ~ 12:45 - Install PHP & Composer 2020-04-10 ~ 15:00 - Resolve the problem using the built-in web server 2020-04-11 ~ 16:10 - Read & execute the 'Installing Yii' section in 'The Definitive Guide to Yii2' * Unable to install Yii2, since PHP & Composer are no longer found :-( 2020-04-11 ~ 16:50 - Analyze * I guess it's time to learn / read more about 'DNF' ... ### I did not further touch that AppVM, beside running a few DNF commands in order to understand the status a bit better ... Any ideas, what might have happened to this Fedora 30-based AppVM - or - any pointers, what I could check/ do in order to resolve this issue? With kind regards, VR -- 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/777b323f-0708-4f9f-99a6-af89747f9ac0%40googlegroups.com.
Re: [qubes-users] Newbie question on disposable VMs?
Hello Mike, Am Samstag, 21. März 2020 23:05:03 UTC+1 schrieb Mike Keehan: > > On 3/21/20 6:25 PM, viktor@gmail.com wrote: > > Am Samstag, 21. März 2020 18:14:51 UTC+1 schrieb viktor@gmail.com: > > > > Am Samstag, 21. März 2020 14:39:18 UTC+1 schrieb Stumpy: > > > > On 2020-03-21 04:26, Viktor Ransmayr wrote: > > > Am Fr., 20. März 2020 um 21:30 Uhr schrieb < > viktor@gmail.com > > > <mailto:viktor@gmail.com>>: > > > > > ... > > > > > > Additional info & update on question: > > > > > > I'm running Qubes OS 4.0.3 - and - was starting a disposable > > > 'fedora-29-dvm' yesterday & by default the terminal offered > > is an Xterm. > > > > > > This morning it became clear to me, that I should use the > > same setup, > > > that I had used previously with the persistant VMs, i.e. > > where by > > > default a standard (Gnome?) terminal is offered ... > > > > > > I updated the Qube settings for 'fedora-29-dvm', increased > > the memory > > > size & enabled network access. > > > > > > However the terminal only shows up temporarily - and - the > > disposable VM > > > is halted again ... > > > > Sorry, I havent a clue on that one, thought i dont think mem is > > an issue > > as the default is 4gb which should be plenty AFAIR. > > > > I have no clue if this would fix things but since you are on 29 > > and 30 > > has been out you might upgrade to fed 30 which might resolve the > > issue > > you are having. > > > > I'll take your advice, upgrade to F30 - and - will report back here. > > > > I renamed "fedora-29-dvm", changed template to "fedora-30", kept > > networking to "sys-firewall" as well as max memory to 8 GB - plus - I > > exchanged "xterm" with "terminal" & tried again. > > > > However the behaviour did not change. > > > > Is this information sufficient to file a bug report - or - what else > > should I provide? > > > > With kind regards, > > > > VR > > > "Terminal" not showing up in a template has been answered on this list > before. Something to do with the way gnome starts their program, I think. > Thanks a lot for your F/B. - This is the link to the qubes-user msg providing the details: * https://groups.google.com/d/msg/qubes-users/keKZRDawupQ/HYM3m4xmAwAJ No further question ( for the moment ;-) With kind regards, VR -- 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/b60c0124-8a0f-4225-a61b-34041c0dcb88%40googlegroups.com.
Re: [qubes-users] Newbie question on disposable VMs?
Am Samstag, 21. März 2020 18:14:51 UTC+1 schrieb viktor@gmail.com: > > Am Samstag, 21. März 2020 14:39:18 UTC+1 schrieb Stumpy: >> >> On 2020-03-21 04:26, Viktor Ransmayr wrote: >> > Am Fr., 20. März 2020 um 21:30 Uhr schrieb > > <mailto:viktor@gmail.com>>: >> > >> > ... > > >> > Additional info & update on question: >> > >> > I'm running Qubes OS 4.0.3 - and - was starting a disposable >> > 'fedora-29-dvm' yesterday & by default the terminal offered is an >> Xterm. >> > >> > This morning it became clear to me, that I should use the same setup, >> > that I had used previously with the persistant VMs, i.e. where by >> > default a standard (Gnome?) terminal is offered ... >> > >> > I updated the Qube settings for 'fedora-29-dvm', increased the memory >> > size & enabled network access. >> > >> > However the terminal only shows up temporarily - and - the disposable >> VM >> > is halted again ... >> >> Sorry, I havent a clue on that one, thought i dont think mem is an issue >> as the default is 4gb which should be plenty AFAIR. >> >> I have no clue if this would fix things but since you are on 29 and 30 >> has been out you might upgrade to fed 30 which might resolve the issue >> you are having. >> >> > I'll take your advice, upgrade to F30 - and - will report back here. > > I renamed "fedora-29-dvm", changed template to "fedora-30", kept networking to "sys-firewall" as well as max memory to 8 GB - plus - I exchanged "xterm" with "terminal" & tried again. However the behaviour did not change. Is this information sufficient to file a bug report - or - what else should I provide? With kind regards, VR -- 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/3e7c6120-a084-4227-9965-376f3f9916a7%40googlegroups.com.
Re: [qubes-users] Newbie question on disposable VMs?
Am Samstag, 21. März 2020 14:39:18 UTC+1 schrieb Stumpy: > > On 2020-03-21 04:26, Viktor Ransmayr wrote: > > Am Fr., 20. März 2020 um 21:30 Uhr schrieb > > <mailto:viktor@gmail.com >>: > > > > Hello Qubes community, > > > > I'm only a short-term user of Qubes-OS - and - I'm very satisfied so > > far. - Thanks a lot for all your work on this important project! > > > > I'd like to use disposable VMs as a means to efficiently 'simulate' > > E2E installation program experience for in-experienced users. > > > > So far my approach has been to create persistent VMs for it - but - > > I'd like to optimize/ simplify that now by using disposable VMs ... > > > > Now finally my question: > > > > *I am not able to/ I do not know how to copy content from a shell/ > > terminal in a disposable VM to a file in a regular VM :-(* > > For copying text from terminal in any vm to any other vm (except dom0) > is pretty much dependant upon the terminal program you are using. if you > are using xterm then i believe there is a way but its tricky so i cant > help you there (I am 99% sure i found how somewhere on stackexchange) > but with others like Terminator, or the termial that comes with xfce you > should be able to right click for a conext menu, select copy, then > ctrl+shft+c then switch to the vm you want and ctrl+shift+v then paste. > > Thanks, that's what I thought in the morning as well ;-) > If you are talking about moving files then in a terminal you just type > qvm-copy filename > then a window should pop up where you can select what appvm you want it > to go to and it will then put your file(s) in a folder ~/QubesIncomming > > > > > Is this a deliberate design decision - or - what am I missing? > > > > > > Additional info & update on question: > > > > I'm running Qubes OS 4.0.3 - and - was starting a disposable > > 'fedora-29-dvm' yesterday & by default the terminal offered is an Xterm. > > > > This morning it became clear to me, that I should use the same setup, > > that I had used previously with the persistant VMs, i.e. where by > > default a standard (Gnome?) terminal is offered ... > > > > I updated the Qube settings for 'fedora-29-dvm', increased the memory > > size & enabled network access. > > > > However the terminal only shows up temporarily - and - the disposable VM > > is halted again ... > > Sorry, I havent a clue on that one, thought i dont think mem is an issue > as the default is 4gb which should be plenty AFAIR. > > I have no clue if this would fix things but since you are on 29 and 30 > has been out you might upgrade to fed 30 which might resolve the issue > you are having. > > I'll take your advice, upgrade to F30 - and - will report back here. Thanks a lot for your help. With kind regards, VR -- 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/eb6bd26e-b698-4b00-b94e-26f99509d0a8%40googlegroups.com.
Re: [qubes-users] Newbie question on disposable VMs?
Am Fr., 20. März 2020 um 21:30 Uhr schrieb : > Hello Qubes community, > > I'm only a short-term user of Qubes-OS - and - I'm very satisfied so far. > - Thanks a lot for all your work on this important project! > > I'd like to use disposable VMs as a means to efficiently 'simulate' E2E > installation program experience for in-experienced users. > > So far my approach has been to create persistent VMs for it - but - I'd > like to optimize/ simplify that now by using disposable VMs ... > > Now finally my question: > > *I am not able to/ I do not know how to copy content from a shell/ > terminal in a disposable VM to a file in a regular VM :-(* > > Is this a deliberate design decision - or - what am I missing? > Additional info & update on question: I'm running Qubes OS 4.0.3 - and - was starting a disposable 'fedora-29-dvm' yesterday & by default the terminal offered is an Xterm. This morning it became clear to me, that I should use the same setup, that I had used previously with the persistant VMs, i.e. where by default a standard (Gnome?) terminal is offered ... I updated the Qube settings for 'fedora-29-dvm', increased the memory size & enabled network access. However the terminal only shows up temporarily - and - the disposable VM is halted again ... Can somebody explain what is going on? With kind regards, VR -- 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/CAAeSrGKMtWdpG-mzefh9FL7MJOYvYJhUjL9w_W_pZ%3DCc8tvFAA%40mail.gmail.com.
[qubes-users] Newbie question on disposable VMs?
Hello Qubes community, I'm only a short-term user of Qubes-OS - and - I'm very satisfied so far. - Thanks a lot for all your work on this important project! I'd like to use disposable VMs as a means to efficiently 'simulate' E2E installation program experience for in-experienced users. So far my approach has been to create persistent VMs for it - but - I'd like to optimize/ simplify that now by using disposable VMs ... Now finally my question: *I am not able to/ I do not know how to copy content from a shell/ terminal in a disposable VM to a file in a regular VM :-(* Is this a deliberate design decision - or - what am I missing? With kind regards, VR -- 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/af4051b9-3b98-4370-bfb3-0fe2d2b98c79%40googlegroups.com.
