Re: [qubes-users] Re: Install of the Fedora-32 templateVM failed
On Monday, May 18, 2020 at 6:01:13 PM UTC-4, TheGardner wrote: > > understood. > Guess I have to do some backups, which I have to move to my NAS. The new > machine will take two months longer. Have to come out with the current > space until then. > > Is it possible that you haven't invoked the --clean parameter (sudo qubes-dom0-update --clean) to ensure the local cache in your updatedvm (sys-firewall) is cleared before the next download? Brendan -- 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/b533ff86-a9c8-48fc-be56-b24097481ebe%40googlegroups.com.
Re: [qubes-users] modifying files with salt
On Mon, May 18, 2020 at 09:01:02PM +0100, lik...@gmx.de wrote: > Hi! > > I'm trying to modify the /etc/fuse.conf > > by using this sls file: > > --- > modify-config-files: > file.replace: > - path: /etc/fuse.conf > - pattern: "# mount_max = 1000" > - repl: "mount_max = 1000" > - append_if_not_found: True > #- dry_run: True > > > Result is: > Execute a packaged state run, the packaged state run will exist in a > tarball available locally. This packaged state > can be generated using salt-ssh. > > CLI Example: > > .. code-block:: bash > > salt '*' state.pkg /tmp/salt_state.tgz > 760a9353810e36f6d81416366fc426dc md5 > > > The file /etc/fuse.conf is not changed afterwards. > Google couldn't help me to resolve that problem. Any hints here from > saltstack pros? > I'd probably use file.uncomment in this case. For file.replace try rewriting your file: /etc/fuse.conf: file.replace: - pattern: ^#.*mount_max.* - repl: "mount_max = 1000" - append_if_not_found: True That should work. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200519010303.GA7181%40thirdeyesecurity.org.
Re: [qubes-users] Re: Install of the Fedora-32 templateVM failed
understood. Guess I have to do some backups, which I have to move to my NAS. The new machine will take two months longer. Have to come out with the current space until then. Am Montag, 18. Mai 2020 23:52:08 UTC+2 schrieb dhorf-hfr...@hashmail.org: > > On Mon, May 18, 2020 at 02:38:34PM -0700, TheGardner wrote: > > [user@sys-firewall ~]$ df -h /var/lib/qubes/dom0-updates > > /dev/xvda3 9.6G 8.7G 450M 96% / > > > sudo mkfs.ext4 /dev/xvdc3 > > sudo mount /dev/xvdc3 /var/lib/qubes/dom0-updates > > > Do I have to change (back) somethings, after I installed the template > and > > removed the noarch.rpm file from dom0-updates ? > > xvdc is the "volatile" volume. > so this change will vanish on its own the next time you restart > sys-firewall. > > > > -- 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/9b5d7c99-5258-4bde-86fc-ebada4621d08%40googlegroups.com.
Re: [qubes-users] Re: Install of the Fedora-32 templateVM failed
On Mon, May 18, 2020 at 02:38:34PM -0700, TheGardner wrote: > [user@sys-firewall ~]$ df -h /var/lib/qubes/dom0-updates > /dev/xvda3 9.6G 8.7G 450M 96% / > sudo mkfs.ext4 /dev/xvdc3 > sudo mount /dev/xvdc3 /var/lib/qubes/dom0-updates > Do I have to change (back) somethings, after I installed the template and > removed the noarch.rpm file from dom0-updates ? xvdc is the "volatile" volume. so this change will vanish on its own the next time you restart sys-firewall. -- 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/20200518215202.GO1079%40priv-mua.
Re: [qubes-users] Re: using salt - how to debug?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I think the pillar files need to be in /srv/pillar/ The following example should work: /srv/pillar/fedora-version.top base: dom0: - fedora-version /srv/pillar/fedora-version.sls version: 31 Then the file needs to be linked to another directory: ln -s /srv/pillar/fedora-version.top /srv/pillar/_tops/base/fedora-version.top This can be tested with the following command: sudo qubesctl pillar.get version And can be used in salt files as you have used it -BEGIN PGP SIGNATURE- iIgEARMKADAWIQRFNnsoPo7HH0XEMXc88cBGMbAIWAUCXsMAEhIccHJhZ29AdHV0 YW5vdGEuZGUACgkQPPHARjGwCFjP2AD/bV5z2DEkRvGtHEbv32MbRAAPN1uZDvfR MR9DzIPEKnUA/2Zfz12HtzdtA/pIEAZoDceKrNLp7iua2Lk8HyStuyUw =eySN -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/M7djpTm--3-2%40tuta.io.
Re: [qubes-users] Re: Install of the Fedora-32 templateVM failed
Okay, df -h /var/lib/qubes/dom0-updates delivered the following: [user@sys-firewall ~]$ df -h /var/lib/qubes/dom0-updates Filesystem Size Used Avail Use% Mounted on /dev/xvda3 9.6G 8.7G 450M 96% / so, clear now! Thanks a buch! After: sudo mkfs.ext4 /dev/xvdc3 sudo mount /dev/xvdc3 /var/lib/qubes/dom0-updates it already worked like a charm and download the 1.3G file. Do I have to change (back) somethings, after I installed the template and removed the noarch.rpm file from dom0-updates ? Cheers :) Am Montag, 18. Mai 2020 12:56:59 UTC+2 schrieb dhorf-hfr...@hashmail.org: > > On Mon, May 18, 2020 at 03:33:02AM -0700, TheGardner wrote: > > - Setting the space up to 4096 on sys-firewall > same result > > the default download location in udaptevm is /var/lib/qubes/dom0-updates > so with a default appvm layout that is inside the rootfs (or its overlay). > you can check if this is the limiting factor by running > "df -h /var/lib/qubes/dom0-updates" in your updatevm (sys-firewall). > > to temporarily make more space available there, you can try ... > > > > -- 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/357eaea6-c601-4244-97ac-225f8b6e2f56%40googlegroups.com.
[qubes-users] Re: Choice of hardware for Qubes...
What about Macbook Pro 16 ? On Monday, May 11, 2020 at 12:40:13 PM UTC+3, Andrew Sullivan wrote: > > Good morning > > I plan to try Qubes, with a view to maybe using it as my main OS. Happily > I also need to update my laptop. > > I've been looking at the HCL, and see that Dell and Lenovo machines seem > to rate quite well. The Dell Outlet web site has some (apparently) > compatible machines at what look like good prices, and maybe buying from > them might be safer than Amazon/eBay (I'm in the UK btw). Two that I am > considering are: > > Latitude E5470 - claimed to be fully compatible with R4.0, can install > 32GB RAM, but only has a 14" (FHD) screen, might take a second 2242-format > SSD (although mixed reports on this) > > M4800 - bit of a monster, but portability isn't really an issue; also > takes 32GB RAM, lots of potential storage space, 15" screen (it won't be > the QHD screen). > > Any thoughts would be appreciated. > > TIA > -- 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/cf1a1736-3337-4b78-95d0-714a517d4aa7%40googlegroups.com.
[qubes-users] modifying files with salt
Hi! I'm trying to modify the /etc/fuse.conf by using this sls file: --- modify-config-files: file.replace: - path: /etc/fuse.conf - pattern: "# mount_max = 1000" - repl: "mount_max = 1000" - append_if_not_found: True #- dry_run: True Result is: Execute a packaged state run, the packaged state run will exist in a tarball available locally. This packaged state can be generated using salt-ssh. CLI Example: .. code-block:: bash salt '*' state.pkg /tmp/salt_state.tgz 760a9353810e36f6d81416366fc426dc md5 The file /etc/fuse.conf is not changed afterwards. Google couldn't help me to resolve that problem. Any hints here from saltstack pros? -- 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/fdcf7056-9ee1-bb78-c36a-6b95a738a8c7%40gmx.de.
[qubes-users] Re: using salt - how to debug?
On 2020-05-17 17:08, unman wrote:
On Sun, May 17, 2020 at 09:55:00AM +0100, liked2-mmb7mzph...@public.gmane.org
wrote:
You haven't included AppVmTobeChanged as a target:
qubesctl --show-output --targets=AppVmTobeChanged state.highstate
You should check that you aren't getting a mistaken dom0 call.
That made the trick. Thanks unman!
One step forward, but still a way to go:
Currently I'm struggling to use pillars in my scripts. I have my scripts in
/srv/salt/user_salt
/srv/salt/user_pillar
Trying to enable a script containing some constants doesn't work because they
cannot be found.
The only way to use pillars for me is passing them at the command line:
qubesctl ... pillar='{"name": "value"}'
But in this case I get errors in some scripts like this:
TypeError encountered executing state.highstate: highstate() takes from 0 to 1
positional arguments but 2 were given
after executing this commandline:
sudo qubesctl --show-output --target AppVmTobeChanged state.highstate pillar='{"name":
"value"}'
Best case I'd manage to include pillars in my scripts. Any ideas how?
Can you post examples of the pillars you have written?
What exactly are you trying to do?
My current goal is to automate the update of a fedora template as soon as a new
one is available.
I'm trying to achieve this by these steps:
1. creating a clone of the default template
2. update this template with packages for a special purpose template
Details:
I created a top file like this:
/srv/salt/user_salt/create_my_special_purpose_template.top
base:
dom0:
- match: nodegroup
- user_salt.create-template-clone
't-fedora-*-template-clone':
- user_salt.install-pkgs-for-special-purpose-template
/srv/salt/user_salt/create_my_special_purpose_template.top
1. creating a clone of the default template is done by this file
/srv/salt/user_salt/create-template-clone.sls
create-template-clone:
qvm.clone:
- name: t-fedora-{{ pillar['version'] }}-special-purpose-template
- source: fedora-{{ pillar['version'] }}-minimal
/srv/salt/user_salt/create-template-clone.sls
2. update this template with packages for a special purpose template
/srv/salt/user_salt/install-pkgs-for-special-purpose-template.sls
install-packages:
pkg.installed:
- pkgs:
- nano
- refresh: True
/srv/salt/user_salt/install-pkgs-for-special-purpose-template.sls
In step 2 I'm trying to use pillars to be less dependent from the fedora
version.
When I'm running the command:
sudo qubesctl --show-output --target t-fedora-31-template-clone state.highstate
pillar='{"version": "31"}'
I get the error:
TypeError encountered executing state.highstate: highstate() takes from 0 to 1
positional arguments but 2 were given
That's why I'm trying to include pillars at least as a file, but don't manage
to include them, so that they could by used by step 1.
Thank you very much by reading this long story... :) And if you've suggestion
to solve it I even more appreciate it. :))
--
You received this message because you are subscribed to the Google Groups
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/2466f4d6-de4b-d4bb-1a3c-766fe97ecde5%40gmx.de.
Re: [qubes-users] Mistakenly deleted MBR & system partitions to install, can't boot Qubes
On 5/18/20 5:28 PM, sjill...@gmail.com wrote: On Monday, May 18, 2020 at 8:27:17 AM UTC-6, Mike Keehan wrote: On 5/17/20 8:34 PM, sjil...@gmail.com wrote: Hello! Thank you for replying, nvme0n1p 953G (hd1) nvme0n1p1 1MBIOS boot efi (hd1,1) this is WAY too small. make it at least 100M, better 500M or even 1GB. Per your advice I've tried reinstalling to make this partition bigger. I deleted the previous qubes partitions, and all partitions except the windows-backup and pops-partition, then clicked the "let qubes set mount points" option and it auto-populated boot and the other qubes partitions, when I clicked on the one you mention and try to change the "desired capacity" will not accept more than 2MiB. I tried manually creating this partition, but as soon as I select BiosBoot it changes from my input of 1GB to 2MiB. I maximized the other boot option too, to see if that would help. I did not. After reinstallation I still can't boot. nvme0n1p2 1GLinux Filesystem (hd1,2) nvme0n1p3 324.8G Linux LVM(hd1,3) 15 G Qubes-dom0-swap this indicates you manually changed the partition layout for qubes in too many ways to count, including removing the disk encrpytion. good luck with that. I did not. I only deleted partitions and kept a windows-backup and a pop_Os partition, qubes did everything else. I left off encryption because I thought that was the reason I couldn't see it in grub to manually boot it. I left encryption on for this new install. But have changed nothing else. I assembled the above from fdisk -l and grub ls command, but perhaps it is confusing or I was confused, I attached a picture of qubes layout from the install screen so you can see it easier (the "unknown" is partitions 5 & 6 the windows/pop partitions, there is no partition 4). [image: qubesinstall.jpg] Thanks again for your help. You say "I deleted the previous qubes partitions, and all partitions except...". This doesn't sound good - deleting Qubes partitions would be OK, but "all other partitions" may not be right. I suggest you post an output from fdisk -l so we can see what partitions are present, and how they are arranged on the disk. Mike. Hi Mike, Yeah, really seems I messed up... My fdisk -l: mint@mint ~ $ sudo fdisk -l Disk /dev/ram0: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram1: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram2: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram3: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram4: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram5: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram6: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram7: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram8: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram9: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram10: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram11: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram12: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk
Re: [qubes-users] Mistakenly deleted MBR & system partitions to install, can't boot Qubes
On Monday, May 18, 2020 at 8:27:17 AM UTC-6, Mike Keehan wrote: > > On 5/17/20 8:34 PM, sjil...@gmail.com wrote: > > Hello! > > > > Thank you for replying, > > > >> nvme0n1p 953G (hd1) > >>> nvme0n1p1 1MBIOS boot efi (hd1,1) > >> > >> this is WAY too small. > >> make it at least 100M, better 500M or even 1GB. > >> > >> Per your advice I've tried reinstalling to make this partition bigger. > I > > deleted the previous qubes partitions, and all partitions except the > > windows-backup and pops-partition, then clicked the "let qubes set mount > > points" option and it auto-populated boot and the other qubes > partitions, > > when I clicked on the one you mention and try to change the "desired > > capacity" will not accept more than 2MiB. I tried manually creating > this > > partition, but as soon as I select BiosBoot it changes from my input of > 1GB > > to 2MiB. I maximized the other boot option too, to see if that would > help. > > I did not. After reinstallation I still can't boot. > > > >>> nvme0n1p2 1GLinux Filesystem (hd1,2) > >>> nvme0n1p3 324.8G Linux LVM(hd1,3) > >>> 15 G Qubes-dom0-swap > > > >> this indicates you manually changed the partition layout for qubes > >> in too many ways to count, including removing the disk encrpytion. > >> good luck with that. > > > > I did not. I only deleted partitions and kept a windows-backup and a > > pop_Os partition, qubes did everything else. I left off encryption > because > > I thought that was the reason I couldn't see it in grub to manually boot > > it. I left encryption on for this new install. But have changed > nothing > > else. I assembled the above from fdisk -l and grub ls command, but > perhaps > > it is confusing or I was confused, I attached a picture of qubes layout > > from the install screen so you can see it easier (the "unknown" is > > partitions 5 & 6 the windows/pop partitions, there is no partition 4). > > > > [image: qubesinstall.jpg] > > Thanks again for your help. > > > > You say "I deleted the previous qubes partitions, and all partitions > except...". This doesn't sound good - deleting Qubes partitions would > be OK, but "all other partitions" may not be right. > > I suggest you post an output from fdisk -l so we can see what partitions > are present, and how they are arranged on the disk. > > Mike. > Hi Mike, Yeah, really seems I messed up... My fdisk -l: mint@mint ~ $ sudo fdisk -l Disk /dev/ram0: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram1: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram2: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram3: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram4: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram5: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram6: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram7: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram8: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram9: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram10: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram11: 64 MiB, 67108864 bytes, 131072 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk /dev/ram12: 64 MiB,
Re: [qubes-users] Mistakenly deleted MBR & system partitions to install, can't boot Qubes
On 5/17/20 8:34 PM, sjill...@gmail.com wrote: Hello! Thank you for replying, nvme0n1p 953G (hd1) nvme0n1p1 1MBIOS boot efi (hd1,1) this is WAY too small. make it at least 100M, better 500M or even 1GB. Per your advice I've tried reinstalling to make this partition bigger. I deleted the previous qubes partitions, and all partitions except the windows-backup and pops-partition, then clicked the "let qubes set mount points" option and it auto-populated boot and the other qubes partitions, when I clicked on the one you mention and try to change the "desired capacity" will not accept more than 2MiB. I tried manually creating this partition, but as soon as I select BiosBoot it changes from my input of 1GB to 2MiB. I maximized the other boot option too, to see if that would help. I did not. After reinstallation I still can't boot. nvme0n1p2 1GLinux Filesystem (hd1,2) nvme0n1p3 324.8G Linux LVM(hd1,3) 15 G Qubes-dom0-swap this indicates you manually changed the partition layout for qubes in too many ways to count, including removing the disk encrpytion. good luck with that. I did not. I only deleted partitions and kept a windows-backup and a pop_Os partition, qubes did everything else. I left off encryption because I thought that was the reason I couldn't see it in grub to manually boot it. I left encryption on for this new install. But have changed nothing else. I assembled the above from fdisk -l and grub ls command, but perhaps it is confusing or I was confused, I attached a picture of qubes layout from the install screen so you can see it easier (the "unknown" is partitions 5 & 6 the windows/pop partitions, there is no partition 4). [image: qubesinstall.jpg] Thanks again for your help. You say "I deleted the previous qubes partitions, and all partitions except...". This doesn't sound good - deleting Qubes partitions would be OK, but "all other partitions" may not be right. I suggest you post an output from fdisk -l so we can see what partitions are present, and how they are arranged on the disk. Mike. -- 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/f01bf4b4-b796-2830-9bff-89a36fcaa5ad%40keehan.net.
Re: [qubes-users] running programs as room in sys-usb?
On 5/18/20 2:33 PM, Stumpy wrote: On 2020-05-18 08:52, Mike Keehan wrote: On 5/18/20 1:43 PM, Stumpy wrote: I have sys-usb based on fedora minimal and when i try to run something like qvm-run -u root sys-usb xterm from dom0 it just hangs (the command, not the whole computer) until i ctrl+c out. Is there some reason i shouldnt be able to do this? I imagine qvm-run will require some qubes package to be installed in the vm, and fedora-minimal doesn't have it. The Qubes documentation website contains some details on what is needed in a minimal template for some purposes. Mike. Thanks. Does it count that i can run the minimal template that sys-usb is based on as root? that is something like: qvm-run -u root fedora-30-minimal xterm and it starts right up? or is that different? Ah, that's "interesting". I guess you have the right packages installed. It might be a Qubes policy thing, but I have never tried looking into those. Sorry, I can't help much now. Mike. -- 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/89e48978-eefa-0cb0-5704-5bfae4d574ae%40keehan.net.
Re: [qubes-users] running programs as room in sys-usb?
On 2020-05-18 08:52, Mike Keehan wrote: On 5/18/20 1:43 PM, Stumpy wrote: I have sys-usb based on fedora minimal and when i try to run something like qvm-run -u root sys-usb xterm from dom0 it just hangs (the command, not the whole computer) until i ctrl+c out. Is there some reason i shouldnt be able to do this? I imagine qvm-run will require some qubes package to be installed in the vm, and fedora-minimal doesn't have it. The Qubes documentation website contains some details on what is needed in a minimal template for some purposes. Mike. Thanks. Does it count that i can run the minimal template that sys-usb is based on as root? that is something like: qvm-run -u root fedora-30-minimal xterm and it starts right up? or is that different? -- 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/2ce00564-6e36-4356-f367-4d8add23a412%40posteo.net.
Re: [qubes-users] running programs as room in sys-usb?
On 5/18/20 1:43 PM, Stumpy wrote: I have sys-usb based on fedora minimal and when i try to run something like qvm-run -u root sys-usb xterm from dom0 it just hangs (the command, not the whole computer) until i ctrl+c out. Is there some reason i shouldnt be able to do this? I imagine qvm-run will require some qubes package to be installed in the vm, and fedora-minimal doesn't have it. The Qubes documentation website contains some details on what is needed in a minimal template for some purposes. Mike. -- 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/2c91bd78-122b-0e4c-910a-2e1b05c75388%40keehan.net.
Re: [qubes-users] Installing ulauncher in dom0?
On 2020-05-13 09:33, Stumpy wrote: I keep running up against limitations of xfce's application launcher and wanted to ask about the security implications of installing something like ulauncher? My threat model is less about being directly targeted and more about general secuirty against malware, privacy, and perhaps soft targeting (not sure if thats even a real phrase but scammers no nation state or hacker groups). With that said, there are really very few laucnhers being actively maintained nowadays. dmenu is fine for i3 but I am looking for a "floating" launcher. ulauncher does everything i need and more but also (seems) to have the added risk of plugins but then again, i am not sure about all this so wanted to ask. nada? -- 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/4f9fe519-843c-01d1-2030-b0a18a63fdcf%40posteo.net.
[qubes-users] running programs as room in sys-usb?
I have sys-usb based on fedora minimal and when i try to run something like qvm-run -u root sys-usb xterm from dom0 it just hangs (the command, not the whole computer) until i ctrl+c out. Is there some reason i shouldnt be able to do this? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6ca9d261-4284-a971-9fec-3efe46872616%40posteo.net.
Re: [qubes-users] Re: Install of the Fedora-32 templateVM failed
On Mon, May 18, 2020 at 03:33:02AM -0700, TheGardner wrote: > - Setting the space up to 4096 on sys-firewall > same result the default download location in udaptevm is /var/lib/qubes/dom0-updates so with a default appvm layout that is inside the rootfs (or its overlay). you can check if this is the limiting factor by running "df -h /var/lib/qubes/dom0-updates" in your updatevm (sys-firewall). to temporarily make more space available there, you can try ... sudo mkfs.ext4 /dev/xvdc3 sudo mount /dev/xvdc3 /var/lib/qubes/dom0-updates sudo chown user.user /var/lib/qubes/dom0-updates -- 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/20200518105633.GN1079%40priv-mua.
[qubes-users] Re: Install of the Fedora-32 templateVM failed
No chance! Whatever I do, it always breaks after around 360mb. Really feels like there isn't enough space. Wonder where I can see this. - Setting the space up to 4096 on sys-firewall > same result - setting the boost and minimal cube emory (for dom0) up > same result Anyone which an idea, what I'm doing wrong? Am Samstag, 16. Mai 2020 15:25:37 UTC+2 schrieb TheGardner: > > Currently try to install the Fedora-32(-testing) template on my Qubes-OS > and it always fail during the initial download (after around 350mb). > Question now is - is the disk space of my updateVM full? And if - can I > check this with a command? > > -- 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/19fb0f98-5b2a-4fc3-b178-c430d966fcd0%40googlegroups.com.
Re: [qubes-users] Persistent Timezone per Qube
Hello, you can put the command "timedatectl set-timezone Asia/Kolkata" in /rw/config/rc.local in your appvm, It will owerwrite the template's timezone. On 20/05/18 07:26AM, Logan wrote: > Hello, > > What is the best way to set a timezone for a particular qube that is > constantly behind a proxy in a particular timezone? > > I have tried "timedatectl set-timezone Asia/Kolkata", but it isn't > persistent. I would rather not use NTP if possible. I thought sticking the > timedatectl > > Thanks, > Logan > > -- > 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/33c8fd5f-0e44-88bf-8612-5f783ae80289%40threatmodel.io. -- 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/20200518080726.rokf4a25hxl4hdyv%40disp6806.
[qubes-users] Persistent Timezone per Qube
Hello, What is the best way to set a timezone for a particular qube that is constantly behind a proxy in a particular timezone? I have tried "timedatectl set-timezone Asia/Kolkata", but it isn't persistent. I would rather not use NTP if possible. I thought sticking the timedatectl Thanks, Logan -- 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/33c8fd5f-0e44-88bf-8612-5f783ae80289%40threatmodel.io. publickey - logan@threatmodel.io.asc.pgp Description: application/pgp-key signature.asc Description: OpenPGP digital signature
