Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/09/2019 3.46 AM, 'Heinrich Ulbricht' via qubes-users wrote: >> Personally, I would just stick with this. In other words, I would treat >> the new Qubes installation as completely new and use qvm-backup-restore >> as the only mechanism for migrating my old data to the new installation. >> This is the only way I would be confident that I weren't screwing >> anything up. >> >> > Thank you very much for helping me out on this, awokd and Andrew. Currently > I'm leaning toward taking the safe path. If I understand correctly that > means: > >1. Backup everything that's on the SSD *and* the external storage pool >HDDs - this will take a lot of time and space but that's the price I have >to pay for the safety I get >2. Connect the new SSD, wipe the external drives >3. Install Qubes OS on the new SSD >4. Create external storage pools on the additional HDDs >5. Make the SSD the default pool; restore VMs for SSD >6. Make external disk 1 the default pool; restore VMs for this pool >7. Make external disk 2 the default pool; restore VMs for this pool >8. Switch default pool back to SSD >9. Done > > How does this sound? > I haven't personally used external storage pools, so I can't comment there. (Thankfully, though, others have already weighed in on that part.) Related to Brendan's point, in step 1, it's important to *verify* the backups you've just created. GUI: Qube Manager -> Restore qubes from backup -> [x] Verify backup integrity, do not restore the data CLI: qvm-backup-restore --verify-only [...] As the saying goes: Backups always succeed. It's restores that fail. (If you have the extra disks, it would technically be even safer to use new HDDs and refrain from wiping the existing ones until after you've verified that everything is correct in the new system, but this might be overly cautious. I personally don't feel the need to do this anymore, because I know the data is already there in a verified Qubes backup, and I've tested my ability to manually recover it independently of Qubes as a last resort.) Aside from these caveats, your plan sounds like what I would do. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1sloEACgkQ203TvDlQ MDDqdg//cFoY4k/EFm5t2pVpoiFKubh/o34CzJo8eYfOWgHaNnnVlhfqXGartWkS F5aSeig2PiPWpPqfJ9G4mWV46ySjC/hez0fSmAl2rsNA/PaRTAG/aIhIy7DlNuoo H9MQJw5TsiHvgz6h/FfYVOcl1/mDOwmVw4n9WQ1x49bgsmI+CdZf94c7P+XvEpde YM3G2hGi6e1Bd3H3Xm1B5EtovsMXC3ieDkXDYlun814t1jBv0BmVib93vRaltHIt Bdd766BAvhkdMOOWONHfmOrw1An7FBm1uKIxdJb71w5Kltv8VV1S7xXq387/QmGF fcdJljdEtArgxg4Pe35i03GseDjRfw1rhsH3TL/8PDjY2P1n+lwI5JG8+fa7ZPUM FHKoQAiPk9D3d8vOXmnwVT8QrCdaJvnX0bqtihusUnUh13+ZCrP5akq3KE7hrIn3 dgVG6eywbwS/Y18pbXChdvDdz3kx6Q05cB56nsFfyR65amLJh7F3NmkVd20HBDoh yNxEqWMaHLiz/chOLLXFxUy8nAor/CQ8JgRPbERh40M5l67jzhFEXgHRl5u4XmbM g8iNpYbFoUsBDP8bSzgPIFaNJ/OuUGnNsXtyYGwfxTzH45UMHLqGCqAPPdRUqaRB W3JYH81cFnRVJdqBU+bj+1GPyD6an31++0ahJFX11DawHiP8nEc= =d7uO -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/88f9196b-3c91-ef70-308c-2652db893ab4%40qubes-os.org.
Re: [qubes-users] Custom installation: "You must create a new filesystem"
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/09/2019 8.03 AM, Claudia wrote: > Andrew David Wong: >> On 31/08/2019 11.23 AM, Claudia wrote: >>> The "Custom Installation" doc gives instructions about how to >>> create a non-default dm-crypt partition, or other custom setup, >>> and install Qubes to it. But when I follow these instructions >>> on R4.0.1, and try to assign my dm-crypt device to "/", I get >>> a message something like >>> >>> "You must create a new filesystem for the root filesystem." >>> >> >> That's odd. I don't remember getting a message like that when I >> installed 4.0 this way > First, thanks for your reply! > > BTW, the actual message is "You must create a new file system on > the root device." (I was going from memory.) > > Okay, so I think I might have figured it out: The tutorial should > work for any filesystem other than btrfs, provided you check the > "Reformat" option. Upon closer examination, your tutorial covers > creation of dm-crypt and LVM containers, but not any filesystems. > The installer does create the actual filesystem, so that's why the > tutorial doesn't cause the message about creating a new filesystem. > It's just that btrfs isn't one of the options. > > When there is an empty dm-crypt partition on the disk, under > "Unknown" category it shows up as "luks-" and asks for a > password. Once unlocked, all options are greyed out, including > Mountpoint, except Label and Reformat. When check Reformat, the > File System drop down is enabled, but btrfs is not an option. So at > this point I could use another filesystem, just not btrfs. The > "Encrypt" checkbox is also enabled and checked by default. > > When I manually format that partition with btrfs, it shows up > under "Unknown" as "Encrypted (LUKS)" and asks for a password. Once > unlocked, it shows under "Unknown" as "btrfs" and all options are > greyed out except Mountpoint and Label. But when I enter "/" as > mountpoint I get that message. I would be fine with replacing the > filesystem in the container, but the "Reformat" box is unchecked > and greyed out. > > Like I said, I thought I got around it somehow, but I don't > remember for sure. I might have given up and used the default > cryptsetup options. > > >> >> Well, the Qubes installer is mostly just the upstream Fedora >> installer, so you might want to file bug reports with them about >> these issues. > > I was afraid of that. I may try to look into it some more and > perhaps see if it's a reportable bug. But the more I'm looking at > it, I think they would call it a "feature" of this deranged > installer. (See below.) I really just want to get past it. > >> >>> I remember running into this before, and I thought I >>> eventually got around it somehow after playing with it for an >>> hour or two. But I don't remember. I might have just ended up >>> using the default dm-crypt parameters. >>> >>> Idea 1: LUKS allows you to change some, but not all, >>> parameters after installation. So you can change the iter-time, >>> for example, but not the key size, cipher, or hash size(?). Not >>> great, but might work for some situations. >>> >>> Idea 2: In my case I want to use btrfs, so I'm thinking I can >>> create a small standard partition at the end of the disk, >>> install to that, then once installed, `btrfs device add` my >>> custom dm-crypt root partition and `btrfs device remove` the >>> original, and optionally delete the temporary partition and >>> grow the real one. I don't yet know what changes will have to >>> be made to the bootloader/dracut config, but I'm assuming the >>> UUID at the very least. >>> >>> Aside from dm-crypt and btrfs, there are also plenty of >>> situations where someone might want to install to an existing >>> device or filesystem. >>> >>> Some of this has been talked about in #2294, but it's not quite >>> the same thing. >>> >>> So I guess this is mostly just a rant. But I was also wondering >>> 1) Am I doing something wrong? Should I not be seeing this >>> message? Is it a bug? >> >> Could be. As mentioned above, I don't remember seeing this when I >> went through it myself. >> >>> 2) Why isn't this addressed in the custom installation >>> tutorial? Why do we have a tutorial that cannot be followed? >> >> I wrote this version of the tutorial because I couldn't find any >> information about how to do this sort of thing on R4 anywhere. I >> went through the trial-and-error and documented my findings for >> the benefit of others (and my future self). But I'm certainly not >> an expert in all the underlying technologies. It worked for me >> when I wrote it, and no one else has contributed to it since >> then. I'm honestly sorry to hear that it didn't work for you, but >> I don't know why it didn't. I can simply remove it from the >> documentation if it's no longer working. > > Did you happen to do any testing with btrfs when you wrote the > tutorial? At this point I don't think the tutorial is faulty,
Re: [qubes-users] Custom installation: "You must create a new filesystem"
Andrew David Wong: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 31/08/2019 11.23 AM, Claudia wrote: The "Custom Installation" doc gives instructions about how to create a non-default dm-crypt partition, or other custom setup, and install Qubes to it. But when I follow these instructions on R4.0.1, and try to assign my dm-crypt device to "/", I get a message something like "You must create a new filesystem for the root filesystem." That's odd. I don't remember getting a message like that when I installed 4.0 this way First, thanks for your reply! BTW, the actual message is "You must create a new file system on the root device." (I was going from memory.) Okay, so I think I might have figured it out: The tutorial should work for any filesystem other than btrfs, provided you check the "Reformat" option. Upon closer examination, your tutorial covers creation of dm-crypt and LVM containers, but not any filesystems. The installer does create the actual filesystem, so that's why the tutorial doesn't cause the message about creating a new filesystem. It's just that btrfs isn't one of the options. When there is an empty dm-crypt partition on the disk, under "Unknown" category it shows up as "luks-" and asks for a password. Once unlocked, all options are greyed out, including Mountpoint, except Label and Reformat. When check Reformat, the File System drop down is enabled, but btrfs is not an option. So at this point I could use another filesystem, just not btrfs. The "Encrypt" checkbox is also enabled and checked by default. When I manually format that partition with btrfs, it shows up under "Unknown" as "Encrypted (LUKS)" and asks for a password. Once unlocked, it shows under "Unknown" as "btrfs" and all options are greyed out except Mountpoint and Label. But when I enter "/" as mountpoint I get that message. I would be fine with replacing the filesystem in the container, but the "Reformat" box is unchecked and greyed out. Like I said, I thought I got around it somehow, but I don't remember for sure. I might have given up and used the default cryptsetup options. Well, the Qubes installer is mostly just the upstream Fedora installer, so you might want to file bug reports with them about these issues. I was afraid of that. I may try to look into it some more and perhaps see if it's a reportable bug. But the more I'm looking at it, I think they would call it a "feature" of this deranged installer. (See below.) I really just want to get past it. I remember running into this before, and I thought I eventually got around it somehow after playing with it for an hour or two. But I don't remember. I might have just ended up using the default dm-crypt parameters. Idea 1: LUKS allows you to change some, but not all, parameters after installation. So you can change the iter-time, for example, but not the key size, cipher, or hash size(?). Not great, but might work for some situations. Idea 2: In my case I want to use btrfs, so I'm thinking I can create a small standard partition at the end of the disk, install to that, then once installed, `btrfs device add` my custom dm-crypt root partition and `btrfs device remove` the original, and optionally delete the temporary partition and grow the real one. I don't yet know what changes will have to be made to the bootloader/dracut config, but I'm assuming the UUID at the very least. Aside from dm-crypt and btrfs, there are also plenty of situations where someone might want to install to an existing device or filesystem. Some of this has been talked about in #2294, but it's not quite the same thing. So I guess this is mostly just a rant. But I was also wondering 1) Am I doing something wrong? Should I not be seeing this message? Is it a bug? Could be. As mentioned above, I don't remember seeing this when I went through it myself. 2) Why isn't this addressed in the custom installation tutorial? Why do we have a tutorial that cannot be followed? I wrote this version of the tutorial because I couldn't find any information about how to do this sort of thing on R4 anywhere. I went through the trial-and-error and documented my findings for the benefit of others (and my future self). But I'm certainly not an expert in all the underlying technologies. It worked for me when I wrote it, and no one else has contributed to it since then. I'm honestly sorry to hear that it didn't work for you, but I don't know why it didn't. I can simply remove it from the documentation if it's no longer working. Did you happen to do any testing with btrfs when you wrote the tutorial? At this point I don't think the tutorial is faulty, I think it just cannot be used with btrfs. Like I said, though, bug #2294 talks about this very problem. So I'm at least not imagining things. Although it doesn't mention the exact error message (I could have sworn it did). In #2294, under "General Notes" > "Not Workarounds:" "If you also manually create
Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?
On Sunday, September 1, 2019 at 12:00:20 PM UTC+2, donoban wrote: > > On 9/1/19 10:46 AM, 'Heinrich Ulbricht' via qubes-users wrote: > > Thank you very much for helping me out on this, awokd and Andrew. > > Currently I'm leaning toward taking the safe path. If I understand > > correctly that means: > > > > 1. Backup everything that's on the SSD /and/ the external storage pool > > HDDs - this will take a lot of time and space but that's the price I > > have to pay for the safety I get > > 2. Connect the new SSD, wipe the external drives > > 3. Install Qubes OS on the new SSD > > 4. Create external storage pools on the additional HDDs > > 5. Make the SSD the default pool; restore VMs for SSD > > 6. Make external disk 1 the default pool; restore VMs for this pool > > 7. Make external disk 2 the default pool; restore VMs for this pool > > 8. Switch default pool back to SSD > > 9. Done > > > > How does this sound? > > > > Hi, > > I recently did a hard disk upgrade and reinstall so I followed this same > steps. > > Generally it should work fine but in mi experience there is a little > issue[1] that can cause additional delay on the process. In steps 6/7, > if your destination hard disk is slower than the your main hard disk > (where dom0 is installed), your backup will be full extracted on dom0, > so you can run out of space if you don't take this in account. > > If your dom0 is smaller than the total amount to extract, you should > restore your domains grouping them in a reasonable amount. > > Another way is changing the temporary directory for the restore process > but it can not be changed with command arguments. You need to modify > 'restore.py' or mount /var/tmp on another device, or use symbolic link. > > [1] https://github.com/QubesOS/qubes-issues/issues/3230 > Thank you very much for pointing this out. Sounds like a lot of saved troubleshooting time for me as I might run into this. I think I'm set for the safe path (although the shortcut proposed by Chris Laprise sounds tempting). I'll report back how it went. -- 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/6c7ef9dc-37cc-43f7-b59e-cc22c3b33355%40googlegroups.com.
Re: [qubes-users] KERNEL PANIC on booting installation media - Acer TravelMate B116 - Details Inside
'awokd' via qubes-users: > 'awokd' via qubes-users: > >>> HYP: 0 0 0 0 Hypervisor callback >>> interrupts >>> HRE: 0 0 0 0 Hyper-V reenlightenment >>> interrupts >>> HVS: 0 0 0 0 Hyper-V stimer0 >>> interrupts >> >>> PIN: 0 0 0 0 Posted-interrupt >>> notification event > > Meant > NPI: 0 0 0 0 Nested > posted-interrupt event > > instead of PIN. > >> These 4 make it look like you are running in a Hypervisor. Some security >> feature or malware? > Try checking /proc/interrupts in a different distro too, like Mint maybe. -- 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/0ba527c6-9641-01a0-28ef-34122be17c8e%40danwin1210.me.
Re: [qubes-users] Software installed in template does not work in appVM
On Sunday, September 1, 2019 at 3:46:00 PM UTC+2, Антон Чехов wrote: > > > > On Sunday, September 1, 2019 at 3:32:24 PM UTC+2, awokd wrote: >> >> 'Антон Чехов' via qubes-users: >> > Hi, >> > >> > I have a small problem that I don't know how to tackle. >> > I've installed a language software/dictionary in a clone of the Fedora >> 30 >> > Template. The parent folder in the template is /home/user/. I can start >> the >> > program by going to the folder and using a shell script ( >> ./script-name). >> > When I shut down the template and opened a Fedora-appVM based on the >> > template-clone there was a menu entry available with the name of the >> > program. Unfortunately it didn't start. Furthermore I couldn't find any >> > traces of the program but to be honest I never had to look up how the >> > software is connected to a templateVM. >> > >> > Any help would be appreciated. >> > >> TL;DR version- Since that dictionary installs in /home/user, install it >> in the AppVM instead. >> >> Long version- >> https://www.qubes-os.org/doc/templates/#inheritance-and-persistence. >> > > > Thanks for your answer but doesn't that mean I should install the program > somewhere else than /home in a templateVM? Moving it is not possible, is it? > Has anyone installed a licensed software in a template, activated it, and > then successfully started it in an App? Is this possible? > > The dictionary can be used with any document or browser. When I move the > cursor over a word, the translation will be shown in the program. It would > be a nice addition but of course one installation in an AppVM would also be > enough. > Okay, I tried myself and moved the folder from /home to /etc and the program did open via terminal in every Fedora based appVM but the activation showed an error message. Also there were problems with fonts and the dictionary wasn't displayed correctly. I then did install the program in the appVM like recommended and now everything is working fine, including the shortcut in the appVM menu. Thanks! -- 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/bc845504-d4eb-4f24-be3a-215ec4f8208b%40googlegroups.com.
Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?
On 9/1/19 7:38 AM, 'awokd' via qubes-users wrote: 'Heinrich Ulbricht' via qubes-users: 1. Backup everything that's on the SSD *and* the external storage pool HDDs - this will take a lot of time and space but that's the price I have to pay for the safety I get 2. Connect the new SSD, wipe the external drives 3. Install Qubes OS on the new SSD 4. Create external storage pools on the additional HDDs 5. Make the SSD the default pool; restore VMs for SSD 6. Make external disk 1 the default pool; restore VMs for this pool 7. Make external disk 2 the default pool; restore VMs for this pool 8. Switch default pool back to SSD 9. Done How does this sound? This looks good, with the caveats others noted in this thread. For posterity, a couple of true 'shortcut' methods are possible (although using backup+restore is always safer). One method involves dd'ing the entire old drive contents onto the new drive. At the end you'll have to expand the partition holding qubes_dom0, as well as the volume group itself and pool00 in order to have access to the additional space on the new drive; but that should be easy. A second method uses LVM management commands to mirror the volume group onto the new drive, but there would be extra steps you'd need to take for a Qubes boot partition: https://casesup.com/knowledgebase/how-to-migrate-lvm-to-new-storage/ -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/2dbed92d-5413-5072-16db-6a61e30023e1%40posteo.net.
[qubes-users] Re: Device showing up in Qubes sys-usb terminal but not devices icon, and attach error in dom0
Le vendredi 30 août 2019 21:02:44 UTC+2, rec wins a écrit : > > On 8/30/19 2:40 AM, unman wrote: > > On Thu, Aug 29, 2019 at 08:58:33PM -1000, rec wins wrote: > >> On 8/29/19 1:49 AM, unman wrote: > >>> On Wed, Aug 28, 2019 at 09:01:46PM -1000, rec wins wrote: > On 5/27/19 6:09 AM, Stumpy wrote: > > I am trying to use an onlykey U2F but have run into some issues like > it > > showing up in dom0 and sys-usb but seems like i cant use it. > > > > in sys-usb: > > [user@sys-usb ~]$ lsusb | grep Only > > Bus 004 Device 010: ID 1d50:60fc OpenMoko, Inc. OnlyKey Two-factor > > Authentication and Password Solution > > > > and in Dom0: > > [ralph@dom0 ~]$ qvm-usb | grep ONLY ; sudo qvm-usb a sys-usb > sys-usb:42 > > sys-usb:4-2 CRYPTOTRUST_ONLYKEY_346etc > > Device attach failed: > > [ralph@dom0 ~]$ > > > > I decided to go with the chrome app but even though sys-usb seems to > see > > the onlykey I cant seem to attach it to the chrome appvm i made? > > > > > so in dom0 you did > $qvm-usb > > get the BDM number and do > > $qvm-usb attach chromevm sys-usb:X-X > > U2F keys will work in chromium for google logins with no > complicated passthrough setup necessary > > OTP won't , if the key does more than U2F you may need to get a > configuration application for the key and make sure it's U2F only > slot 1 , 2 etc > > >>> > >>> Have you looked at the qubes-u2f-proxy package? > >>> https://www.qubes-os.org/doc/u2f-proxy > >>> > >>> After installation in dom0 and the relevant template, you enable the > >>> service in the qube you want to use it in, and the device should then > >>> be available for use in that qube. > >>> You *dont* attach the USB device to the qube. > >>> > >>> Try that, and see how you get on. > >>> > >>> unman > >>> > >> > >> > >> attaching does work(only in chromium fwiw) even with the FF > about:config > >> changes, though, apparently this isn't 'secure' so > >> > >> looking at the u2f proxy at this point > >> > >> > >> Repeat qvm-service --enable (or do this in VM settings -> Services in > >> the Qube Manager) for all qubes that should have the proxy enabled. As > >> usual with software updates, shut down the templates after > installation, > >> then restart sys-usb and all qubes that use the proxy. After that, you > >> may use your U2F token (but see Browser support below). > >> > >> > >> after installing the proxy in the templates and shutting them down, and > >> restarting the appVMs based on them. there is No qvm-service to > >> do qvm-service --enable > >> > >> and/or what or where is this supposed to be 'repeated' ? > >> > >> "Repeat qvm-service --enable for all qubes that should have the proxy > >> enabled." > >> > >> sure sounds like by "qubes" what is meant is the AppVMs or TBAVM > or > >> whatever they are called now :) > >> > > "qube" is a "user friendly term for a VM" > > (https://www.qubes-os.org/doc/glossary;) > > > > qvm-service is a dom0 command line tool - you can also enable the > > service in the GUI interface as noted in the instructions. > > You enable the service for *each* qube where you want to use the proxy - > > that's the "repeat" part. > > Check the policy file in /etc/qubes-rpc/policy/ > > > > > OK seems to be operational now in FF , not sure what I was supposed to > see in /policy/ > > @dom0 ~]$ !529 > cat /etc/qubes-rpc/policy/u2f.Register > $anyvm sys-usb allow,user=root > > > u2f.Authenticate says the same > > > > Stumpy did you do this : > > https://docs.crp.to/qubes.html > > > need to keep the support organize or just gets too complicated IMO > or are you Sebastian please bottompost unman, awokd, brendan > are the ones to talk to > Could you post a step by step explanation ? Is your OnlyKey working simultaneously with U2F proxy AND as a keyboard in dom0 ? THX Sébastien -- 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/4169554b-84e4-488e-ae8c-30501b1f1da0%40googlegroups.com.
Re: [qubes-users] Re: Device showing up in Qubes sys-usb terminal but not devices icon, and attach error in dom0
Le vendredi 30 août 2019 14:40:51 UTC+2, unman a écrit : > > On Thu, Aug 29, 2019 at 08:58:33PM -1000, rec wins wrote: > > On 8/29/19 1:49 AM, unman wrote: > > > On Wed, Aug 28, 2019 at 09:01:46PM -1000, rec wins wrote: > > >> On 5/27/19 6:09 AM, Stumpy wrote: > > >>> I am trying to use an onlykey U2F but have run into some issues like > it > > >>> showing up in dom0 and sys-usb but seems like i cant use it. > > >>> > > >>> in sys-usb: > > >>> [user@sys-usb ~]$ lsusb | grep Only > > >>> Bus 004 Device 010: ID 1d50:60fc OpenMoko, Inc. OnlyKey Two-factor > > >>> Authentication and Password Solution > > >>> > > >>> and in Dom0: > > >>> [ralph@dom0 ~]$ qvm-usb | grep ONLY ; sudo qvm-usb a sys-usb > sys-usb:42 > > >>> sys-usb:4-2 CRYPTOTRUST_ONLYKEY_346etc > > >>> Device attach failed: > > >>> [ralph@dom0 ~]$ > > >>> > > >>> I decided to go with the chrome app but even though sys-usb seems to > see > > >>> the onlykey I cant seem to attach it to the chrome appvm i made? > > >>> > > >> > > >> > > >> so in dom0 you did > > >> $qvm-usb > > >> > > >> get the BDM number and do > > >> > > >> $qvm-usb attach chromevm sys-usb:X-X > > >> > > >> U2F keys will work in chromium for google logins with no > > >> complicated passthrough setup necessary > > >> > > >> OTP won't , if the key does more than U2F you may need to get a > > >> configuration application for the key and make sure it's U2F only > > >> slot 1 , 2 etc > > >> > > > > > > Have you looked at the qubes-u2f-proxy package? > > > https://www.qubes-os.org/doc/u2f-proxy > > > > > > After installation in dom0 and the relevant template, you enable the > > > service in the qube you want to use it in, and the device should then > > > be available for use in that qube. > > > You *dont* attach the USB device to the qube. > > > > > > Try that, and see how you get on. > > > > > > unman > > > > > > > > > attaching does work(only in chromium fwiw) even with the FF about:config > > changes, though, apparently this isn't 'secure' so > > > > looking at the u2f proxy at this point > > > > > > Repeat qvm-service --enable (or do this in VM settings -> Services in > > the Qube Manager) for all qubes that should have the proxy enabled. As > > usual with software updates, shut down the templates after installation, > > then restart sys-usb and all qubes that use the proxy. After that, you > > may use your U2F token (but see Browser support below). > > > > > > after installing the proxy in the templates and shutting them down, and > > restarting the appVMs based on them. there is No qvm-service to > > do qvm-service --enable > > > > and/or what or where is this supposed to be 'repeated' ? > > > > "Repeat qvm-service --enable for all qubes that should have the proxy > > enabled." > > > > sure sounds like by "qubes" what is meant is the AppVMs or TBAVM or > > whatever they are called now :) > > > "qube" is a "user friendly term for a VM" > (https://www.qubes-os.org/doc/glossary;) > > qvm-service is a dom0 command line tool - you can also enable the > service in the GUI interface as noted in the instructions. > You enable the service for *each* qube where you want to use the proxy - > that's the "repeat" part. > Check the policy file in /etc/qubes-rpc/policy/ > U2F proxy not working for me, neither Chrome or FF. Directly attaching the Onlykey to the vm works for U2F but after detaching, Onlykey is no more a keyboard in dom0. I did : https://docs.crp.to/qubes.html Is : https://raw.githubusercontent.com/trustcrypto/trustcrypto.github.io/master/49-onlykey.rules needed in sys-usb ? THX Sébastien -- 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/66c4a2a7-e6f1-4730-a180-f28edb17853d%40googlegroups.com.
[qubes-users] 4.0.2
Is there any timeline for the release of 4.0.2 Final? Steve -- 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/ba16a4ae-8bbd-4ecc-9d12-b1c532fdbf5a%40googlegroups.com.
Re: [qubes-users] Software installed in template does not work in appVM
On Sunday, September 1, 2019 at 3:32:24 PM UTC+2, awokd wrote: > > 'Антон Чехов' via qubes-users: > > Hi, > > > > I have a small problem that I don't know how to tackle. > > I've installed a language software/dictionary in a clone of the Fedora > 30 > > Template. The parent folder in the template is /home/user/. I can start > the > > program by going to the folder and using a shell script ( > ./script-name). > > When I shut down the template and opened a Fedora-appVM based on the > > template-clone there was a menu entry available with the name of the > > program. Unfortunately it didn't start. Furthermore I couldn't find any > > traces of the program but to be honest I never had to look up how the > > software is connected to a templateVM. > > > > Any help would be appreciated. > > > TL;DR version- Since that dictionary installs in /home/user, install it > in the AppVM instead. > > Long version- > https://www.qubes-os.org/doc/templates/#inheritance-and-persistence. > Thanks for your answer but doesn't that mean I should install the program somewhere else than /home in a templateVM? Moving it is not possible, is it? Has anyone installed a licensed software in a template, activated it, and then successfully started it in an App? Is this possible? The dictionary can be used with any document or browser. When I move the cursor over a word, the translation will be shown in the program. It would be a nice addition but of course one installation in an AppVM would also be enough. -- 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/c290c6a1-c264-4fc5-af47-28d8e9ba7114%40googlegroups.com.
Re: [qubes-users] Software installed in template does not work in appVM
'Антон Чехов' via qubes-users: > Hi, > > I have a small problem that I don't know how to tackle. > I've installed a language software/dictionary in a clone of the Fedora 30 > Template. The parent folder in the template is /home/user/. I can start the > program by going to the folder and using a shell script ( ./script-name). > When I shut down the template and opened a Fedora-appVM based on the > template-clone there was a menu entry available with the name of the > program. Unfortunately it didn't start. Furthermore I couldn't find any > traces of the program but to be honest I never had to look up how the > software is connected to a templateVM. > > Any help would be appreciated. > TL;DR version- Since that dictionary installs in /home/user, install it in the AppVM instead. Long version- https://www.qubes-os.org/doc/templates/#inheritance-and-persistence. -- 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/023657f6-091f-3f16-16e9-14df089f4d06%40danwin1210.me.
[qubes-users] Software installed in template does not work in appVM
Hi, I have a small problem that I don't know how to tackle. I've installed a language software/dictionary in a clone of the Fedora 30 Template. The parent folder in the template is /home/user/. I can start the program by going to the folder and using a shell script ( ./script-name). When I shut down the template and opened a Fedora-appVM based on the template-clone there was a menu entry available with the name of the program. Unfortunately it didn't start. Furthermore I couldn't find any traces of the program but to be honest I never had to look up how the software is connected to a templateVM. Any help would be appreciated. -- 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/91625c1d-5920-428a-8958-de08f02c800e%40googlegroups.com.
Re: [qubes-users] KERNEL PANIC on booting installation media - Acer TravelMate B116 - Details Inside
'awokd' via qubes-users: >> HYP: 0 0 0 0 Hypervisor callback >> interrupts >> HRE: 0 0 0 0 Hyper-V reenlightenment >> interrupts >> HVS: 0 0 0 0 Hyper-V stimer0 >> interrupts > >> PIN: 0 0 0 0 Posted-interrupt >> notification event Meant NPI: 0 0 0 0 Nested posted-interrupt event instead of PIN. > These 4 make it look like you are running in a Hypervisor. Some security > feature or malware? -- 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/2b30a798-8fa3-6409-4824-918b94fca30f%40danwin1210.me.
Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?
'Heinrich Ulbricht' via qubes-users: >1. Backup everything that's on the SSD *and* the external storage pool >HDDs - this will take a lot of time and space but that's the price I have >to pay for the safety I get >2. Connect the new SSD, wipe the external drives >3. Install Qubes OS on the new SSD >4. Create external storage pools on the additional HDDs >5. Make the SSD the default pool; restore VMs for SSD >6. Make external disk 1 the default pool; restore VMs for this pool >7. Make external disk 2 the default pool; restore VMs for this pool >8. Switch default pool back to SSD >9. Done > > How does this sound? > This looks good, with the caveats others noted in 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/fd4eeac2-5fe2-9488-b95c-370597adf2c3%40danwin1210.me.
Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?
I would advise against wiping any disks until you are sure the full set of restores are complete and tested. I’ve learned the hard way to never put myself into a situation where I cannot revert to my original configuration. 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/a8cd7eb9-cb89-4007-a0ce-bde17f3a37cb%40googlegroups.com.
Re: [qubes-users] KERNEL PANIC on booting installation media - Acer TravelMate B116 - Details Inside
Guest: > The requested details are inline below. > > Below are the outputs of /proc/interrupts, lspci, lsusb, and uname. Taken on > the latest tails, with all possible peripherals disabled in the bios. > > ---snip--- > cat /proc/interrupts: > CPU0 CPU1 CPU2 CPU3 > 118: 0 0 0 0 hdmi_lpe_audio_irqchip > -hdmi_lpe_audio_irq_handler hdmi-lpe-audio > 119: 0 0 0 0 INT0002 Virtual GPIO2 > ACPI:Event These two look different. Can you disable hdmi audio? That Virtual GPIO might be related to the below 4. > HYP: 0 0 0 0 Hypervisor callback > interrupts > HRE: 0 0 0 0 Hyper-V reenlightenment > interrupts > HVS: 0 0 0 0 Hyper-V stimer0 interrupts > PIN: 0 0 0 0 Posted-interrupt > notification event These 4 make it look like you are running in a Hypervisor. Some security feature or malware? > 00:1a.0 Encryption controller: Intel Corporation Atom/Celeron/Pentium > Processor x5-E8000/J3xxx/N3xxx Series Trusted Execution Engine (rev 21) Is Secure Boot disabled? -- 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/ce836751-6acc-6dfa-becb-518f6b75310e%40danwin1210.me.
Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8/31/19 9:12 PM, donoban wrote: > On 9/1/19 10:46 AM, 'Heinrich Ulbricht' via qubes-users wrote: >> Thank you very much for helping me out on this, awokd and >> Andrew. Currently I'm leaning toward taking the safe path. If I >> understand correctly that means: >> >> 1. Backup everything that's on the SSD /and/ the external storage >> pool HDDs - this will take a lot of time and space but that's the >> price I have to pay for the safety I get 2. Connect the new SSD, >> wipe the external drives 3. Install Qubes OS on the new SSD 4. >> Create external storage pools on the additional HDDs 5. Make the >> SSD the default pool; restore VMs for SSD 6. Make external disk 1 >> the default pool; restore VMs for this pool 7. Make external disk >> 2 the default pool; restore VMs for this pool 8. Switch default >> pool back to SSD 9. Done >> >> How does this sound? >> > > Hi, > > I recently did a hard disk upgrade and reinstall so I followed this > same steps. > > Generally it should work fine but in mi experience there is a > little issue[1] that can cause additional delay on the process. In > steps 6/7, if your destination hard disk is slower than the your > main hard disk (where dom0 is installed), your backup will be full > extracted on dom0, so you can run out of space if you don't take > this in account. > > If your dom0 is smaller than the total amount to extract, you > should restore your domains grouping them in a reasonable amount. > > Another way is changing the temporary directory for the restore > process but it can not be changed with command arguments. You need > to modify 'restore.py' or mount /var/tmp on another device, or use > symbolic link. > > [1] https://github.com/QubesOS/qubes-issues/issues/3230 > Ouch, marked as Spam. Trying with pgp sign... -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEznLCgPSfWTT+LPrmFBMQ2OPtCKUFAl1qynkACgkQFBMQ2OPt CKW7sRAAjwiDddhSFN6+FEhVfBqhcdHE4iE6l6YnGXpXEDnMB5Q7cVIFKp8+NQmp 03C75NcGE67Mfpuqw+9rxw/ZJvJKm+zVbCa5RTp7k0Ei/WA9qPQSCuTnX5eXDBZp a3ioZvgo7I05p0euipv6uMqUfRbmz3b5crXLU4b7x+/Z2snet90NyaQdjNEeelA1 HmaRDX3EFFvgee079VxXfl+W1Msh/D9MC7HOel6/Q3Q/UaBW9OxVPMXO/KOjF4VK W8bmuttGsjpBXWeLJz8xYWquU5tEBMkVSZp1eXmM+Z0CT6OjKv2AcFMjfMm+80EJ ECC8zuv+NlUR3qnggzXfFk0F3fhrGvKL8uBH1UBw+f0sFmdWMIxtb8SzCvOwA0PG nsCvPdvKegsXoNrQdzljIwNl/zhzZI4L3AeicnbqtOusZhKuB9nxinSD5LEA1N7C q9uiHEnVePtgjUBLXeOPZo477iVHKn/ulOjGemnaf2TtD9sZXUqC3VGRjNKO6ofg owjF76df3vduMudivBXHzm2q1+DU25NEENBzIjqFMmyagDQgM+V/3OUXAIFEtDWj H9yjxTxAKw+/4OrGRWQirIVhF2lfjA/wTnSyjfjqnuGVlL7CBh/lMYgukGZdrxL3 rBHpVwHg+6ppRHHeO4GwtsX2naWvK86Mild1UGCeQ3FvyN0qVTI= =j234 -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/d3609bb2-e0cd-39a7-729e-6fd29d421c57%40riseup.net.
Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?
On 9/1/19 10:46 AM, 'Heinrich Ulbricht' via qubes-users wrote: Thank you very much for helping me out on this, awokd and Andrew. Currently I'm leaning toward taking the safe path. If I understand correctly that means: 1. Backup everything that's on the SSD /and/ the external storage pool HDDs - this will take a lot of time and space but that's the price I have to pay for the safety I get 2. Connect the new SSD, wipe the external drives 3. Install Qubes OS on the new SSD 4. Create external storage pools on the additional HDDs 5. Make the SSD the default pool; restore VMs for SSD 6. Make external disk 1 the default pool; restore VMs for this pool 7. Make external disk 2 the default pool; restore VMs for this pool 8. Switch default pool back to SSD 9. Done How does this sound? Hi, I recently did a hard disk upgrade and reinstall so I followed this same steps. Generally it should work fine but in mi experience there is a little issue[1] that can cause additional delay on the process. In steps 6/7, if your destination hard disk is slower than the your main hard disk (where dom0 is installed), your backup will be full extracted on dom0, so you can run out of space if you don't take this in account. If your dom0 is smaller than the total amount to extract, you should restore your domains grouping them in a reasonable amount. Another way is changing the temporary directory for the restore process but it can not be changed with command arguments. You need to modify 'restore.py' or mount /var/tmp on another device, or use symbolic link. [1] https://github.com/QubesOS/qubes-issues/issues/3230 -- 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/d8ef668b-d5e3-4451-1d4d-beb5dbfa845c%40riseup.net.
Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?
> Personally, I would just stick with this. In other words, I would treat > the new Qubes installation as completely new and use qvm-backup-restore > as the only mechanism for migrating my old data to the new installation. > This is the only way I would be confident that I weren't screwing > anything up. > > Thank you very much for helping me out on this, awokd and Andrew. Currently I'm leaning toward taking the safe path. If I understand correctly that means: 1. Backup everything that's on the SSD *and* the external storage pool HDDs - this will take a lot of time and space but that's the price I have to pay for the safety I get 2. Connect the new SSD, wipe the external drives 3. Install Qubes OS on the new SSD 4. Create external storage pools on the additional HDDs 5. Make the SSD the default pool; restore VMs for SSD 6. Make external disk 1 the default pool; restore VMs for this pool 7. Make external disk 2 the default pool; restore VMs for this pool 8. Switch default pool back to SSD 9. Done How does this sound? -- 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/84d1e9c3-d2f6-4262-b3fa-fd62140109d5%40googlegroups.com.
Re: [qubes-users] KERNEL PANIC on booting installation media - Acer TravelMate B116 - Details Inside
The requested details are inline below. I really appreciate you looking into this - Thanks. If there are any other thoughts and ideas to try to isolate the problem am happy to try and revert. At 20:21 31/08/2019, 'awokd' via qubes-users wrote: >>> At 23:22 28/08/2019, 'awokd' via qubes-users wrote: >>> Update BIOS first. Do those Acers have a hardware peripheral in common between them, like a webcam? If so, disable it in BIOS, then try a reinstall. If not, disable all possible integrated peripherals (or enable all if you've disabled something) and try again. > >Spent some time digging through code. Looks like it is somehow grabbing >an interrupt that's not physical, but a lot of this is above my pay grade! I get that often when looking at code ;-) >Does it have a NVMe controller? Nothing like it - a simple SATA controller (see below for lspci output) >Can you put it in SATA compatible mode, >or if a regular storage controller IDE instead of AHCI? No, the BIOS does not have and such options - no SATA compatible option in the BIOS and no IDE controller available in hardware. >Otherwise, try booting a regular distro on it and copying & pasting "cat >/proc/interrupts" here. Below are the outputs of /proc/interrupts, lspci, lsusb, and uname. Taken on the latest tails, with all possible peripherals disabled in the bios. ---snip--- cat /proc/interrupts: CPU0 CPU1 CPU2 CPU3 0: 8 0 0 0 IO-APIC2-edge timer 1: 0 0444 0 IO-APIC1-edge i8042 8: 0 0 0 0 IO-APIC8-edge rtc0 9: 0 2 0 0 IO-APIC9-fasteoi acpi, INT0002 12: 0140 0 0 IO-APIC 12-edge i8042 18: 0 0 0 0 IO-APIC 18-fasteoi i801_smbus 32: 0 0 0 0 IO-APIC 32-fasteoi 808622C1:00 43: 0 0 0 0 IO-APIC 43-fasteoi dw:dmac-1 45: 0 52 0 0 IO-APIC 45-fasteoi mmc0 115: 0 0 41183 0 PCI-MSI 327680-edge xhci_hcd 116: 0 0 0 1883 PCI-MSI 311296-edge ahci[:00:13.0] 117: 27211 0 0 0 PCI-MSI 32768-edge i915 118: 0 0 0 0 hdmi_lpe_audio_irqchip -hdmi_lpe_audio_irq_handler hdmi-lpe-audio 119: 0 0 0 0 INT0002 Virtual GPIO2 ACPI:Event 120: 0 0 0 0 PCI-MSI 180224-edge proc_thermal NMI: 14 15 17 16 Non-maskable interrupts LOC: 71011 66702 72938 68160 Local timer interrupts SPU: 0 0 0 0 Spurious interrupts PMI: 14 15 17 16 Performance monitoring interrupts IWI:171 20 11 17 IRQ work interrupts RTR: 0 0 0 0 APIC ICR read retries RES: 14206 11466 11147 11923 Rescheduling interrupts CAL: 8511 6653 4262 5411 Function call interrupts TLB:235283104108 TLB shootdowns TRM: 0 0 0 0 Thermal event interrupts THR: 0 0 0 0 Threshold APIC interrupts DFR: 0 0 0 0 Deferred Error APIC interrupts MCE: 0 0 0 0 Machine check exceptions MCP: 3 3 3 3 Machine check polls HYP: 0 0 0 0 Hypervisor callback interrupts HRE: 0 0 0 0 Hyper-V reenlightenment interrupts HVS: 0 0 0 0 Hyper-V stimer0 interrupts ERR: 0 MIS: 0 PIN: 0 0 0 0 Posted-interrupt notification event NPI: 0 0 0 0 Nested posted-interrupt event PIW: 0 0 0 0 Posted-interrupt wakeup event lcpci: 00:00.0 Host bridge: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SoC Transaction Register (rev 21) 00:02.0 VGA compatible controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Integrated Graphics Controller (rev 21) 00:0b.0 Signal processing controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series Power Management Controller (rev 21) 00:13.0 SATA controller: Intel Corporation Atom/Celeron/Pentium Processor x5-E8000/J3xxx/N3xxx Series SATA Controller (rev 21) 00:14.0 USB controller: Intel Corporation
