Mount cached lvm2 volume from rescue system
up vote
0
down vote
favorite
I have the following setup:
root@system:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 30G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 977M 0 part
│ └─md0 9:0 0 976,4M 0 raid1 /boot
└─sda3 8:3 0 29G 0 part
└─md1 9:1 0 29G 0 raid1
└─vg00-root_corig 253:3 0 29G 0 lvm
└─vg00-root 253:0 0 29G 0 lvm /
sdb 8:16 0 8G 0 disk
├─vg00-cache_cdata 253:1 0 8G 0 lvm
│ └─vg00-root 253:0 0 29G 0 lvm /
└─vg00-cache_cmeta 253:2 0 32M 0 lvm
└─vg00-root 253:0 0 29G 0 lvm /
sr0 11:0 1 1024M 0 rom
root@system:~# lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
[cache] vg00 Cwi---C--- 7,93g 0,51 3,22 0,00
[cache_cdata] vg00 Cwi-ao---- 7,93g
[cache_cmeta] vg00 ewi-ao---- 32,00m
[lvol0_pmspare] vg00 ewi------- 32,00m
root vg00 Cwi-aoC--- 29,02g [cache] [root_corig] 0,51 3,22 0,00
[root_corig] vg00 owi-aoC--- 29,02g
As you can see I have a volume group vg00 that spans across 2 physical devices sda(sda3) and sdb. The lv root is placed on a raid1 md1. This raid device only has one disk. This doesn't make much sense for production use. Please ignore that for the moment. It does in other setups and is not relevant here.
The lv root is using a writethrough cache using dm-cache.
My problem: E.g. in case the system doesn't boot for whatever reason I need to be able to mount my lv root which contains the root fs to recover files or fix a broken installation. To do that I boot into a rescue evoirment and assemble the raid1:
root@rescue:/# mdadm --assemble md1 /dev/sda3
mdadm: /dev/md/md1 has been started with 1 drive.
However I cannot activate the lv root:
root@rescue:/# lvchange -a y vg00/root
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
/dev/mapper/vg00-cache_cmeta: open failed: No such file or directory
vgchange -a y vg00 produces the same result.
When trying often enough the required lvs cache_cmeta and cache_cdata sometimes become active (lvs -a). When that's the case I can create the device mapper files using vgmknodes and run lvchange -a y vg00/root or vgchange -a y to activate root and mount the device as usual. However this is not reliable.
I cannot activate the cache lvs manually:
root@rescue:/# lvchange -a y vg00/cache_cmeta
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Unable to change internal LV vg00/cache_cmeta directly.
Question: What is the correct way to activate a cached lv?
I can uncache the lv using lvconcert --uncache vg00/root which works reliably, however I'm looking for a reliable way to mount the root lv without uncaching it first.
linux debian lvm2
asked Nov 19 at 12:45
K.A.B.
11
add a comment |
up vote
0
down vote
favorite
I have the following setup:
root@system:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 30G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 977M 0 part
│ └─md0 9:0 0 976,4M 0 raid1 /boot
└─sda3 8:3 0 29G 0 part
└─md1 9:1 0 29G 0 raid1
└─vg00-root_corig 253:3 0 29G 0 lvm
└─vg00-root 253:0 0 29G 0 lvm /
sdb 8:16 0 8G 0 disk
├─vg00-cache_cdata 253:1 0 8G 0 lvm
│ └─vg00-root 253:0 0 29G 0 lvm /
└─vg00-cache_cmeta 253:2 0 32M 0 lvm
└─vg00-root 253:0 0 29G 0 lvm /
sr0 11:0 1 1024M 0 rom
root@system:~# lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
[cache] vg00 Cwi---C--- 7,93g 0,51 3,22 0,00
[cache_cdata] vg00 Cwi-ao---- 7,93g
[cache_cmeta] vg00 ewi-ao---- 32,00m
[lvol0_pmspare] vg00 ewi------- 32,00m
root vg00 Cwi-aoC--- 29,02g [cache] [root_corig] 0,51 3,22 0,00
[root_corig] vg00 owi-aoC--- 29,02g
As you can see I have a volume group vg00 that spans across 2 physical devices sda(sda3) and sdb. The lv root is placed on a raid1 md1. This raid device only has one disk. This doesn't make much sense for production use. Please ignore that for the moment. It does in other setups and is not relevant here.
The lv root is using a writethrough cache using dm-cache.
My problem: E.g. in case the system doesn't boot for whatever reason I need to be able to mount my lv root which contains the root fs to recover files or fix a broken installation. To do that I boot into a rescue evoirment and assemble the raid1:
root@rescue:/# mdadm --assemble md1 /dev/sda3
mdadm: /dev/md/md1 has been started with 1 drive.
However I cannot activate the lv root:
root@rescue:/# lvchange -a y vg00/root
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
/dev/mapper/vg00-cache_cmeta: open failed: No such file or directory
vgchange -a y vg00 produces the same result.
When trying often enough the required lvs cache_cmeta and cache_cdata sometimes become active (lvs -a). When that's the case I can create the device mapper files using vgmknodes and run lvchange -a y vg00/root or vgchange -a y to activate root and mount the device as usual. However this is not reliable.
I cannot activate the cache lvs manually:
root@rescue:/# lvchange -a y vg00/cache_cmeta
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Unable to change internal LV vg00/cache_cmeta directly.
Question: What is the correct way to activate a cached lv?
I can uncache the lv using lvconcert --uncache vg00/root which works reliably, however I'm looking for a reliable way to mount the root lv without uncaching it first.
linux debian lvm2
asked Nov 19 at 12:45
K.A.B.
11
From this (and similar data I was able to find by searching), it follows that you should either startlvmedad, which is a daemon, before trying to carry other LVM operations, or disable it in the LVM config and update initramfs: some LVM management operations will become slower but they won't depend on that daemon being active.
– kostix
Nov 19 at 14:58
lvmetad is not available in rescue. It should not influence operation. I can try disabling it via config anyway and see what happens, but I doubt it'll make a difference. I can't update my initramfs without access to my rootfs.
– K.A.B.
Nov 20 at 15:44
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have the following setup:
root@system:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 30G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 977M 0 part
│ └─md0 9:0 0 976,4M 0 raid1 /boot
└─sda3 8:3 0 29G 0 part
└─md1 9:1 0 29G 0 raid1
└─vg00-root_corig 253:3 0 29G 0 lvm
└─vg00-root 253:0 0 29G 0 lvm /
sdb 8:16 0 8G 0 disk
├─vg00-cache_cdata 253:1 0 8G 0 lvm
│ └─vg00-root 253:0 0 29G 0 lvm /
└─vg00-cache_cmeta 253:2 0 32M 0 lvm
└─vg00-root 253:0 0 29G 0 lvm /
sr0 11:0 1 1024M 0 rom
root@system:~# lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
[cache] vg00 Cwi---C--- 7,93g 0,51 3,22 0,00
[cache_cdata] vg00 Cwi-ao---- 7,93g
[cache_cmeta] vg00 ewi-ao---- 32,00m
[lvol0_pmspare] vg00 ewi------- 32,00m
root vg00 Cwi-aoC--- 29,02g [cache] [root_corig] 0,51 3,22 0,00
[root_corig] vg00 owi-aoC--- 29,02g
As you can see I have a volume group vg00 that spans across 2 physical devices sda(sda3) and sdb. The lv root is placed on a raid1 md1. This raid device only has one disk. This doesn't make much sense for production use. Please ignore that for the moment. It does in other setups and is not relevant here.
The lv root is using a writethrough cache using dm-cache.
My problem: E.g. in case the system doesn't boot for whatever reason I need to be able to mount my lv root which contains the root fs to recover files or fix a broken installation. To do that I boot into a rescue evoirment and assemble the raid1:
root@rescue:/# mdadm --assemble md1 /dev/sda3
mdadm: /dev/md/md1 has been started with 1 drive.
However I cannot activate the lv root:
root@rescue:/# lvchange -a y vg00/root
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
/dev/mapper/vg00-cache_cmeta: open failed: No such file or directory
vgchange -a y vg00 produces the same result.
When trying often enough the required lvs cache_cmeta and cache_cdata sometimes become active (lvs -a). When that's the case I can create the device mapper files using vgmknodes and run lvchange -a y vg00/root or vgchange -a y to activate root and mount the device as usual. However this is not reliable.
I cannot activate the cache lvs manually:
root@rescue:/# lvchange -a y vg00/cache_cmeta
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Unable to change internal LV vg00/cache_cmeta directly.
Question: What is the correct way to activate a cached lv?
I can uncache the lv using lvconcert --uncache vg00/root which works reliably, however I'm looking for a reliable way to mount the root lv without uncaching it first.
linux debian lvm2
asked Nov 19 at 12:45
K.A.B.
11
I have the following setup:
root@system:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 30G 0 disk
├─sda1 8:1 0 1M 0 part
├─sda2 8:2 0 977M 0 part
│ └─md0 9:0 0 976,4M 0 raid1 /boot
└─sda3 8:3 0 29G 0 part
└─md1 9:1 0 29G 0 raid1
└─vg00-root_corig 253:3 0 29G 0 lvm
└─vg00-root 253:0 0 29G 0 lvm /
sdb 8:16 0 8G 0 disk
├─vg00-cache_cdata 253:1 0 8G 0 lvm
│ └─vg00-root 253:0 0 29G 0 lvm /
└─vg00-cache_cmeta 253:2 0 32M 0 lvm
└─vg00-root 253:0 0 29G 0 lvm /
sr0 11:0 1 1024M 0 rom
root@system:~# lvs -a
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
[cache] vg00 Cwi---C--- 7,93g 0,51 3,22 0,00
[cache_cdata] vg00 Cwi-ao---- 7,93g
[cache_cmeta] vg00 ewi-ao---- 32,00m
[lvol0_pmspare] vg00 ewi------- 32,00m
root vg00 Cwi-aoC--- 29,02g [cache] [root_corig] 0,51 3,22 0,00
[root_corig] vg00 owi-aoC--- 29,02g
As you can see I have a volume group vg00 that spans across 2 physical devices sda(sda3) and sdb. The lv root is placed on a raid1 md1. This raid device only has one disk. This doesn't make much sense for production use. Please ignore that for the moment. It does in other setups and is not relevant here.
The lv root is using a writethrough cache using dm-cache.
My problem: E.g. in case the system doesn't boot for whatever reason I need to be able to mount my lv root which contains the root fs to recover files or fix a broken installation. To do that I boot into a rescue evoirment and assemble the raid1:
root@rescue:/# mdadm --assemble md1 /dev/sda3
mdadm: /dev/md/md1 has been started with 1 drive.
However I cannot activate the lv root:
root@rescue:/# lvchange -a y vg00/root
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
/dev/mapper/vg00-cache_cmeta: open failed: No such file or directory
vgchange -a y vg00 produces the same result.
When trying often enough the required lvs cache_cmeta and cache_cdata sometimes become active (lvs -a). When that's the case I can create the device mapper files using vgmknodes and run lvchange -a y vg00/root or vgchange -a y to activate root and mount the device as usual. However this is not reliable.
I cannot activate the cache lvs manually:
root@rescue:/# lvchange -a y vg00/cache_cmeta
WARNING: Failed to connect to lvmetad. Falling back to device scanning.
Unable to change internal LV vg00/cache_cmeta directly.
Question: What is the correct way to activate a cached lv?
I can uncache the lv using lvconcert --uncache vg00/root which works reliably, however I'm looking for a reliable way to mount the root lv without uncaching it first.
linux debian lvm2
linux debian lvm2
asked Nov 19 at 12:45
K.A.B.
11
asked Nov 19 at 12:45
K.A.B.
11
edited Nov 19 at 12:51
asked Nov 19 at 12:45
K.A.B.
11
asked Nov 19 at 12:45
K.A.B.
11
asked Nov 19 at 12:45
K.A.B.
11
11
From this (and similar data I was able to find by searching), it follows that you should either startlvmedad, which is a daemon, before trying to carry other LVM operations, or disable it in the LVM config and update initramfs: some LVM management operations will become slower but they won't depend on that daemon being active.
– kostix
Nov 19 at 14:58
lvmetad is not available in rescue. It should not influence operation. I can try disabling it via config anyway and see what happens, but I doubt it'll make a difference. I can't update my initramfs without access to my rootfs.
– K.A.B.
Nov 20 at 15:44
add a comment |
From this (and similar data I was able to find by searching), it follows that you should either startlvmedad, which is a daemon, before trying to carry other LVM operations, or disable it in the LVM config and update initramfs: some LVM management operations will become slower but they won't depend on that daemon being active.
– kostix
Nov 19 at 14:58
lvmetad is not available in rescue. It should not influence operation. I can try disabling it via config anyway and see what happens, but I doubt it'll make a difference. I can't update my initramfs without access to my rootfs.
– K.A.B.
Nov 20 at 15:44
From this (and similar data I was able to find by searching), it follows that you should either start
lvmedad, which is a daemon, before trying to carry other LVM operations, or disable it in the LVM config and update initramfs: some LVM management operations will become slower but they won't depend on that daemon being active.– kostix
Nov 19 at 14:58
From this (and similar data I was able to find by searching), it follows that you should either start
lvmedad, which is a daemon, before trying to carry other LVM operations, or disable it in the LVM config and update initramfs: some LVM management operations will become slower but they won't depend on that daemon being active.– kostix
Nov 19 at 14:58
lvmetad is not available in rescue. It should not influence operation. I can try disabling it via config anyway and see what happens, but I doubt it'll make a difference. I can't update my initramfs without access to my rootfs.
– K.A.B.
Nov 20 at 15:44
lvmetad is not available in rescue. It should not influence operation. I can try disabling it via config anyway and see what happens, but I doubt it'll make a difference. I can't update my initramfs without access to my rootfs.
– K.A.B.
Nov 20 at 15:44
add a comment |
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1376692%2fmount-cached-lvm2-volume-from-rescue-system%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
From this (and similar data I was able to find by searching), it follows that you should either start
lvmedad, which is a daemon, before trying to carry other LVM operations, or disable it in the LVM config and update initramfs: some LVM management operations will become slower but they won't depend on that daemon being active.– kostix
Nov 19 at 14:58
lvmetad is not available in rescue. It should not influence operation. I can try disabling it via config anyway and see what happens, but I doubt it'll make a difference. I can't update my initramfs without access to my rootfs.
– K.A.B.
Nov 20 at 15:44