패키지 정리를 통해 정리할 수 없는 부팅 파티션을 정리하는 방법은 무엇입니까?

패키지 정리를 통해 정리할 수 없는 부팅 파티션을 정리하는 방법은 무엇입니까?

최근에 연구실/개발 컴퓨터에 CentOS 7을 다시 설치했습니다. /home이전 설치의 파티션을 유지하고 싶었 기 때문에 이를 수행할 수 있도록 파티션을 수동으로 구성했습니다. 그 과정에서 우연히반품이전에 설치된 /boot파티션을 보존합니다.

성공적으로 설치한 후 매우 바쁜 Grub2 시작 화면을 보았습니다. "새" 깨끗한 CentOS 설치를 제외하고 모든 이전 커널 이미지가 부팅 화면에 나타납니다.

CentOS Linux (3.10.0-693.11.1.el7.x86_64) 7 (Core)
CentOS Linux (3.10.0-693.5.2.el7.x86_64) 7 (Core)
CentOS Linux (3.10.0-693.el7.x86_64) 7 (Core)   <--- this is the new/reinstalled OS
CentOS Linux (3.10.0-693.11.1.el7.x86_64.debug) 7 (Core)
CentOS Linux (0-rescue-7859fc0fbe934b91b11ea69046b5d787) 7 (Core)
CentOS Linux (0-rescue-6c92bef5457049e5a42e5609c540d753) 7 (Core)
CentOS Linux (0-rescue-e7a05dc4cdda4e778a344945ef1ed391) 7 (Core)

실제로 하나의 커널만 설치되므로 단순히 실행하는 것은 package-cleanup작동하지 않습니다(새 운영 체제에 관한 한).

$ package-cleanup --oldkernels --count=1
No old kernels to remove

$ uname -r
3.10.0-693.el7.x86_64

$ rpm -qa kernel*
kernel-debug-devel-3.10.0-693.11.6.el7.x86_64
kernel-3.10.0-693.el7.x86_64
kernel-headers-3.10.0-693.11.6.el7.x86_64
kernel-tools-libs-3.10.0-693.el7.x86_64
kernel-tools-3.10.0-693.el7.x86_64

따라서 저는 이것이 일반적인 " /boot파티션을 어떻게 청소합니까?"라는 사기라고 생각하지 않습니다. 질문(예:CentOS 7에서 이전 커널 버전을 안전하게 제거하는 방법은 무엇입니까?)

일반적으로 엉망인 Grub2 메뉴를 처리해야 하지만 내 /boot파티션에는 11MiB만 남아 있으므로 커널을 업데이트할 수 없습니다.

/boot파티션에서 삭제해도 안전한 것이 무엇인지 잘 모르겠습니다 . package-cleanup청소하지 않을 때는 어떻게 청소하나요?

답변1

이를 사용하여 yum whatprovides /boot/*아직 설치되어 있는 커널과 안전하게 제거할 수 있는 패키지의 일부가 아닌 커널을 확인할 수 있습니다. 그러나 이는 grub이 자동으로 구성되고 있다고 가정합니다.

답변2

jdwolf의 답변이전 시스템에서 생성된 패키지는 의 항목 목록을 제공 /boot/*하지만 약간 길며 CentOS를 다시 설치하면 어떤 파일이 관련이 없는지 즉시 명확하지 않습니다. 일부 출력의 예:

$ yum whatprovides /boot/*

kernel-3.10.0-693.5.2.el7.x86_64 : The Linux kernel
Repo        : updates
Matched from:
Filename    : /boot/config-3.10.0-693.5.2.el7.x86_64

kernel-3.10.0-693.el7.x86_64 : The Linux kernel
Repo        : base
Matched from:
Filename    : /boot/config-3.10.0-693.el7.x86_64

fwupdate-efi-9-8.el7.x86_64 : UEFI binaries used by libfwup
Repo        : base
Matched from:
Filename    : /boot/efi

[... truncated output ...]

rpm -q --whatprovides /boot/*하지만 이로 인해 파일이 필요한지 결정하는 데 더 유용한 이 방법을 대신 사용하게 되었습니다 .

$ rpm -q --whatprovides /boot/*
file /boot/config-3.10.0-693.11.1.el7.x86_64 is not owned by any package
file /boot/config-3.10.0-693.11.1.el7.x86_64.debug is not owned by any package
file /boot/config-3.10.0-693.5.2.el7.x86_64 is not owned by any package
kernel-3.10.0-693.el7.x86_64
file /boot/efi is not owned by any package
file /boot/elf-memtest86+-5.01 is not owned by any package
file /boot/grub is not owned by any package
grub2-common-2.02-0.65.el7.centos.2.noarch
[... truncated output ...]

rpm -q --whatprovides입력 파일 이름이 제공하는 패키지와 일치하는 경우 입력 파일 이름이 인쇄되지 않습니다 . 그러나 0파일이 패키지에서 제공되거나 파일이 패키지에서 제공되지 않으면 1반환됩니다 . 따라서 해결책은 간단합니다.

$ for f in /boot/*; do rpm -q --whatprovides $f || rm -f $f; done
file /boot/config-3.10.0-693.11.1.el7.x86_64 is not owned by any package
file /boot/config-3.10.0-693.11.1.el7.x86_64.debug is not owned by any package
file /boot/config-3.10.0-693.5.2.el7.x86_64 is not owned by any package
kernel-3.10.0-693.el7.x86_64
file /boot/efi is not owned by any package
rm: cannot remove ‘/boot/efi’: Is a directory
file /boot/elf-memtest86+-5.01 is not owned by any package
[... truncated output ...]

$ ls -1 /boot
config-3.10.0-693.el7.x86_64
efi
grub
grub2
initramfs-3.10.0-693.el7.x86_64.img
symvers-3.10.0-693.el7.x86_64.gz
System.map-3.10.0-693.el7.x86_64
vmlinuz-3.10.0-693.el7.x86_64

이것을 실행하면 grub2-mkconfig -o /boot/grub2/grub.cfgGrub 메뉴가 깨끗해지고 디렉토리도 깨끗해집니다 /boot.

참고: 이것을 사용하는 것이 더 좋고 안전할 수도 있지만 find /boot -type f -exec ...(또는 어쩌면 ) 디렉토리가 삭제되지 않기 find ... -xargs ...때문에 내 솔루션은 제대로 작동합니다 .rm -f

관련 정보