On Monday, 13 August 2018 16:13:06 UTC-4, Chris Laprise wrote: > On 08/13/2018 06:48 AM, 'awokd' via qubes-users wrote: > > On Mon, August 13, 2018 7:59 am, > > > >> Should I mount each LV > >> and attempt to import the root.img and private.img files? How would I > >> mount those to get to the files, and how would import to Qubes? > > > > Sounds pretty FUBARd. LVs don't have .img files; if you can manage to get > > them mounted you might be able to recover contents. Boot from some > > recovery distribution and get the Qubes PV attached, then "mount <subdir> > > /dev/mapper/qubes_dom0-vm--vmname--private" for example. > > Thin LVs can be imaged like normal volumes, however. I would try > 'vgchange -ay' then 'lvchange -ay' on the drive and then look for the > vm*private volumes in /dev/mapper. > > Once you got that, you can do stuff like this to backup: > > # dd if=/dev/mapper/qubes_dom0-vm--work--private | gzip >work_img.gz > > and this to restore: > > # gunzip -c work_img.gz | dd > of=/dev/mapper/qubes_dom0-vm--work--private conv=sparse > > This example is unencrypted, so take care with the remaining backup details. > > Also keep in mind that thin-provisioned lvm is still pretty young -- it > is NOT 'like' regular non-thin lvm, but more like a new filesystem on > top of regular lvm. If reliability is high on your list then Btrfs may > be better... it seems to be older with a lot more people using it, and > has more internal error-correction mechanisms (but it still isn't > recommended for RAID5/6). Btrfs is worth considering as an alternative. > > -- > > Chris Laprise > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886
Thanks. Is Btrfs an option when installing Qubes 4.0? BTW, Qubes fully recovered. Like last time I messed things up by filling up the LVM, Here are the steps: Insert a bigger drive create PV from new drive added PV to VG LVmove pool00_tdata from full drive to new PV LVextended Pool00 to give room LVextended pool00_tmeta (this was the corrupted part) LVconvert --repair qubes_dom0/pool00 I did try all this yesterday, but the drive I put in, had a previous Qubes 4 install. Even with deleting the partitions, it seemed to still recognize the Volume Group information on it. And since it is also named qubes_dom0... it really messed things up and had me going down rabbit holes with a VG with a MISSING PV. No commands really work when in that stuck state. The issue still remains if anything will be done with Thin Provisioning to prevent this from happening. Last time this happened, there was no disk storage applet. This time, there was, but I just didn't see what a vmdk file was going to be on disk. Should VMs get automatically paused when approaching the limit? Also, should dom0 be inside the thin pool? Or would it make sense to keep it as its own LV? Yeah, it means dom0 cannot grow with the pool, but should 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/aaaa6ee3-cf40-494f-9d33-50757a45c178%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
