• LVM completely gone after trying to install, cnchi gave an error at end of 'install'


    I was trying to install antergos on lvm I setup with it’s own root provisioned. I had my lvm setup with a 256MiB /boot at lvboot, Arch installed to a 20GiB lvarchroot, Empty 20GiB named lvantroot, 2GiB swap lv, and the rest for /home at lvhome. When I got to installing antergos, everything looked fine. The installer saw my lvm setup, I selected the mount points, told it to format lvboot and lvantroot and mount /home to lvhome and use lvswap. Everything looked like it installed fine. Then the installer hit 100% and I got an error that looked similar to:

    Installer failed at: mount [[/dev/mapper/vgfirstdisk-lvantroot]]; None
    

    I could have that a little incorrect, but that’s the gist. I checked and nothing was there. I checked to see if I could see anything in /dev/mapper, but it only has this:

    [[email protected] antergos]# ls -alh /dev/mapper
    total 0
    drwxr-xr-x  2 root root      80 Sep 17 07:23 .
    drwxr-xr-x 18 root root    3.2K Sep 17 07:26 ..
    lrwxrwxrwx  1 root root       7 Sep 17 07:23 arch_root-image -> ../dm-0
    crw-------  1 root root 10, 236 Sep 17 07:23 control
    

    lvdisplay, pvdisplay, and vgdisplay all return nothing, no output. I did find files that ended in .vg and when I looked at them they had a perfect breakdown of the lvm with ids and mount points and everything, then I bumped the flash drive and it disconnected so I had to reboot and those files are lost.
    fdisk -l output:

    [[email protected] antergos]# fdisk -l /dev/sda
    Disk /dev/sda: 149.1 GiB, 160041885696 bytes, 312581808 sectors
    Units: sectors of 1 * 512 = 512 bytes
    Sector size (logical/physical): 512 bytes / 512 bytes
    I/O size (minimum/optimal): 512 bytes / 512 bytes
    Disklabel type: dos
    Disk identifier: 0x0002291d
    Device Boot Start End Sectors Size Id Type /dev/sda1 * 2048 312580095 312578048 149.1G 8e Linux LVM
    

    The antergos installer shows disk as /dev/sda1, type as ? mount point and label and format are all blank, size is 160G, used is 0b.

    I didn’t think to backup before trying to install antergos as arch installed flawlessly a few weeks ago. I can’t just scrap this and call it a loss because I need to get these files back. What can I do to fix this and recover the files that were/are there?
    After googling a bit too I found the command vgscan --mknodes which found nothing.

    #vgscan --mknodes -v
    Wiping cache of LVM-capable devices
    Wiping internal VG cache
    Reading all physical volumes.  This may take a while...
    Using volume group(s) on command line.
    No volume groups found.
    Using logical volume(s) on command line.
    No volume groups found.
    

    Please can anyone help me here?! I’m really hoping this can be fixed. Please and thank you!

  • What does GNOME Disk Utility show when you open it from the Live Environment? Also, check Gparted as well. Post screenshots here.

  • What’s the output of sudo lvmdiskscan, sudo vgscan, and sudo vgchange -ay?

  • [[email protected] antergos]# lvmdiskscan 
      /dev/loop0                  [       1.46 GiB] 
      /dev/mapper/arch_root-image [       5.00 GiB] 
      /dev/loop1                  [       5.00 GiB] 
      /dev/sda1                   [     149.05 GiB] 
      /dev/loop2                  [     256.00 MiB] 
      /dev/sdb1                   [       1.52 GiB] 
      /dev/sdb2                   [      31.00 MiB] 
      1 disk
      6 partitions
      0 LVM physical volume whole disks
      0 LVM physical volumes
    [[email protected] antergos]# vgscan
      Reading all physical volumes.  This may take a while...
    [[email protected] antergos]# vgchange -ay
    [[email protected] antergos]# 
    

    Nada unfortunately.

  • Supplimental info:

    cat /proc/partitions 
    major minor  #blocks  name
    
       7        0    1529848 loop0
       7        1    5242880 loop1
       7        2     262144 loop2
       8        0  156290904 sda
       8        1  156289024 sda1
      11        0    1048575 sr0
       8       16    3956736 sdb
       8       17    1597792 sdb1
       8       18      31744 sdb2
     254        0    5242880 dm-0
    
  • I found I have an old backup of the computer, etc included. It’s a few months old, but the lvm layout hasn’t changed. Is there anything there that might help in recovering this?

  • More info: just discovered pvscan can run with -vvvv for extra verboseness:

    [[email protected] antergos]# pvscan -vvvv
    #lvmcmdline.c:1543         DEGRADED MODE. Incomplete RAID LVs will be processed.
    #libdm-config.c:1013       Setting activation/monitoring to 1
    #lvmcmdline.c:1549         Processing: pvscan -vvvv
    #lvmcmdline.c:1550         system ID: 
    #lvmcmdline.c:1553         O_DIRECT will be used
    #libdm-config.c:949       Setting global/locking_type to 1
    #libdm-config.c:1013       Setting global/wait_for_locks to 1
    #locking/locking.c:128       File-based locking selected.
    #libdm-config.c:1013       Setting global/prioritise_write_locks to 1
    #libdm-config.c:918       Setting global/locking_dir to /run/lock/lvm
    #libdm-config.c:1013       Setting global/use_lvmlockd to 0
    #misc/lvm-flock.c:200       Locking /run/lock/lvm/P_global WB
    #misc/lvm-flock.c:101         _do_flock /run/lock/lvm/P_global:aux WB
    #misc/lvm-flock.c:101         _do_flock /run/lock/lvm/P_global WB
    #misc/lvm-flock.c:48         _undo_flock /run/lock/lvm/P_global:aux
    #filters/filter-persistent.c:51     Wiping cache of LVM-capable devices
    #device/dev-cache.c:338         /dev/sdb: Added to device cache
    #device/dev-cache.c:335         /dev/disk/by-id/usb-PNY_USB_2.0_FD_AAC30FA100001075-0:0: Aliased to /dev/sdb in device cache
    #device/dev-cache.c:338         /dev/disk/by-label/ANTERGOS: Added to device cache
    #device/dev-cache.c:335         /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0: Aliased to /dev/sdb in device cache
    #device/dev-cache.c:335         /dev/disk/by-uuid/2015-08-18-02-36-03-00: Aliased to /dev/disk/by-label/ANTERGOS in device cache
    #device/dev-cache.c:335         /dev/sdb1: Aliased to /dev/disk/by-label/ANTERGOS in device cache (preferred name)
    #device/dev-cache.c:335         /dev/disk/by-id/usb-PNY_USB_2.0_FD_AAC30FA100001075-0:0-part1: Aliased to /dev/sdb1 in device cache
    #device/dev-cache.c:324         /dev/disk/by-label/ANTERGOS: Already in device cache
    #device/dev-cache.c:335         /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part1: Aliased to /dev/sdb1 in device cache
    #device/dev-cache.c:324         /dev/disk/by-uuid/2015-08-18-02-36-03-00: Already in device cache
    #device/dev-cache.c:338         /dev/sdb2: Added to device cache
    #device/dev-cache.c:335         /dev/disk/by-id/usb-PNY_USB_2.0_FD_AAC30FA100001075-0:0-part2: Aliased to /dev/sdb2 in device cache
    #device/dev-cache.c:335         /dev/disk/by-label/ARCHISO_EFI: Aliased to /dev/sdb2 in device cache
    #device/dev-cache.c:335         /dev/disk/by-path/pci-0000:00:1d.7-usb-0:1:1.0-scsi-0:0:0:0-part2: Aliased to /dev/sdb2 in device cache
    #device/dev-cache.c:335         /dev/disk/by-uuid/8A67-86C4: Aliased to /dev/sdb2 in device cache
    #device/dev-cache.c:338         /dev/sr0: Added to device cache
    #device/dev-cache.c:335         /dev/cdrom: Aliased to /dev/sr0 in device cache (preferred name)
    #device/dev-cache.c:335         /dev/disk/by-id/ata-HL-DT-ST_DVDRAM_GSA-4083N_KZ077AM1544: Aliased to /dev/cdrom in device cache
    #device/dev-cache.c:338         /dev/sda: Added to device cache
    #device/dev-cache.c:335         /dev/disk/by-id/ata-ST9160823AS_5NK19HKQ: Aliased to /dev/sda in device cache
    #device/dev-cache.c:338         /dev/sda1: Added to device cache
    #device/dev-cache.c:335         /dev/disk/by-id/ata-ST9160823AS_5NK19HKQ-part1: Aliased to /dev/sda1 in device cache
    #device/dev-cache.c:338         /dev/loop0: Added to device cache
    #device/dev-cache.c:338         /dev/loop1: Added to device cache
    #device/dev-cache.c:335         /dev/disk/by-uuid/6175ac89-c215-4129-b0e9-eeec62bc88dd: Aliased to /dev/loop1 in device cache
    #device/dev-cache.c:338         /dev/loop2: Added to device cache
    #device/dev-cache.c:324         /dev/disk/by-uuid/6175ac89-c215-4129-b0e9-eeec62bc88dd: Already in device cache
    #device/dev-cache.c:338         /dev/loop3: Added to device cache
    #device/dev-cache.c:338         /dev/loop4: Added to device cache
    #device/dev-cache.c:338         /dev/loop5: Added to device cache
    #device/dev-cache.c:338         /dev/loop6: Added to device cache
    #device/dev-cache.c:338         /dev/loop7: Added to device cache
    #device/dev-cache.c:338         /dev/dm-0: Added to device cache
    #device/dev-cache.c:335         /dev/disk/by-id/dm-name-arch_root-image: Aliased to /dev/dm-0 in device cache (preferred name)
    #device/dev-cache.c:324         /dev/disk/by-uuid/6175ac89-c215-4129-b0e9-eeec62bc88dd: Already in device cache
    #device/dev-cache.c:335         /dev/mapper/arch_root-image: Aliased to /dev/disk/by-id/dm-name-arch_root-image in device cache (preferred name)
    #cache/lvmcache.c:1947     Wiping internal VG cache
    #cache/lvmcache.c:497         Metadata cache has no info for vgname: "#orphans_lvm1"
    #cache/lvmcache.c:497         Metadata cache has no info for vgname: "#orphans_lvm1"
    #cache/lvmcache.c:1444         lvmcache: initialised VG #orphans_lvm1
    #cache/lvmcache.c:497         Metadata cache has no info for vgname: "#orphans_pool"
    #cache/lvmcache.c:497         Metadata cache has no info for vgname: "#orphans_pool"
    #cache/lvmcache.c:1444         lvmcache: initialised VG #orphans_pool
    #cache/lvmcache.c:497         Metadata cache has no info for vgname: "#orphans_lvm2"
    #cache/lvmcache.c:497         Metadata cache has no info for vgname: "#orphans_lvm2"
    #cache/lvmcache.c:1444         lvmcache: initialised VG #orphans_lvm2
    #cache/lvmetad.c:776         Asking lvmetad for complete list of known VGs
    #libdm-config.c:918       Setting response to OK
    #libdm-config.c:918       Setting response to OK
    #pvscan.c:386     Walking through all physical volumes
    #cache/lvmetad.c:699         Asking lvmetad for complete list of known PVs
    #libdm-config.c:918       Setting response to OK
    #libdm-config.c:918       Setting response to OK
    #pvscan.c:444   No matching physical volumes found
    #misc/lvm-flock.c:71       Unlocking /run/lock/lvm/P_global
    #misc/lvm-flock.c:48         _undo_flock /run/lock/lvm/P_global
    #lvmcmdline.c:1630         Completed: pvscan -vvvv
    
  • I’m afraid there’s an already solved bug that made that when you tried to install with a previous lvm system, in advanced mode, it unmounted and DELETED all previously created volumes. I do not recall (and I cannot check now) if this fix has reached stable or not, yet. EDIT: 0.12.13 has no longer this bug.

    Will check asap. Thanks for reporting this and I want to apologise if Cnchi deleted your Arch installation.

  • @karasu Thank you for your reply. It deleted more than just arch, but all my personal files.

    The bug you mention, you said specifically in advanced mode. Do you mean when setting up partitions manually?

    And do you know of any recovery methods from this? I’d like to install antergos eventually, but I really need to recover this lvm.

  • The bug you mention, you said specifically in advanced mode. Do you mean when setting up partitions manually?

    Yes, that’s right.

    I did find files that ended in .vg and when I looked at them they had a perfect breakdown of the lvm with ids and mount points and everything

    Those files were lvm metadata!!! Damn it.

    And do you know of any recovery methods from this? I’d like to install antergos eventually, but I really need to recover this lvm.

    You’re probably going to hate me as I doubt it’s going to be an easy task. There’s hope, though, because Cnchi used wipefs to delete your lvm volumes, and if you read wipefs’ manual:

    wipefs can erase filesystem, raid or partition-table signatures (magic strings) from the specified device to make the >signatures invisible for libblkid.
    wipefs does not erase the filesystem itself nor any other data from the device

    Therefore, your data is still there.

    Ok, for start, run this command to check for your LVM data backups (if any):

    pvck -d -v /dev/sda1

    Post the result here, please.

    P.S. If anybody else is reading this thread, this bug has already been fixed in Cnchi 0.12.13

  • Holy damn that’s great news! Let’s hope we can recover something!

    Here’s that output

    [[email protected] antergos]# pvck -d -v /dev/sda1
    Scanning /dev/sda1
    Could not find LVM label on /dev/sda1

  • Hmm…though I am not 100% sure how it handles LVM partitions, testdisk is probably going to be your best bet at recovering your files. There is documentaiton available here:

    http://www.cgsecurity.org/wiki/TestDisk

    There’s also many tutorials on the web for it if you do a quick google search ;-)

    Let us know if you get stuck on anything. Cheers!

  • @lots.0.logs said:

    There’s also many tutorials on the web for it if you do a quick google search

    Yeah that’s the first place I looked was google, and nothing really came up that looked any kind of reliable. BUT… I can try it. I’ll hook up my external and see what is found, I’ll update after scans.

  • Ya’ll really need to work on making your live disc more stable. It’s crashed with kernel panic’s 4 times now. Here’s hoping 5th time’s a charm!

  • @newarcher That’s odd, we havent receive any other reports of kernel panics. Do you remember what the output was referencing? What were you doing at the time it occurred?

  • The first two times it was just sitting there. The third I was looking at something on reddit waiting to have another idea on how to solve this. The fourth it was just sitting there scanning with testdisk. It hadn’t even gotten past 5% and kernel panic when I plugged in/attached my 1TB Western Digital Blue drive via external enclosure. I didn’t even think to take a pic of it. Next time it happens (it’ll happen again I’m sure) I’ll snap a pic of the output.

  • THE SCAN FOUND EVERYTHING! SORT OF!!! I wound up using photorec as testdisk only saw the partition contents as empty bits of things. Photorec found everything as txt files, png/jpg/gif, that sort of thing.

    As I was clicking through the first few files I found my lvm meta data file in segments. If I post the segmented metadata files can someone help me out with putting them back together so I can restore everything properly?

    @lots.0.logs said:

    @newarcher That’s odd, we havent receive any other reports of kernel panics. Do you remember what the output was referencing? What were you doing at the time it occurred?

    Well, it happened again, so here’s the output! The mouse being there kinda throws me off…

    Anyway, so it crashed again, but the files were saved just before that in directories like “recup_dir.1” “recup_dir.2” etc, file names like f0285014.txt or f0285066.sh or .png or .txt etc. Is there anything I can do to restore the proper structure/names/etc?

    Thank you so much for all the help up to this point!

  • Using an existing metadata file on a different computer of mine as reference, I went through the metadata files I found. Of the dozen or so, I was able to put together 3 that look viable. I’m not 100% sure whether these will work, or even really how to use them. They can be seen here: first, second, third. The first was created at the time I installed arch last week it seems, the second was created after I renamed the install destination from lvdebroot to lvantroot, the third for some reason doesn’t have lvantroot at all.

    If anyone can look over those and tell me 1) if they look like they can be used to recover this drive, and 2) what to do with them now. Please and thanks!

    I’m going to run a recursive grep overnight through all the found files to look for more metadata fragments. I’m thinking because they’re used to define the whole disk that they’d only be listed (and thus found) at the beginning of the vg, but I just want to be sure.

  • Grep found nothing. Grep found a decent bit aparently. I’m investigating further.

    For now, all I have are the 3 vg files I put together from the found scraps before. So now I just need some help putting them to use with getting my LVM back up.

cnchi112 installation212 install78 lvm7 Posts 24Views 6167
Log in to reply