パッケージのクリーンアップでクリーンアップできないブートパーティションをクリーンアップする方法は?

パッケージのクリーンアップでクリーンアップできないブートパーティションをクリーンアップする方法は?

最近、研究室/開発コンピュータに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)

実際には1つのカーネルしかインストールされていないため、単に実行することは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

関連情報