더 높은 버전의 GLIBC가 필요한 Deepin Linux 20에 소프트웨어를 설치하려고 합니다. 내가 찾은스택 오버플로를 수행하는 방법에 대한 질문일부 답변의 지침을 따르세요. 이제 컴퓨터를 부팅하려고 할 때마다 Deepin 로고가 나타나고 멈춥니다(애니메이션이어야 함). 컴퓨터는 로고를 숨기고 텍스트 출력을 표시하는 키 입력을 포함하여 어떤 키 입력에도 응답하지 않습니다.
터미널로 부팅할 수도 없는 경우 부팅 로그를 확인하거나 이 변경 사항을 취소하려면 어떻게 해야 합니까? 다른 시스템으로 부팅할 수 있지만 기본 시스템을 오프라인으로 수정하는 방법을 모르겠습니다.
의견에 제안된 대로 부팅 옵션을 제거한 후 quiet이제 splash문제에 대한 세부 정보를 얻을 수 있습니다.
맨 아래에는 다음 줄이 있습니다.
---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0007f00 ]---
또한 커널 패닉을 일으키는 것으로 생각되는 줄이 있습니다.
/init: line 83: wait-for-root: not found
또 다른 줄에서는 커널 패닉에 대해 자세히 설명합니다.
/sbin/init: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory
답변1
(저는 이 지침이 갑자기 수영장, 싱크대 또는 수영의 깊은 곳에 던져진 것처럼 느껴질 수 있다는 것을 알고 있습니다. 이 지침이 충분히 자세하지 않은 것 같으면 가까운 Linux 경험이 있는 사람을 찾아 시도해 볼 것을 적극 권장합니다. 그들과 함께 문제를 해결하세요).
복원할 백업이 없는 경우 가장 쉬운 복구 방법은 이전 라이브러리를 수동으로 추출하여 다시 넣고 시스템이 chroot 가능해지면 패키지 관리자를 사용하여 최신 라이브러리 패키지를 다운그레이드하는 것입니다.
.debar x package.deb세 가지 파일을 생성하는 패키지 수동 추출을 사용할 수 있습니다 . control.tar.xz사전/사후 설치/제거 스크립트(있는 경우) 및 패키지 관리자의 메타데이터가 포함되어 있으며, data.tar.xz압축을 푼 경우 상대 경로로 패키지된 실제 파일이 포함되어 있습니다 data.tar.xz. 시스템 루트 디렉터리에 있으면 파일이 예상 위치에 자동으로 추출됩니다.
이 특별한 경우에는 백업 시스템으로 부팅하고 손상된 기본 시스템의 루트 파일 시스템을 마운트한 다음 data.tar.xz기본 시스템의 루트에 있는 디렉터리에 있는 해당 glibc 패키지에서 해당 파일 시스템을 추출합니다. 즉, 기본 루트 파일 시스템을 에 마운트하는 경우 다음을 사용하여 추출 /mnt합니다 data.tar.xz.
cd /mnt
tar xvf /where/ever/data.tar.xz
또한 기본 시스템의 내용도 읽어야 합니다 /var/log/dpkg.log(즉, /mnt/var/log/dpkg.log기본 운영 체제의 루트 파일 시스템이 마운트된 경우 /mnt). 파일에는 다음과 같은 줄이 있어야 합니다.
<timestamp> upgrade <package name>:<arch> <old version> <new version>
이는 불운한 업그레이드 시도를 시작하기 전에 어떤 패키지 버전이 있었는지, 그리고 glibc 업그레이드로 인해 다른 라이브러리 패키지도 업그레이드되었는지 여부를 정확하게 알려줍니다. 만약 그렇다면 해당 패키지도 복원해야 할 수 있습니다.
필요한 라이브러리의 올바른 버전을 복원한 후에는 chroot를 통해 기본 시스템을 테스트할 수 있습니다. 기본 시스템의 루트 파일 시스템이 다음에 마운트되어 있다고 가정합니다 /mnt.
mount --rbind /dev /mnt/dev
mount --rbind /sys /mnt/sys
mount -t proc proc /mnt/proc
chroot /mnt
이러한 명령 후에 chroot 명령을 입력한 셸 세션은 기본적으로 기본 시스템이 최소한으로 실행되는 것처럼("단일 사용자 모드") 기본 시스템 환경에서 실행될 수 있습니다. 실행하여 누락된 라이브러리가 없는지 보고하는지 확인해야 하며 ldd /sbin/init중요한 시스템 바이너리에 대해서도 동일한 작업을 수행해야 합니다.
이 시점에서 패키지 관리자를 사용하여 실패한 업그레이드를 주의 깊게 되돌릴 수 있어야 합니다. 그러면 현재 설치된 파일에 대한 패키지 관리자의 아이디어가 다시 현실적이 될 것입니다(따라서 나중에 종속성 문제가 발생하지 않습니다). 업그레이드 중에 패키지가 제거된 것으로 표시된 경우 dpkg.log업그레이드 이전에 존재했던 정확한 구성으로 되돌릴 수 있도록 제거된 패키지를 다시 설치해야 합니다.
업그레이드 시도 후 수동 작업을 수행했거나 기본 설치 의 파일 타임스탬프에 업그레이드 시도 중에 업데이트된 것으로 표시된 update-initramfs -u경우 chrooted 쉘 세션에서 실행하여 좋은 라이브러리로 기본 시스템의 initramfs를 다시 빌드 해야 할 수도 있습니다 .initrd.img-<kernel version>/bootupdate-initramfs -u -k <kernel version>
glibc 업그레이드 시도 중에 업데이트된 모든 라이브러리 패키지를 복원했다면 이제 기본 시스템이 업그레이드 전 상태로 돌아가서 다시 부팅할 수 있어야 합니다.
배포판의 나머지 부분도 업그레이드하지 않고 GLIBC를 업데이트하는 것은 일반적으로 나쁜 생각입니다. GLIBC는 기본적으로 시스템의 모든 실행 가능한 바이너리가 의존하는 초석이 되는 경우가 많으며 많은 라이브러리 파일도 이에 의존합니다.
배포판 빌더는 핵심 시스템 라이브러리 버전 세트(GLIBC 포함)를 선택하고 함께 잘 작동하도록 빌드 및 구성합니다. 이러한 라이브러리 중 하나를 다른 배포판(또는 해당 배포판의 다른 주요 버전)용 패키지로 교체하는 경우동일한배포), 이러한 상호 의존성은 위험에 처할 수 있으며 예상대로 실행되지 않거나 전혀 실행되지 않을 수 있습니다.