Khối lượng logic không hoạt động tại thời điểm khởi động

Tôi thay đổi kích thước khối lượng logic và hệ thống tập tin của mình và tất cả đều diễn ra suôn sẻ. Tôi đã cài đặt kernel mới và sau khi khởi động lại, tôi không thể khởi động cả hiện tại lẫn trước đây. Tôi nhận được lỗi khối lượng nhóm không tìm thấy sau khi chọn tùy chọn grub (2). Kiểm tra từ hộp bận cho thấy các khối lượng không được đăng ký với trình ánh xạ thiết bị và chúng không hoạt động. Tôi không thể gắn kết chúng sau khi kích hoạt, tôi gặp lỗi không tìm thấy tệp (mount / dev / mapper / all-root / mnt).

Bất kỳ ý tưởng làm thế nào để tiến hành hoặc làm cho chúng hoạt động tại thời điểm khởi động? Hoặc tại sao tất cả các khối lượng không hoạt động đột ngột tại thời điểm khởi động?

Trân trọng,

Marek

EDIT: Điều tra thêm cho thấy rằng điều này không liên quan gì đến việc thay đổi kích thước khối lượng logic. Thực tế là khối lượng logic phải được kích hoạt bằng tay trong vỏ tro sau khi khởi động thất bại và giải pháp khả thi cho vấn đề này được đề cập trong phần trả lời của tôi dưới đây.

Vì vậy, tôi đã xoay sở để giải quyết điều này cuối cùng. Có một vấn đề (lỗi) với việc phát hiện khối lượng logic, đó là một số điều kiện chủng tộc (có thể trong trường hợp của tôi liên quan đến thực tế rằng điều này xảy ra bên trong KVM). Điều này được đề cập trong các cuộc thảo luận sau đây . Trong trường hợp cụ thể của tôi (Debian Squeeze), giải pháp như sau:

• sao lưu tập lệnh / usr / share / initramfs-tools / scripts / local-top / lvm2
• áp dụng bản vá từ báo cáo lỗi được đề cập
• chạy update-initramfs -u

Điều này đã giúp tôi, hy vọng nó sẽ giúp người khác (kỳ lạ thay, đây chưa phải là một phần của dòng chính).

Liên kết đến bản vá: _http: //bugs.debian.org/cgi-bin/orpreport.cgi?

Dưới đây là một bản sao cho hậu thế.

--- /usr/share/initramfs-tools/scripts/local-top/lvm2 2009-08-17 19:28:09.000000000 +0200
+++ /usr/share/initramfs-tools/scripts/local-top/lvm2 2010-02-19 23:22:14.000000000 +0100
@@ -45,12 +45,30 @@

  eval $(dmsetup splitname --nameprefixes --noheadings --rows "$dev")

- if [ "$DM_VG_NAME" ] && [ "$DM_LV_NAME" ]; then
-   lvm lvchange -aly --ignorelockingfailure "$DM_VG_NAME/$DM_LV_NAME"
-   rc=$?
-   if [ $rc = 5 ]; then
-     echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
-   fi
+ # Make sure that we have non-empty volume group and logical volume
+ if [ -z "$DM_VG_NAME" ] || [ -z "$DM_LV_NAME" ]; then
+   return 1
+ fi
+
+ # If the logical volume hasn't shown up yet, give it a little while
+ # to deal with LVM on removable devices (inspired from scripts/local)
+ fulldev="/dev/$DM_VG_NAME/$DM_LV_NAME"
+ if [ -z "`lvm lvscan -a --ignorelockingfailure |grep $fulldev`" ]; then
+   # Use default root delay
+   slumber=$(( ${ROOTDELAY:-180} * 10 ))
+
+   while [ -z "`lvm lvscan -a --ignorelockingfailure |grep $fulldev`" ]; do
+     /bin/sleep 0.1
+     slumber=$(( ${slumber} - 1 ))
+     [ ${slumber} -gt 0 ] || break
+   done
+ fi
+
+ # Activate logical volume
+ lvm lvchange -aly --ignorelockingfailure "$DM_VG_NAME/$DM_LV_NAME"
+ rc=$?
+ if [ $rc = 5 ]; then
+   echo "Unable to find LVM volume $DM_VG_NAME/$DM_LV_NAME"
  fi
 }

Tạo một kịch bản khởi động trong việc /etc/init.d/lvmchứa các mục sau:

#!/bin/sh

case "$1" in
 start)
    /sbin/vgscan
    /sbin/vgchange -ay
    ;;
  stop)
    /sbin/vgchange -an
    ;;
  restart|force-reload)
    ;;
esac

exit 0

Sau đó thực hiện các lệnh:

chmod 0755 /etc/init.d/lvm
update-rc.d lvm start 26 S . stop 82 1 .

Nên thực hiện thủ thuật cho các hệ thống Debian.

Tôi cũng có vấn đề này. Cuối cùng, đây là những gì dường như để khắc phục nó:

diff -u /usr/share/initramfs-tools/scripts/local-top/lvm2-backup /usr/share/initramfs-tools/scripts/local-top/lvm2
--- /usr/share/initramfs-tools/scripts/local-top/lvm2-backup    2014-06-06 19:55:19.249857946 -0400
+++ /usr/share/initramfs-tools/scripts/local-top/lvm2   2014-06-21 01:26:01.015289945 -0400
@@ -60,6 +60,7 @@

 modprobe -q dm-mod

+lvm vgchange -ay
 activate_vg "$ROOT"
 activate_vg "$resume"

Những thứ khác tôi đã thử:

1. bản vá của bạn
2. khác biệt /etc/lvm/lvm.conf
3. GRUB_PRELOAD_MODULES="lvm"
4. GRUB_CMDLINE_LINUX="scsi_mod.scan=sync"
5. sudo grub-install /dev/sda && sudo grub-install /dev/sdb && sudo update-grub && sudo update-initramfs -u -k all
6. sudo apt-get install --reinstall lvm2 grub-pc grub-common

Tôi đã trải qua và tháo gỡ những thay đổi khác, đây là điều duy nhất quan trọng với tôi, mặc dù nó có lẽ là ít thanh lịch nhất.

Nếu vgscan"tìm thấy" âm lượng, bạn sẽ có thể kích hoạt chúng vớivgchange -ay /dev/volumegroupname

$ sudo vgscan
[sudo] password for username: 
  Reading all physical volumes.  This may take a while...
  Found volume group "vg02" using metadata type lvm2
  Found volume group "vg00" using metadata type lvm2

$ sudo vgchange -ay /dev/vg02
  7 logical volume(s) in volume group "vg00" now active

Tôi không chắc điều gì sẽ khiến chúng không hoạt động sau khi khởi động lại.

Nếu không có bất kỳ chi tiết cấu hình hoặc thông báo lỗi nào chúng tôi cần đưa ra câu trả lời thực tế, tôi sẽ thực hiện một cú đâm trong bóng tối grub-mkdevicemapnhư một giải pháp.

Giả sử hệ thống của bạn sử dụng initramfs, có thể có vấn đề về cấu hình ở đó. Bạn nên cập nhật hình ảnh initramfs của mình bắt đầu vào lúc khởi động bằng grub (trong Debian bạn làm điều này với update-initramfs, không biết về các bản phát hành khác).

Bạn cũng có thể làm điều này bằng tay bằng cách giải nén initramfs và thay đổi /etc/lvm/lvm.conf (hoặc một cái gì đó tương tự) trong hình ảnh initramfs của bạn và sau đó đóng gói lại.

Tôi đã gặp vấn đề tương tự trong môi trường của mình khi chạy Red Hat 7.4 với tư cách là khách KVM. Tôi đang chạy qemu-kvm-1.5.3-141 và virt-manager 1.4.1. Lúc đầu, tôi đang chạy Red Hat 7.2 với tư cách là khách mà không gặp vấn đề gì, nhưng sau khi nâng cấp bản phát hành nhỏ từ 7.2 lên 7.4 và kernel lên phiên bản mới nhất 3.10.0-693.5.2, đã xảy ra sự cố và không thể khởi động phân vùng LV / var LV của tôi hơn. Hệ thống chuyển sang chế độ khẩn cấp yêu cầu mật khẩu root. Nhập mật khẩu gốc và chạy các lệnh lvm vgchange -ayvà systemctl defaulttôi đã có thể kích hoạt /varLV của mình và khởi động hệ thống.

Tôi chưa tìm ra nguyên nhân gây ra vấn đề này, nhưng cách giải quyết của tôi là đưa LV /varvào /etc/default/grubnhư bạn thấy dưới đây:

GRUB_CMDLINE_LINUX="crashkernel=auto rd.lvm.lv=vg_local/root rd.lvm.lv=vg_local/var rd.lvm.lv=vg_local/swap rhgb quiet biosdevname=0 net.ifnames=0 ipv6.disable=1"

Sau đó, tôi phải chạy grub2-mkconfig -o /boot/grub2/grub.cfgvà kiểm tra xem có rd.lvm.lv=vg_local/varđược bao gồm trong dòng vmlinuz không /boot/grub2/grub.cfg. Sau khi khởi động lại hệ thống, tôi không gặp phải lỗi khi kích hoạt /varLV nữa và hệ thống hoàn tất quá trình khởi động thành công.

tìm ra trong trường hợp của tôi rằng gốc rễ grub là root = / dev / vgname / root

vì vậy, kiểm tra trong / usr / share / initramfs-tools / scripts / local-top / lvm2

  # Make sure that we have a d-m path
  dev="${dev#/dev/mapper/}"          
  if [ "$dev" = "$1" ]; then         
    return 1                         
  fi      

luôn luôn sai và khối lượng gốc không bao giờ kích hoạt.

đã cập nhật / etc / fstab từ

/dev/vgname/root        /

đến

/dev/mapper/vgname-root   /

và đã làm:

update-grub
grub-install /dev/sda

giải quyết vấn đề của tôi

chúng tôi chạy vào vấn đề này và phát hiện ra rằng việc vô hiệu hóa lvmetadbằng cách thiết lập use_lvmetad=0trong /etc/lvm/lvm.confbuộc khối lượng được tìm thấy và mae truy cập lúc khởi động.