☰

재부팅하지 않고 systemd에서 /var /usr을 안전하게 마운트 해제하는 방법

tag-icon • tag-icon mount systemd rsync reboot kexec
재부팅하지 않고 systemd에서 /var /usr을 안전하게 마운트 해제하는 방법

가상 머신에 Linux 서버가 있는데 타사 공급자의 구성 오류로 인해 재부팅이 전원 끄기처럼 작동합니다. 가상 머신 구성에 액세스할 수 없습니다.

시스템을 설치한 사람이 누구든 저장 공간을 엉망으로 만들고 무책임하게 각 디렉토리( /var, /home, /usr등...)에 지점을 설치하여 일부 디렉토리에는 쉽게 배고프고 다른 디렉토리에는 비어 있게 만들었습니다.

이 혼란을 해결하기 위해 마운트 지점을 재구성하고 있으며 다음을 수행 한 다음 나중에 이를 사용하는 프로세스를 다시 시작하여 mount --bind / /mnt대부분을 관리 할 수 있었습니다 .rsyncumount

문제는 systemd init 프로세스 자체가 /var. /usr그것이 systemd-remount-fs효과가 있을까요? 어떻게 해야 합니까? fstab간단한 편집만으로 rsync충분합니까? 모든 서비스가 다시 시작되나요?

제 경우에는 어떤 지점에 별도의 파티션이 필요한지 알고 있지만 그렇지 /var않습니다 /usr.

전제는 파티션을 다시 마운트한 후 파티션을 파괴해야 하기 때문에 사용할 수 없다는 것이고 , 잘못 구성된 이 VM에 동일한 버그 효과가 있을지 모르기 때문에 다시 부팅할 수 없는 것을 umount -l방지하고 싶습니다 .kexec

나는 압축된 파티션을 만들 계획이며 btrfs거의 정적인 상태가 된 후에는 필요한 공간을 최소화하면서 다른 모든 파티션을 함께 모을 계획입니다. 앞으로는 구성 오류를 쉽게 감지할 수 있도록 루트 및 마운트와 함께 배치할 수도 있습니다. 재부팅하지 않고도 이 모든 작업을 수행할 수 있기를 바라지만, 그럴 수 있을지는 모르겠습니다./var/logbtrfsxfs/var/lib/dockersquashfsoverlayfs

답변1

경고하다:이러한 작업은 매우 위험하므로 모든 단계를 이해하고 수행하는 것이 좋습니다. 이를 수행하지 않을 경우 시스템이 파손될 수 있습니다. 그것의 사용에서.

동일한 작업을 수행할 수 있는지 확실하지 않은 경우 원래 서버에 영향을 주지 않고 이러한 명령을 시도하기 위해 모든 서버 디스크를 내 워크스테이션의 로컬 가상 머신에 복제했습니다. 광범위한 연구와 많은 실험 끝에 마침내 해결책을 찾았습니다.

일부 시스템에서는initrd에서 시스템화됨, 대상 루트를 마운트한 후 chroot를 사용하는 것처럼 systemd 환경을 전환하고 모든 서비스를 종료한 다음 새 환경에서 다시 시작합니다.

이 기능을 활용하여 루트 디렉터리를 다시 변경할 수 있습니다. 다른 디스크의 복제된 환경에서 이 작업을 수행하면 이전 환경에 있던 시스템 잠금이 해제되므로 안전하게 포인트를 마운트 해제할 수 있습니다. 실제로는 거의 절대 해제되지 않습니다. 전혀 마운트하지 마십시오. 그러나 복제 환경은 네트워크를 다시 가동하고 SSH 액세스를 제공하도록 적절하게 구성되어야 합니다. 그렇지 않다면 자신이 운명에 처해 있다고 생각하십시오.

중요한 점은 별도의 파티션이 있다는 것입니다. 일단 장치 자체가 아닌 다른 파티션 내의 디렉터리로 chroot하면 시스템은 여전히 ​​상위 파티션의 장치를 저장할 수 있습니다. 이 사용 사례에서는 그 목적을 고려해야 하며 그렇지 않을 것입니다. 무엇이든 차단하세요.

할당되지 않은 여유 공간이 있거나 복제 환경을 위한 공간을 확보하기 위해 일부 파티션을 축소할 수 있는 경우에 권장됩니다. 그러나 사용 가능한 저장 공간이 없고 메모리가 충분한 경우 가상 메모리 탑재 지점을 생성할 수 있습니다. 이 프로세스 중에 연결이 끊어질 수 있으므로 네트워크 파티셔닝은 권장되지 않습니다.

가상 메모리 마운트 지점은 다음으로 수행할 수 있지만 tmpfs이전 환경에서 이 메모리를 잠그게 되므로 또는 없이는 메모리를 해제할 수 없습니다 reboot. kexec더 좋은 방법은 다음을 사용하는 것입니다.zram, 저장 장치를 만드는 것 외에도 데이터를 압축하기 때문에 5G데이터를 쓰면 실제로는 그보다 훨씬 적은 메모리를 사용하지만 여전히 충분한 메모리가 필요합니다.

예를 들어, 7G충분하다면 다음과 같이 생성할 수 있습니다.

sudo modprobe zram num_devices=4
echo 7G | sudo tee /sys/block/zram0/disksize
sudo mkfs.ext4 -m0 /dev/zram0

복제 환경에 필요한 파티션을 구성하면 작동 방식은 다음과 같습니다.

mkdir /tmp/sys
sudo mount /dev/zram0 /tmp/sys # or the target device in place of zram0
# mount other separate partitions if required
sudo tar -cpSf - \
    --acls --xattrs --selinux \
    --exclude '/dev/*' \
    --exclude '/run/*' \
    --exclude '/sys/*' \
    --exclude '/proc/*' \
    --exclude '/tmp/*' \
    --exclude '/var/tmp/*' \
    --exclude '/var/run/*' \
    / |
    sudo tar -xvf - \
        --acls --xattrs --selinux \
        -C /tmp/sys

fstab다음을 백업하는 것이 좋습니다 .

sudo cp -a /tmp/sys/etc/fstab /tmp/sys/etc/fstab-
sudo truncate -s0 /tmp/sys/etc/fstab

일부 장치의 파티션을 메모리로 변경하려는 경우 swap먼저 비활성화하는 것이 좋습니다.

sudo swapoff -a

그런 다음 chroot를 실행합니다.

sudo mkdir /sysroot
sudo mount --rbind /tmp/sys /sysroot
sudo touch /etc/initrd-release
sudo systemctl --no-block isolate initrd-switch-root
# it will stop all other services (isolate) and call systemctl switch-root /sysroot

chroot를 수행할 때 일반적으로 수행하는 것처럼 바인딩은 필요하지 않으며 systemd가 이를 수행 proc합니다 . dev연결이 끊어졌을 수도 있습니다. 잠시 기다려도 연결이 되지 않으면 애도를 표합니다. 당신은 낭비한 것입니다.

그러나 운이 좋아 지금 연결할 수 있다면 원하는 파티션 테이블 변경을 수행할 수 있습니다.

blkid새 경로와 일치하도록 장치 경로와 uuid()를 조정하는 것이 중요합니다.

sudo mv /etc/fstab- /etc/fstab
sudo vi /etc/fstab
sudo vi /etc/default/grub

변경을 완료한 후에는 동일한 전략을 수행하여 실제 루트 장치로 다시 전환할 수 있으며, 작업이 완료되면 종료 시 다시 복원할 수 있도록 새 환경에 대한 부트로더를 설치하는 것을 잊지 마십시오.

sudo grub2-install /dev/sda # or the intended bootable disk
sudo grub2-mkconfig -o /etc/grub2.cfg

물리적 장치로 다시 전환한 후 해당 장치를 사용 중인 경우 다음을 수행 zram하여 메모리를 확보할 수 있습니다.

echo 1 | sudo tee /sys/block/zram0/reset
sudo modprobe -r zram

이 작업을 수행할 때 발생하는 위험은 사용자 본인의 책임임을 기억하세요.

관련 정보