Stack Exchange network consists of 183 Q&A communities including Stack Overflow, the largest, most trusted online community for developers to learn, share their knowledge, and build their careers.
Visit Stack Exchange
Stack Internal
Knowledge at work
Bring the best of human thought and AI automation together at your work.
Explore Stack InternalA story fairly similar to this onethis one happened to me yesterday.
I was on a live disk, just about to shrink the /dev/sda2 partition following those stepsthose steps when I abruptly had to stop and unplug my computer. I just had mounted the partition using
A story fairly similar to this one happened to me yesterday.
I was on a live disk, just about to shrink the /dev/sda2 partition following those steps when I abruptly had to stop and unplug my computer. I just had mounted the partition using
A story fairly similar to this one happened to me yesterday.
I was on a live disk, just about to shrink the /dev/sda2 partition following those steps when I abruptly had to stop and unplug my computer. I just had mounted the partition using
/dev/mapper/live-rw [ 4.00 GiB] /dev/sda1 [ 500.00 MiB] /dev/mapper/live-base [ 4.00 GiB] /dev/loop2 [ 886.75 MiB] /dev/sda2 [ 465.27 GiB] /dev/mapper/live-osimg-min [ 4.00 GiB] /dev/mapper/loop3 [ 4.00 GiB] /dev/mapper/fedora_pedro [ 465.27 GiB] LVM physical volume /dev/loop4 [ 512.00 MiB] 3 disks 5 partitions 1 LVM physical volume whole disk 0 LVM physical volume /dev/mapper/live-rw [ 4.00 GiB] /dev/sda1 [ 500.00 MiB] /dev/mapper/live-base [ 4.00 GiB] /dev/loop2 [ 886.75 MiB] /dev/sda2 [ 465.27 GiB] /dev/mapper/live-osimg-min [ 4.00 GiB] /dev/mapper/loop3 [ 4.00 GiB] /dev/mapper/fedora_pedro [ 465.27 GiB] LVM physical volume /dev/loop4 [ 512.00 MiB] /dev/mapper/live-rw [ 4.00 GiB] /dev/sda1 [ 500.00 MiB] /dev/mapper/live-base [ 4.00 GiB] /dev/loop2 [ 886.75 MiB] /dev/sda2 [ 465.27 GiB] /dev/mapper/live-osimg-min [ 4.00 GiB] /dev/mapper/loop3 [ 4.00 GiB] /dev/mapper/fedora_pedro [ 465.27 GiB] LVM physical volume /dev/loop4 [ 512.00 MiB] 3 disks 5 partitions 1 LVM physical volume whole disk 0 LVM physical volume /dev/sda1 is the /boot partition, it is not encrypted. The /dev/sda2 partition was originally a LUKS partition containing the volume group fedora_hostnamefedora_pedro, which itself contained the following logical volumes:
/dev/mapper/fedora_hostnamefedora_pedro-root /dev/mapper/fedora_hostnamefedora_pedro-home /dev/mapper/fedora_hostnamefedora_pedro-swap cryptsetup luksOpen /dev/sda2 ExistingExt4fedora_pedro Using a rescue disk, I opened the drive (cryptsetup luksOpen /dev/sda2 ExistingExt4fedora_pedro) and I inquired the status of the partition using e2fsck, which returned a pretty
testdisk /dev/mapper/ExistingExt4fedora_pedro showed the right volumes (swap, root and home) and allowed access to all data on the system, so I chose to Write partition to the disk, hoping that I could see them after rebooting. That did not happen however, although fdisk -l /dev/mapper/ExistingExt4fedora_pedro now returns
Disk /dev/mapper/ExistingExt4fedora_pedro: 465.3 GiB, 49958403712 bytes, 975742976 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 / 4096 bytes Disklabel type: dos Disk identifier: 0x0000000 Device Boot Start End Blocks Id System /dev/mapper/ExistingExt4p1fedora_pedro1 * 2048 8161279 4079616 82 Linux swap / Solaris /dev/mapper/ExistingExt4p2fedora_pedro2 8161280 870885375 431362048 82 Linux /dev/mapper/ExistingExt4p3fedora_pedro3 870885376 975742975 52428800 82 Linux /dev/sda1: "9f2a5417-dce6-45c1-8d93-1ee753e5c75c" TYPE="ext4" PARTUUID="0006282d-01" /dev/sda2: "a33beb04-1147-446e-8f3b-7ff9d6bc226b" TYPE="crypto_LUKS" PARTUUID="0006282d-02" [...] /dev/mapper/ExistingExt4fedora_pedro: PTTYPE="dos" I think I made a mistake with Write partition to disk in testdisk, as the uuid of my current ExistingExt4fedora_pedro does in no way match with the one of the former deviceoriginal one. In fact, ExistingExt4fedora_pedro has no uuid. Is it possible to attribute to this volume all the specifications of the previous, working unit: uuid, logical partitioning, ... If yes, how?
Getting closer?
vgchange -ay fedora_pedro returns
Volume group "fedora_pedro" not found Skipping volume group fedora_pedro Even though I use the same volume group name as the original one, mentioned in /etc/lvm/backup/ or /etc/lvm/archive. vgdisplay says exactly the same.
What's interesting is the output of lvmdiskscan
/dev/mapper/live-rw [ 4.00 GiB] /dev/sda1 [ 500.00 MiB] /dev/mapper/live-base [ 4.00 GiB] /dev/loop2 [ 886.75 MiB] /dev/sda2 [ 465.27 GiB] /dev/mapper/live-osimg-min [ 4.00 GiB] /dev/mapper/loop3 [ 4.00 GiB] /dev/mapper/fedora_pedro [ 465.27 GiB] LVM physical volume /dev/loop4 [ 512.00 MiB] If I understand it correctly, someone knows that there is a physical volume out there. But it does not want to show it.
$ pvdisplay fedora_pedro Failed to read physical volume "fedora_pedro" $ pvdisplay /dev/mapper/fedora_pedro No physical volume found in lvmetad cache for /dev/mapper/fedora_pedro Failed to read physical volume "/dev/mapper/fedora_pedro" $ pvdisplay /home/liveuser/Documents/etc/lvm/archive/fedora_pedro_00000-1031984471.vg Failed to read physical volume "/home/liveuser/Documents/etc/lvm/archive/fedora_pedro_00000-1031984471.vg" I'm not sure how to go further. I did lvmdump -m and had a look at the dmsetup_ls_tree, dmsetup_table, dmsetup_status and dmsetup_info. dmsetup_info returns the following UUID for fedora_pedro
Name Maj Min Stat Open Targ Event UUID fedora_pedro 253 3 L--w 0 1 0 CRYPT-LUKS1-a33beb04-1147-446e-8f3b-7ff9d6bc226b-fedora_pedro This is the same UUID as the one returned by blkid for /dev/sda2. It is also the same as what I find at line 26 of /home/liveuser/Documents/etc/lvm/archive/fedora_pedro_00000-1031984471.vg
[...] pv0 { id = "cZ83jX-WXkk-tNG4-ulGT-sAqq-HlKq-Omtqc8" device = "/dev/mapper/luks-a33beb04-1147-446e-8f3b-7ff9d6bc226b" # Hint only [...] and in the grub.cfg file on /dev/sda1.
As I wrote in the list above, will try to match the id's and UUID together, but I think the glitch is somewhere else.
/dev/sda1 is the /boot partition, it is not encrypted. The /dev/sda2 partition was originally a LUKS partition containing the volume group fedora_hostname, which itself contained the following logical volumes:
/dev/mapper/fedora_hostname-root /dev/mapper/fedora_hostname-home /dev/mapper/fedora_hostname-swap cryptsetup luksOpen /dev/sda2 ExistingExt4 Using a rescue disk, I opened the drive (cryptsetup luksOpen /dev/sda2 ExistingExt4) and I inquired the status of the partition using e2fsck, which returned a pretty
testdisk /dev/mapper/ExistingExt4 showed the right volumes (swap, root and home) and allowed access to all data on the system, so I chose to Write partition to the disk, hoping that I could see them after rebooting. That did not happen however, although fdisk -l /dev/mapper/ExistingExt4 now returns
Disk /dev/mapper/ExistingExt4: 465.3 GiB, 49958403712 bytes, 975742976 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 / 4096 bytes Disklabel type: dos Disk identifier: 0x0000000 Device Boot Start End Blocks Id System /dev/mapper/ExistingExt4p1 * 2048 8161279 4079616 82 Linux swap / Solaris /dev/mapper/ExistingExt4p2 8161280 870885375 431362048 82 Linux /dev/mapper/ExistingExt4p3 870885376 975742975 52428800 82 Linux /dev/sda1: "9f2a5417-dce6-45c1-8d93-1ee753e5c75c" TYPE="ext4" PARTUUID="0006282d-01" /dev/sda2: "a33beb04-1147-446e-8f3b-7ff9d6bc226b" TYPE="crypto_LUKS" PARTUUID="0006282d-02" [...] /dev/mapper/ExistingExt4: PTTYPE="dos" I think I made a mistake with Write partition to disk in testdisk, as the uuid of my current ExistingExt4 does in no way match with the one of the former device. In fact, ExistingExt4 has no uuid. Is it possible to attribute to this volume all the specifications of the previous, working unit: uuid, logical partitioning, ... If yes, how?
/dev/sda1 is the /boot partition, it is not encrypted. The /dev/sda2 partition was originally a LUKS partition containing the volume group fedora_pedro, which itself contained the following logical volumes:
/dev/mapper/fedora_pedro-root /dev/mapper/fedora_pedro-home /dev/mapper/fedora_pedro-swap cryptsetup luksOpen /dev/sda2 fedora_pedro Using a rescue disk, I opened the drive (cryptsetup luksOpen /dev/sda2 fedora_pedro) and I inquired the status of the partition using e2fsck, which returned a pretty
testdisk /dev/mapper/fedora_pedro showed the right volumes (swap, root and home) and allowed access to all data on the system, so I chose to Write partition to the disk, hoping that I could see them after rebooting. That did not happen however, although fdisk -l /dev/mapper/fedora_pedro now returns
Disk /dev/mapper/fedora_pedro: 465.3 GiB, 49958403712 bytes, 975742976 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 / 4096 bytes Disklabel type: dos Disk identifier: 0x0000000 Device Boot Start End Blocks Id System /dev/mapper/fedora_pedro1 * 2048 8161279 4079616 82 Linux swap / Solaris /dev/mapper/fedora_pedro2 8161280 870885375 431362048 82 Linux /dev/mapper/fedora_pedro3 870885376 975742975 52428800 82 Linux /dev/sda1: "9f2a5417-dce6-45c1-8d93-1ee753e5c75c" TYPE="ext4" PARTUUID="0006282d-01" /dev/sda2: "a33beb04-1147-446e-8f3b-7ff9d6bc226b" TYPE="crypto_LUKS" PARTUUID="0006282d-02" [...] /dev/mapper/fedora_pedro: PTTYPE="dos" I think I made a mistake with Write partition to disk in testdisk, as the uuid of my current fedora_pedro does in no way match with the one of the original one. In fact, fedora_pedro has no uuid. Is it possible to attribute to this volume all the specifications of the previous, working unit: uuid, logical partitioning, ... If yes, how?
Getting closer?
vgchange -ay fedora_pedro returns
Volume group "fedora_pedro" not found Skipping volume group fedora_pedro Even though I use the same volume group name as the original one, mentioned in /etc/lvm/backup/ or /etc/lvm/archive. vgdisplay says exactly the same.
What's interesting is the output of lvmdiskscan
/dev/mapper/live-rw [ 4.00 GiB] /dev/sda1 [ 500.00 MiB] /dev/mapper/live-base [ 4.00 GiB] /dev/loop2 [ 886.75 MiB] /dev/sda2 [ 465.27 GiB] /dev/mapper/live-osimg-min [ 4.00 GiB] /dev/mapper/loop3 [ 4.00 GiB] /dev/mapper/fedora_pedro [ 465.27 GiB] LVM physical volume /dev/loop4 [ 512.00 MiB] If I understand it correctly, someone knows that there is a physical volume out there. But it does not want to show it.
$ pvdisplay fedora_pedro Failed to read physical volume "fedora_pedro" $ pvdisplay /dev/mapper/fedora_pedro No physical volume found in lvmetad cache for /dev/mapper/fedora_pedro Failed to read physical volume "/dev/mapper/fedora_pedro" $ pvdisplay /home/liveuser/Documents/etc/lvm/archive/fedora_pedro_00000-1031984471.vg Failed to read physical volume "/home/liveuser/Documents/etc/lvm/archive/fedora_pedro_00000-1031984471.vg" I'm not sure how to go further. I did lvmdump -m and had a look at the dmsetup_ls_tree, dmsetup_table, dmsetup_status and dmsetup_info. dmsetup_info returns the following UUID for fedora_pedro
Name Maj Min Stat Open Targ Event UUID fedora_pedro 253 3 L--w 0 1 0 CRYPT-LUKS1-a33beb04-1147-446e-8f3b-7ff9d6bc226b-fedora_pedro This is the same UUID as the one returned by blkid for /dev/sda2. It is also the same as what I find at line 26 of /home/liveuser/Documents/etc/lvm/archive/fedora_pedro_00000-1031984471.vg
[...] pv0 { id = "cZ83jX-WXkk-tNG4-ulGT-sAqq-HlKq-Omtqc8" device = "/dev/mapper/luks-a33beb04-1147-446e-8f3b-7ff9d6bc226b" # Hint only [...] and in the grub.cfg file on /dev/sda1.
As I wrote in the list above, will try to match the id's and UUID together, but I think the glitch is somewhere else.
