Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)
I use a custom dracut module from the2nd, ykluks, so I don't know about how to modify it to unlock multiple volumes. Also, I may want to stick with LUKS instead of ecryptfs because yubikey support. Can you elaborate on the steps for using Btrfs during install of Qubes, the documentation is still pretty old and doesn't really go over the non standard options. Does Qubes 4.0 need LVM for snapshots and backups while vm is running? I haven't seen anything about why LVM thin provisioning is done on Qubes, or what I would lose if I went with something else like Btrfs or even Ext4. Here's what I think my setup will have to be: nvme0n1 (2 drives in hw RAID 0) ├─nvme0n1p1 part /boot └─nvme0n1p2 part └─luks (same key) crypt ├─qubes_dom0-pool00_tmeta lvm ├─qubes_dom0-pool00_tdata lvm │ └─qubes_dom0-pool00-tpool lvm │ ├─qubes_dom0-pool00 lvm │ ├─qubes_dom0-root lvm / │ └─ ... vm lvm └─qubes_dom0-swap lvm [SWAP] sda (2 drives in hw RAID 0) └─sda1part └─luks (same key) crypt └─qubes_dom0-pool00_tdata lvm └─qubes_dom0-pool00-tpool lvm ├─qubes_dom0-pool00 lvm ├─qubes_dom0-root lvm / └─ ... vm lvm And if I need another drive added (sdb),... I just insert the drive, create another luks partition, unlock, add to Volume Group (qubes-dom0), lvextend pool00? - What would Btrfs look like? This?: nvme0n1 (2 drives in hw RAID 0) ├─nvme0n1p1 part /boot └─nvme0n1p2 part └─luks (same key) crypt ├─qubes (btrfs) part / └─qubes_dom0-swap part [SWAP] sda (2 drives in hw RAID 0) └─sda1part └─luks (same key) crypt └─qubes (btrfs) part / Under Btrfs, does qubes simply have each vm as a image file under the /var/lib/qubes/appvms// directory? Do I lose the ability to backup live, or any other features? How does performance compare to LVM And to add another drive (sdb), how would I extend with Btrfs? Thanks Chris. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fd83485c-3dab-4421-97b1-30d26388feb5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)
On 08/13/2018 05:32 PM, joevio...@gmail.com wrote: On Monday, 13 August 2018 17:13:06 UTC-4, Chris Laprise wrote: On 08/13/2018 04:47 PM, Related question. If I installed Qubes and used LUKS encryption (I have to run cryptsetup openLuks just to see the LVM inside)... then I add physical drives to my Volume Group, and start adding more AppVMs to the pool, that starts writing to the PV... Is the data on the new drive, encrypted? Can anyone forensically pull data from those new AppVMs since it wasn't originally a part of the LUKS encrypted drive? Based on the sparse description I'd say No, the new space is not encrypted. You have to add separate LUKS/dmcrypt block layers to those new devices and then treat those dmcrypt block devices as the new pvs. If you're doing this to qubes_dom0, then it could be a little tricky getting all of the encrypted "pvs" to unlock at the same time during the boot process. You'd need to investigate how crypttab and grub accommodate that multi-volume setup. -- Chris Laprise PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 I would imagine it would require a longer grub entry with rd.luks attributes for other UUIDs. Yes, but if you can get crypttab to accept multiple volumes that share a keyfile or password then dracut may be able to setup the grub entries automatically. But it seems I have an LVM over LUKS configuration... when what I want is a LUKS over LVM. [...] The problem is that Qubes 4.0 manipulates lvm directly so unless you opt for Qubes managing your vms with Ext4 image files (not a nice way to go), what you could end up with is: lvm --> luks --> lvm --> device And I don't think that could truly work under ideal conditions because thats COW on top of COW. This is also the reason that Btrfs on lvm is frowned upon... stacking this way is not reliable. If I choose btrfs for my next install, I can avoid the LVM problems, but can I expand onto new physical volumes by adding more drives? IMO, Btrfs gives you some added reliability and simplicity - devices can be added and removed with ease, even when it reduces overall space. But since encryption is still a separate luks layer you're still faced with managing multiple luks volumes under Btrfs. The only other possibility I can think of is to experiment with ecryptfs on top of Btrfs. If you got it to work with Qubes it could span physical volumes easily and the main (only?) downside would be increased vulnerability to _physical_ (not remote) attacks. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f0e94454-b91f-547b-17fd-f7697c2c4a31%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)
On Monday, 13 August 2018 17:13:06 UTC-4, Chris Laprise wrote: > On 08/13/2018 04:47 PM, > > Related question. > > > > If I installed Qubes and used LUKS encryption (I have to run cryptsetup > > openLuks just to see the LVM inside)... then I add physical drives to my > > Volume Group, and start adding more AppVMs to the pool, that starts writing > > to the PV... > > Is the data on the new drive, encrypted? > > Can anyone forensically pull data from those new AppVMs since it wasn't > > originally a part of the LUKS encrypted drive? > > Based on the sparse description I'd say No, the new space is not > encrypted. You have to add separate LUKS/dmcrypt block layers to those > new devices and then treat those dmcrypt block devices as the new pvs. > > If you're doing this to qubes_dom0, then it could be a little tricky > getting all of the encrypted "pvs" to unlock at the same time during the > boot process. You'd need to investigate how crypttab and grub > accommodate that multi-volume setup. > > -- > > Chris Laprise > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 I would imagine it would require a longer grub entry with rd.luks attributes for other UUIDs. But it seems I have an LVM over LUKS configuration... when what I want is a LUKS over LVM. Here's what I have: [root@dom0]# lsblk | grep -v "\-\-" NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sdb8:16 0 3.7T 0 disk └─sdb1 8:17 0 3.7T 0 part ├─qubes_dom0-pool00_tmeta 253:10 2.1G 0 lvm │ └─qubes_dom0-pool00-tpool253:30 1T 0 lvm │ ├─qubes_dom0-pool00253:60 1T 0 lvm │ ├─qubes_dom0-root 253:40 192.6G 0 lvm / ├─qubes_dom0-pool00_meta0 253:63 0 2.1G 0 lvm └─qubes_dom0-pool00_tdata 253:20 1T 0 lvm └─qubes_dom0-pool00-tpool253:30 1T 0 lvm ├─qubes_dom0-pool00253:60 1T 0 lvm ├─qubes_dom0-root 253:40 192.6G 0 lvm / sr0 11:01 1024M 0 rom loop0 7:00 500M 0 loop sda8:00 232.9G 0 disk └─sda1 8:10 232.9G 0 part nvme0n1 259:00 232.9G 0 disk ├─nvme0n1p1 259:10 1G 0 part /boot └─nvme0n1p2 259:20 231.9G 0 part └─luks-bfcca13a-213d-46ec-b156-53df348dba30253:00 231.9G 0 crypt ├─qubes_dom0-pool00_tdata253:20 1T 0 lvm │ └─qubes_dom0-pool00-tpool 253:30 1T 0 lvm │ ├─qubes_dom0-pool00 253:60 1T 0 lvm │ ├─qubes_dom0-root253:40 192.6G 0 lvm / └─qubes_dom0-swap253:50 23.3G 0 lvm [SWAP] Even better, I should look into a RAID setup too. If I choose btrfs for my next install, I can avoid the LVM problems, but can I expand onto new physical volumes by adding more drives? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a43f228b-819b-449f-916e-658bfba2a128%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)
On 08/13/2018 04:47 PM, joevio...@gmail.com wrote: Related question. If I installed Qubes and used LUKS encryption (I have to run cryptsetup openLuks just to see the LVM inside)... then I add physical drives to my Volume Group, and start adding more AppVMs to the pool, that starts writing to the PV... Is the data on the new drive, encrypted? Can anyone forensically pull data from those new AppVMs since it wasn't originally a part of the LUKS encrypted drive? Based on the sparse description I'd say No, the new space is not encrypted. You have to add separate LUKS/dmcrypt block layers to those new devices and then treat those dmcrypt block devices as the new pvs. If you're doing this to qubes_dom0, then it could be a little tricky getting all of the encrypted "pvs" to unlock at the same time during the boot process. You'd need to investigate how crypttab and grub accommodate that multi-volume setup. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/6640ddad-eb8f-9caf-5b0e-8284270d80a7%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)
Related question. If I installed Qubes and used LUKS encryption (I have to run cryptsetup openLuks just to see the LVM inside)... then I add physical drives to my Volume Group, and start adding more AppVMs to the pool, that starts writing to the PV... Is the data on the new drive, encrypted? Can anyone forensically pull data from those new AppVMs since it wasn't originally a part of the LUKS encrypted drive? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fb9e3b7d-472e-42d6-ba46-f11f9974d0c8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
