(f-40; gnome; stand-alone dual-boot workstation; kernel 6.11.3)
Selected command output...
-bash.2[~]: rpm -qa kernel kernel-6.10.12-200.fc40.x86_64 kernel-6.11.3-200.fc40.x86_64 -bash.3[~]:
-bash.3[~]: rpm -qa kernel-core kernel-core-6.10.12-200.fc40.x86_64 kernel-core-6.11.3-200.fc40.x86_64 -bash.4[~]:
-bash.4[~]: ls -l /boot total 297300 -rw-r--r--. 1 root root 275360 Sep 29 18:00 config-6.10.12-100.fc39.x86_64
-rw-------. 1 root root 77162500 Oct 10 10:12 initramfs-6.10.12-100.fc39.x86_64.img
-rw-r--r--. 1 root root 165784 Oct 10 10:12 symvers-6.10.12-100.fc39.x86_64.xz
-rw-r--r--. 1 root root 9116365 Sep 29 18:00 System.map-6.10.12-100.fc39.x86_64
-rwxr-xr-x. 1 root root 15903080 Sep 29 18:00 vmlinuz-6.10.12-100.fc39.x86_64
-bash.5[~]:
-bash.11[~]: ls -l /boot/loader/entries total 8
-rw-r--r--. 1 root root 540 Oct 10 10:11 70857e3fb05849139515e66a3fdc6b38-6.10.12-100.fc39.x86_64.conf
-bash.12[~]:
My grub menu has 3 Fedora entries (two f-40, one f-39). There should only be 2: the f-40 entries. What I listed above from the "ls" commands are what appear to be the extra files. I've deleted from the output entries for the f-40 kernels and the memtest entries. The "rpm" output is for your information.
The questions: 1. Am I correct in assuming that I get rid of the extra files listed above? 2. If yes, should I do that by using the "rm" command, or would it be better to do it another way? If another way, how? (Would using the "rm" command mess up a database?) 3. What else (if anything) should I do to complete this clean-up properly?
On Oct 22, 2024, at 20:42, home user via users users@lists.fedoraproject.org wrote:
(f-40; gnome; stand-alone dual-boot workstation; kernel 6.11.3)
Selected command output...
-bash.2[~]: rpm -qa kernel kernel-6.10.12-200.fc40.x86_64 kernel-6.11.3-200.fc40.x86_64 -bash.3[~]:
-bash.3[~]: rpm -qa kernel-core kernel-core-6.10.12-200.fc40.x86_64 kernel-core-6.11.3-200.fc40.x86_64 -bash.4[~]:
-bash.4[~]: ls -l /boot total 297300 -rw-r--r--. 1 root root 275360 Sep 29 18:00 config-6.10.12-100.fc39.x86_64
-rw-------. 1 root root 77162500 Oct 10 10:12 initramfs-6.10.12-100.fc39.x86_64.img
-rw-r--r--. 1 root root 165784 Oct 10 10:12 symvers-6.10.12-100.fc39.x86_64.xz
-rw-r--r--. 1 root root 9116365 Sep 29 18:00 System.map-6.10.12-100.fc39.x86_64
-rwxr-xr-x. 1 root root 15903080 Sep 29 18:00 vmlinuz-6.10.12-100.fc39.x86_64
-bash.5[~]:
-bash.11[~]: ls -l /boot/loader/entries total 8
-rw-r--r--. 1 root root 540 Oct 10 10:11 70857e3fb05849139515e66a3fdc6b38-6.10.12-100.fc39.x86_64.conf
-bash.12[~]:
My grub menu has 3 Fedora entries (two f-40, one f-39). There should only be 2: the f-40 entries. What I listed above from the "ls" commands are what appear to be the extra files. I've deleted from the output entries for the f-40 kernels and the memtest entries. The "rpm" output is for your information.
The questions:
- Am I correct in assuming that I get rid of the extra files listed above?
- If yes, should I do that by using the "rm" command, or would it be better to do it another way? If another way, how? (Would using the "rm" command mess up a database?)
- What else (if anything) should I do to complete this clean-up properly?
Just to double check, is there a directory in /boot/efi named after your Machine ID (what’s in /etc/machine-id) with kernels and BLSCFG entries?
On 10/23/24 3:18 PM, Jonathan Billings wrote:
On Oct 22, 2024, at 20:42, home user via users users@lists.fedoraproject.org wrote:
(f-40; gnome; stand-alone dual-boot workstation; kernel 6.11.3)
Selected command output...
-bash.2[~]: rpm -qa kernel kernel-6.10.12-200.fc40.x86_64 kernel-6.11.3-200.fc40.x86_64 -bash.3[~]:
-bash.3[~]: rpm -qa kernel-core kernel-core-6.10.12-200.fc40.x86_64 kernel-core-6.11.3-200.fc40.x86_64 -bash.4[~]:
-bash.4[~]: ls -l /boot total 297300 -rw-r--r--. 1 root root 275360 Sep 29 18:00 config-6.10.12-100.fc39.x86_64
-rw-------. 1 root root 77162500 Oct 10 10:12 initramfs-6.10.12-100.fc39.x86_64.img
-rw-r--r--. 1 root root 165784 Oct 10 10:12 symvers-6.10.12-100.fc39.x86_64.xz
-rw-r--r--. 1 root root 9116365 Sep 29 18:00 System.map-6.10.12-100.fc39.x86_64
-rwxr-xr-x. 1 root root 15903080 Sep 29 18:00 vmlinuz-6.10.12-100.fc39.x86_64
-bash.5[~]:
-bash.11[~]: ls -l /boot/loader/entries total 8
-rw-r--r--. 1 root root 540 Oct 10 10:11 70857e3fb05849139515e66a3fdc6b38-6.10.12-100.fc39.x86_64.conf
-bash.12[~]:
My grub menu has 3 Fedora entries (two f-40, one f-39). There should only be 2: the f-40 entries. What I listed above from the "ls" commands are what appear to be the extra files. I've deleted from the output entries for the f-40 kernels and the memtest entries. The "rpm" output is for your information.
The questions:
- Am I correct in assuming that I get rid of the extra files listed above?
- If yes, should I do that by using the "rm" command, or would it be better to do it another way? If another way, how? (Would using the "rm" command mess up a database?)
- What else (if anything) should I do to complete this clean-up properly?
Just to double check, is there a directory in /boot/efi named after your Machine ID (what’s in /etc/machine-id) with kernels and BLSCFG entries?
-bash.11[~]: ls -l /etc/machine-id -r--r--r--. 1 root root 33 Mar 17 2013 /etc/machine-id -bash.12[~]: cat /etc/machine-id 70857e3fb05849139515e66a3fdc6b38 -bash.13[~]:
-bash.13[~]: ls -la /boot/efi/ total 11 drwx------. 3 root root 1024 Jan 23 2024 . dr-xr-xr-x. 6 root root 5120 Oct 19 10:46 .. drwx------. 4 root root 1024 Jan 23 2024 EFI -bash.14[~]: ls -la /boot/efi/EFI/ total 8 drwx------. 4 root root 1024 Jan 23 2024 . drwx------. 3 root root 1024 Jan 23 2024 .. drwx------. 2 root root 1024 Jan 23 2024 BOOT drwx------. 2 root root 1024 Oct 10 18:50 fedora -bash.15[~]:
Apparently not. I'm curious: What's the significance of that?
On 10/23/24 2:56 PM, home user via users wrote:
On 10/23/24 3:18 PM, Jonathan Billings wrote:
On Oct 22, 2024, at 20:42, home user via users users@lists.fedoraproject.org wrote:
(f-40; gnome; stand-alone dual-boot workstation; kernel 6.11.3)
Selected command output...
-bash.2[~]: rpm -qa kernel kernel-6.10.12-200.fc40.x86_64 kernel-6.11.3-200.fc40.x86_64 -bash.3[~]:
-bash.3[~]: rpm -qa kernel-core kernel-core-6.10.12-200.fc40.x86_64 kernel-core-6.11.3-200.fc40.x86_64 -bash.4[~]:
-bash.4[~]: ls -l /boot total 297300 -rw-r--r--. 1 root root 275360 Sep 29 18:00 config-6.10.12-100.fc39.x86_64
-rw-------. 1 root root 77162500 Oct 10 10:12 initramfs-6.10.12-100.fc39.x86_64.img
-rw-r--r--. 1 root root 165784 Oct 10 10:12 symvers-6.10.12-100.fc39.x86_64.xz
-rw-r--r--. 1 root root 9116365 Sep 29 18:00 System.map-6.10.12-100.fc39.x86_64
-rwxr-xr-x. 1 root root 15903080 Sep 29 18:00 vmlinuz-6.10.12-100.fc39.x86_64
-bash.5[~]:
-bash.11[~]: ls -l /boot/loader/entries total 8
-rw-r--r--. 1 root root 540 Oct 10 10:11 70857e3fb05849139515e66a3fdc6b38-6.10.12-100.fc39.x86_64.conf
-bash.12[~]:
My grub menu has 3 Fedora entries (two f-40, one f-39). There should only be 2: the f-40 entries. What I listed above from the "ls" commands are what appear to be the extra files. I've deleted from the output entries for the f-40 kernels and the memtest entries. The "rpm" output is for your information.
The questions:
- Am I correct in assuming that I get rid of the extra files listed
above? 2. If yes, should I do that by using the "rm" command, or would it be better to do it another way? If another way, how? (Would using the "rm" command mess up a database?) 3. What else (if anything) should I do to complete this clean-up properly?
Just to double check, is there a directory in /boot/efi named after your Machine ID (what’s in /etc/machine-id) with kernels and BLSCFG entries?
-bash.11[~]: ls -l /etc/machine-id -r--r--r--. 1 root root 33 Mar 17 2013 /etc/machine-id -bash.12[~]: cat /etc/machine-id 70857e3fb05849139515e66a3fdc6b38 -bash.13[~]:
-bash.13[~]: ls -la /boot/efi/ total 11 drwx------. 3 root root 1024 Jan 23 2024 . dr-xr-xr-x. 6 root root 5120 Oct 19 10:46 .. drwx------. 4 root root 1024 Jan 23 2024 EFI -bash.14[~]: ls -la /boot/efi/EFI/ total 8 drwx------. 4 root root 1024 Jan 23 2024 . drwx------. 3 root root 1024 Jan 23 2024 .. drwx------. 2 root root 1024 Jan 23 2024 BOOT drwx------. 2 root root 1024 Oct 10 18:50 fedora -bash.15[~]:
Apparently not. I'm curious: What's the significance of that?
It's not supposed to be there. It's in the filenames in /boot/loader/entries/ as you showed earlier.
On Oct 23, 2024, at 17:56, home user via users users@lists.fedoraproject.org wrote:
On 10/23/24 3:18 PM, Jonathan Billings wrote:
On Oct 22, 2024, at 20:42, home user via users users@lists.fedoraproject.org wrote:
(f-40; gnome; stand-alone dual-boot workstation; kernel 6.11.3)
Selected command output...
-bash.2[~]: rpm -qa kernel kernel-6.10.12-200.fc40.x86_64 kernel-6.11.3-200.fc40.x86_64 -bash.3[~]:
-bash.3[~]: rpm -qa kernel-core kernel-core-6.10.12-200.fc40.x86_64 kernel-core-6.11.3-200.fc40.x86_64 -bash.4[~]:
-bash.4[~]: ls -l /boot total 297300 -rw-r--r--. 1 root root 275360 Sep 29 18:00 config-6.10.12-100.fc39.x86_64
-rw-------. 1 root root 77162500 Oct 10 10:12 initramfs-6.10.12-100.fc39.x86_64.img
-rw-r--r--. 1 root root 165784 Oct 10 10:12 symvers-6.10.12-100.fc39.x86_64.xz
-rw-r--r--. 1 root root 9116365 Sep 29 18:00 System.map-6.10.12-100.fc39.x86_64
-rwxr-xr-x. 1 root root 15903080 Sep 29 18:00 vmlinuz-6.10.12-100.fc39.x86_64
-bash.5[~]:
-bash.11[~]: ls -l /boot/loader/entries total 8
-rw-r--r--. 1 root root 540 Oct 10 10:11 70857e3fb05849139515e66a3fdc6b38-6.10.12-100.fc39.x86_64.conf
-bash.12[~]:
My grub menu has 3 Fedora entries (two f-40, one f-39). There should only be 2: the f-40 entries. What I listed above from the "ls" commands are what appear to be the extra files. I've deleted from the output entries for the f-40 kernels and the memtest entries. The "rpm" output is for your information.
The questions:
- Am I correct in assuming that I get rid of the extra files listed above?
- If yes, should I do that by using the "rm" command, or would it be better to do it another way? If another way, how? (Would using the "rm" command mess up a database?)
- What else (if anything) should I do to complete this clean-up properly?
Just to double check, is there a directory in /boot/efi named after your Machine ID (what’s in /etc/machine-id) with kernels and BLSCFG entries?
-bash.11[~]: ls -l /etc/machine-id -r--r--r--. 1 root root 33 Mar 17 2013 /etc/machine-id -bash.12[~]: cat /etc/machine-id 70857e3fb05849139515e66a3fdc6b38 -bash.13[~]:
-bash.13[~]: ls -la /boot/efi/ total 11 drwx------. 3 root root 1024 Jan 23 2024 . dr-xr-xr-x. 6 root root 5120 Oct 19 10:46 .. drwx------. 4 root root 1024 Jan 23 2024 EFI -bash.14[~]: ls -la /boot/efi/EFI/ total 8 drwx------. 4 root root 1024 Jan 23 2024 . drwx------. 3 root root 1024 Jan 23 2024 .. drwx------. 2 root root 1024 Jan 23 2024 BOOT drwx------. 2 root root 1024 Oct 10 18:50 fedora -bash.15[~]:
Apparently not. I'm curious: What's the significance of that?
Just wanted to make sure you didn’t have kernels installed in the systemd-boot locations.
(updated and revised)
On 10/23/24 5:51 PM, Jonathan Billings wrote:
On Oct 23, 2024, at 17:56, home user via users users@lists.fedoraproject.org wrote:
-bash.1[~]: rpm -qa kernel [complete] kernel-6.11.3-200.fc40.x86_64 kernel-6.11.4-201.fc40.x86_64 -bash.2[~]:
-bash.2[~]: rpm -qa kernel-core [complete] kernel-core-6.11.3-200.fc40.x86_64 kernel-core-6.11.4-201.fc40.x86_64 -bash.3[~]:
-bash.3[~]: ls -l /boot | grep -v fc40 [edited] total 298684 -rw-r--r--. 1 root root 275360 Sep 29 18:00 config-6.10.12-100.fc39.x86_64 ... -rw-------. 1 root root 77162500 Oct 10 10:12 initramfs-6.10.12-100.fc39.x86_64.img ... -rw-r--r--. 1 root root 165784 Oct 10 10:12 symvers-6.10.12-100.fc39.x86_64.xz -rw-r--r--. 1 root root 9116365 Sep 29 18:00 System.map-6.10.12-100.fc39.x86_64 -rwxr-xr-x. 1 root root 15903080 Sep 29 18:00 vmlinuz-6.10.12-100.fc39.x86_64 -bash.4[~]:
-bash.4[~]: ls -l /boot/loader/entries | grep -v fc40 [complete] total 8 ... -rw-r--r--. 1 root root 540 Oct 10 10:11 70857e3fb05849139515e66a3fdc6b38-6.10.12-100.fc39.x86_64.conf -bash.5[~]:
[snip]
Yesterday's weekly patching cleaned out extra items in the "rpm" commands.
I'm still needing answers to the original questions. One word was inadvertently left out of the first question. Here are the corrected questions: 1. Am I correct in assuming that I SHOULD get rid of the extra files listed above? 2. If yes, should I do that by using the "rm" command, or would it be better to do it another way? If another way, how? (Would using the "rm" command mess up a database?) 3. What else (if anything) should I do to complete this clean-up properly?
On Tue, Oct 22, 2024 at 8:42 PM home user via users users@lists.fedoraproject.org wrote:
(f-40; gnome; stand-alone dual-boot workstation; kernel 6.11.3)
Selected command output...
-bash.2[~]: rpm -qa kernel kernel-6.10.12-200.fc40.x86_64 kernel-6.11.3-200.fc40.x86_64 -bash.3[~]:
-bash.3[~]: rpm -qa kernel-core kernel-core-6.10.12-200.fc40.x86_64 kernel-core-6.11.3-200.fc40.x86_64 -bash.4[~]:
Related, be sure to look in /lib/modules for old kernel artifacts. There have been several bugs related to proceccessing old kernel removals. The removal scripts would _not_ remove the directory if they were not empty, and the script had a bug that left a few small files.
Something like this is safe to run to cleanup /lib/modules:
# https://bugzilla.redhat.com/show_bug.cgi?id=2185410 clean_lib_modules() { if [[ -d "/lib/modules" ]]; then echo "Cleaning /lib/modules" # dirs=($(ls /lib/modules)) mapfile -t dirs < <(ls /lib/modules) for dir in "${dirs[@]}" do dir="/lib/modules/${dir}" if [ "$(du -s -B 4096 "${dir}" | awk '{print $1}')" -lt 4096 ] then echo " removing ${dir}" rm -rf "${dir}" 2>/dev/null fi done fi }
Jeff
On 10/25/24 12:45 PM, Jeffrey Walton wrote:
On Tue, Oct 22, 2024 at 8:42 PM home user via users users@lists.fedoraproject.org wrote:
(f-40; gnome; stand-alone dual-boot workstation; kernel 6.11.3)
Selected command output...
-bash.2[~]: rpm -qa kernel kernel-6.10.12-200.fc40.x86_64 kernel-6.11.3-200.fc40.x86_64 -bash.3[~]:
-bash.3[~]: rpm -qa kernel-core kernel-core-6.10.12-200.fc40.x86_64 kernel-core-6.11.3-200.fc40.x86_64 -bash.4[~]:
Related, be sure to look in /lib/modules for old kernel artifacts. There have been several bugs related to proceccessing old kernel removals. The removal scripts would _not_ remove the directory if they were not empty, and the script had a bug that left a few small files.
Something like this is safe to run to cleanup /lib/modules:
# https://bugzilla.redhat.com/show_bug.cgi?id=2185410 clean_lib_modules() { if [[ -d "/lib/modules" ]]; then echo "Cleaning /lib/modules" # dirs=($(ls /lib/modules)) mapfile -t dirs < <(ls /lib/modules) for dir in "${dirs[@]}" do dir="/lib/modules/${dir}" if [ "$(du -s -B 4096 "${dir}" | awk '{print $1}')" -lt 4096 ] then echo " removing ${dir}" rm -rf "${dir}" 2>/dev/null fi done fi }
Jeff
I do not fully understand that script, but I did the clean-up. 5 old directories, each having several times 4096 blocks were left behind. I don't know if the problem is in dnf, a database, or something/somewhere else. But post patching clean-up seems to be an ongoing problem.
I'm still needing the answer to the core questions of this thread.
On Sat, Oct 26, 2024 at 5:43 PM home user via users users@lists.fedoraproject.org wrote:
On 10/25/24 12:45 PM, Jeffrey Walton wrote:
On Tue, Oct 22, 2024 at 8:42 PM home user via users users@lists.fedoraproject.org wrote:
(f-40; gnome; stand-alone dual-boot workstation; kernel 6.11.3)
Selected command output...
-bash.2[~]: rpm -qa kernel kernel-6.10.12-200.fc40.x86_64 kernel-6.11.3-200.fc40.x86_64 -bash.3[~]:
-bash.3[~]: rpm -qa kernel-core kernel-core-6.10.12-200.fc40.x86_64 kernel-core-6.11.3-200.fc40.x86_64 -bash.4[~]:
Related, be sure to look in /lib/modules for old kernel artifacts. There have been several bugs related to proceccessing old kernel removals. The removal scripts would _not_ remove the directory if they were not empty, and the script had a bug that left a few small files.
Something like this is safe to run to cleanup /lib/modules:
# https://bugzilla.redhat.com/show_bug.cgi?id=2185410 clean_lib_modules() { if [[ -d "/lib/modules" ]]; then echo "Cleaning /lib/modules" # dirs=($(ls /lib/modules)) mapfile -t dirs < <(ls /lib/modules) for dir in "${dirs[@]}" do dir="/lib/modules/${dir}" if [ "$(du -s -B 4096 "${dir}" | awk '{print $1}')" -lt 4096 ] then echo " removing ${dir}" rm -rf "${dir}" 2>/dev/null fi done fi }
I do not fully understand that script, but I did the clean-up. 5 old directories, each having several times 4096 blocks were left behind. I don't know if the problem is in dnf, a database, or something/somewhere else. But post patching clean-up seems to be an ongoing problem.
The script uses `du` to count the size of files in the directory tree of each [previously installed] kernel. If the size is less than 4K, it deletes the directory tree. If the size is greater than 4K, then it is not touched.
Here's an example of what causes the accumulation of leftovers in /lib/modules from a Linux Mint machine. As I understand things, the kernel uses the same scripts everywhere. Notice the "dpkg: warning...".
Removing linux-modules-5.15.0-122-generic (5.15.0-122.132) ... (Reading database ... 375164 files and directories currently installed.) Purging configuration files for linux-modules-5.15.0-122-generic (5.15.0-122.132) ... dpkg: warning: while removing linux-modules-5.15.0-122-generic, directory '/lib/modules/5.15.0-122-generic' not empty so not removed Purging configuration files for linux-image-5.15.0-122-generic (5.15.0-122.132) ... Purging configuration files for linux-modules-extra-5.15.0-122-generic (5.15.0-122.132) ... ...
I'm still needing the answer to the core questions of this thread.
Jeff
On 11/6/24 11:12 AM, Jeffrey Walton wrote:
On Sat, Oct 26, 2024 at 5:43 PM home user via users users@lists.fedoraproject.org wrote:
On 10/25/24 12:45 PM, Jeffrey Walton wrote:
On Tue, Oct 22, 2024 at 8:42 PM home user via users users@lists.fedoraproject.org wrote:
(f-40; gnome; stand-alone dual-boot workstation; kernel 6.11.3)
Selected command output...
-bash.2[~]: rpm -qa kernel kernel-6.10.12-200.fc40.x86_64 kernel-6.11.3-200.fc40.x86_64 -bash.3[~]:
-bash.3[~]: rpm -qa kernel-core kernel-core-6.10.12-200.fc40.x86_64 kernel-core-6.11.3-200.fc40.x86_64 -bash.4[~]:
Related, be sure to look in /lib/modules for old kernel artifacts. There have been several bugs related to proceccessing old kernel removals. The removal scripts would _not_ remove the directory if they were not empty, and the script had a bug that left a few small files.
Something like this is safe to run to cleanup /lib/modules:
# https://bugzilla.redhat.com/show_bug.cgi?id=2185410 clean_lib_modules() { if [[ -d "/lib/modules" ]]; then echo "Cleaning /lib/modules" # dirs=($(ls /lib/modules)) mapfile -t dirs < <(ls /lib/modules) for dir in "${dirs[@]}" do dir="/lib/modules/${dir}" if [ "$(du -s -B 4096 "${dir}" | awk '{print $1}')" -lt 4096 ] then echo " removing ${dir}" rm -rf "${dir}" 2>/dev/null fi done fi }
I do not fully understand that script, but I did the clean-up. 5 old directories, each having several times 4096 blocks were left behind. I don't know if the problem is in dnf, a database, or something/somewhere else. But post patching clean-up seems to be an ongoing problem.
The script uses `du` to count the size of files in the directory tree of each [previously installed] kernel. If the size is less than 4K, it deletes the directory tree. If the size is greater than 4K, then it is not touched.
Here's an example of what causes the accumulation of leftovers in /lib/modules from a Linux Mint machine. As I understand things, the kernel uses the same scripts everywhere. Notice the "dpkg: warning...".
Removing linux-modules-5.15.0-122-generic (5.15.0-122.132) ... (Reading database ... 375164 files and directories currently installed.) Purging configuration files for linux-modules-5.15.0-122-generic (5.15.0-122.132) ... dpkg: warning: while removing linux-modules-5.15.0-122-generic, directory '/lib/modules/5.15.0-122-generic' not empty so not removed Purging configuration files for linux-image-5.15.0-122-generic (5.15.0-122.132) ... Purging configuration files for linux-modules-extra-5.15.0-122-generic (5.15.0-122.132) ... ...
I'm still needing the answer to the core questions of this thread.
Jeff
Thank-you, Jeff.
Several directories were cleaned out. But several (5) sub-directories were left behind and are still there. All are over 36000 4-k blocks The oldest are 6.2.*, dating back to f-37. Likewise, /boot still has 5 files from 6.10.12 (f-39). S-o-m-e t-h-i-n-g in the patch and upgrade processes is not cleaning up properly.
On Wed, Nov 6, 2024 at 5:04 PM home user via users users@lists.fedoraproject.org wrote:
On 11/6/24 11:12 AM, Jeffrey Walton wrote:
[...]
Related, be sure to look in /lib/modules for old kernel artifacts. There have been several bugs related to proceccessing old kernel removals. The removal scripts would _not_ remove the directory if they were not empty, and the script had a bug that left a few small files.
Something like this is safe to run to cleanup /lib/modules:
# https://bugzilla.redhat.com/show_bug.cgi?id=2185410 clean_lib_modules() { if [[ -d "/lib/modules" ]]; then echo "Cleaning /lib/modules" # dirs=($(ls /lib/modules)) mapfile -t dirs < <(ls /lib/modules) for dir in "${dirs[@]}" do dir="/lib/modules/${dir}" if [ "$(du -s -B 4096 "${dir}" | awk '{print $1}')" -lt 4096 ] then echo " removing ${dir}" rm -rf "${dir}" 2>/dev/null fi done fi }
I do not fully understand that script, but I did the clean-up. 5 old directories, each having several times 4096 blocks were left behind. I don't know if the problem is in dnf, a database, or something/somewhere else. But post patching clean-up seems to be an ongoing problem.
The script uses `du` to count the size of files in the directory tree of each [previously installed] kernel. If the size is less than 4K, it deletes the directory tree. If the size is greater than 4K, then it is not touched.
Here's an example of what causes the accumulation of leftovers in /lib/modules from a Linux Mint machine. As I understand things, the kernel uses the same scripts everywhere. Notice the "dpkg: warning...".
Removing linux-modules-5.15.0-122-generic (5.15.0-122.132) ... (Reading database ... 375164 files and directories currently installed.) Purging configuration files for linux-modules-5.15.0-122-generic (5.15.0-122.132) ... dpkg: warning: while removing linux-modules-5.15.0-122-generic, directory '/lib/modules/5.15.0-122-generic' not empty so not removed Purging configuration files for linux-image-5.15.0-122-generic (5.15.0-122.132) ... Purging configuration files for linux-modules-extra-5.15.0-122-generic (5.15.0-122.132) ... ...
I'm still needing the answer to the core questions of this thread.
Several directories were cleaned out. But several (5) sub-directories were left behind and are still there. All are over 36000 4-k blocks The oldest are 6.2.*, dating back to f-37. Likewise, /boot still has 5 files from 6.10.12 (f-39). S-o-m-e t-h-i-n-g in the patch and upgrade processes is not cleaning up properly.
`package-cleanup --oldkernels --count=2` might help with that. It removes all old kernels except the current kernel and the one before it.
You can also manually do it. For each old kernel listed in /lib/modules, do something like this:
export kernel_ver=6.11.5-200.fc40.x86_64 dnf remove \ kernel-$(kernel_ver) \ kernel-core-$(kernel_ver) \ kernel-devel-$(kernel_ver) \ kernel-modules-$(kernel_ver)
Once you manually remove the old kernels, then run clean_lib_modules to remove the old artifacts in /usr/modules.
Jeff
On 11/6/24 10:15 PM, Jeffrey Walton wrote: [snip]
`package-cleanup --oldkernels --count=2` might help with that. It removes all old kernels except the current kernel and the one before it.
-bash.6[~]: package-cleanup --oldkernels --count=2 package-cleanup has to be executed with one of the options: --dupes, --leaves, --orphans, --problems or --cleandupes -bash.7[~]:
I read the man page. None of the options suggested above or in the man page seem to fit what's needed here.
You can also manually do it. For each old kernel listed in /lib/modules, do something like this:
export kernel_ver=6.11.5-200.fc40.x86_64 dnf remove \ kernel-$(kernel_ver) \ kernel-core-$(kernel_ver) \ kernel-devel-$(kernel_ver) \ kernel-modules-$(kernel_ver)
I had to remove the parentheses. The result of one case:
-bash.8[~]: export kernel_ver=6.10.12-100.fc39.x86_64 -bash.9[~]: echo $kernel_ver 6.10.12-100.fc39.x86_64 -bash.10[~]: dnf remove kernel-$kernel_ver kernel-core-$kernel_ver kernel-devel-$kernel_ver kernel-modules-$kernel_ver No match for argument: kernel-6.10.12-100.fc39.x86_64 No match for argument: kernel-core-6.10.12-100.fc39.x86_64 No match for argument: kernel-devel-6.10.12-100.fc39.x86_64 No match for argument: kernel-modules-6.10.12-100.fc39.x86_64 No packages marked for removal. Dependencies resolved. Nothing to do. Complete! -bash.11[~]:
I still have old kernel files in /boot:
-bash.17[~]: cd /boot -bash.18[boot]: ls *-6.10.* config-6.10.12-100.fc39.x86_64 System.map-6.10.12-100.fc39.x86_64 initramfs-6.10.12-100.fc39.x86_64.img vmlinuz-6.10.12-100.fc39.x86_64 symvers-6.10.12-100.fc39.x86_64.xz -bash.19[boot]:
On 11/7/24 4:15 PM, home user via users wrote:
On 11/6/24 10:15 PM, Jeffrey Walton wrote: [snip]
`package-cleanup --oldkernels --count=2` might help with that. It removes all old kernels except the current kernel and the one before it.
-bash.6[~]: package-cleanup --oldkernels --count=2 package-cleanup has to be executed with one of the options: --dupes, -- leaves, --orphans, --problems or --cleandupes -bash.7[~]:
I read the man page. None of the options suggested above or in the man page seem to fit what's needed here.
You can also manually do it. For each old kernel listed in /lib/modules, do something like this:
export kernel_ver=6.11.5-200.fc40.x86_64 dnf remove \ kernel-$(kernel_ver) \ kernel-core-$(kernel_ver) \ kernel-devel-$(kernel_ver) \ kernel-modules-$(kernel_ver)
I had to remove the parentheses. The result of one case:
-bash.8[~]: export kernel_ver=6.10.12-100.fc39.x86_64 -bash.9[~]: echo $kernel_ver 6.10.12-100.fc39.x86_64 -bash.10[~]: dnf remove kernel-$kernel_ver kernel-core- $kernel_ver kernel-devel-$kernel_ver kernel-modules-$kernel_ver No match for argument: kernel-6.10.12-100.fc39.x86_64 No match for argument: kernel-core-6.10.12-100.fc39.x86_64 No match for argument: kernel-devel-6.10.12-100.fc39.x86_64 No match for argument: kernel-modules-6.10.12-100.fc39.x86_64 No packages marked for removal. Dependencies resolved. Nothing to do. Complete! -bash.11[~]:
I still have old kernel files in /boot:
-bash.17[~]: cd /boot -bash.18[boot]: ls *-6.10.* config-6.10.12-100.fc39.x86_64 System.map-6.10.12-100.fc39.x86_64 initramfs-6.10.12-100.fc39.x86_64.img vmlinuz-6.10.12-100.fc39.x86_64 symvers-6.10.12-100.fc39.x86_64.xz
There are no packages involved. You just have to manually delete the files. You can verify by running "rpm -qf /boot/*" or whatever other directory you're checking to see which files aren't owned.
On 11/7/24 10:22 PM, Samuel Sieb wrote:
On 11/7/24 4:15 PM, home user via users wrote:
On 11/6/24 10:15 PM, Jeffrey Walton wrote: [snip]
[snip]
-bash.11[~]:
I still have old kernel files in /boot:
-bash.17[~]: cd /boot -bash.18[boot]: ls *-6.10.* config-6.10.12-100.fc39.x86_64 System.map-6.10.12-100.fc39.x86_64 initramfs-6.10.12-100.fc39.x86_64.img vmlinuz-6.10.12-100.fc39.x86_64 symvers-6.10.12-100.fc39.x86_64.xz
There are no packages involved. You just have to manually delete the files. You can verify by running "rpm -qf /boot/*" or whatever other directory you're checking to see which files aren't owned.
Thank-you Samuel. That worked.
While doing those "rpm -qf" commands, 2 questions came to mind. 1. Suppose [dir] has sub-directories. If I do "rpm -qf [dir]/*", will it also check [dir]'s sub-directories? If no, then 2. How do get the sub-directories checked without having to do them manually one-by-one?
Comment/suggestion The output for some of the "rpm -qf" runs showed a lot of output. It showed both owned and unowned files. It listed sub-directories as though they were files. It would have been too easy to miss that a file is owned, and then do an "rm -rf" on something that should be kept. I found it helpful to add | grep " not owned " or | grep -v " not owned " to get a clearer picture of things, and to give me more confidence that doing "rm -rf [dir]" is safe.
I recently started a sys.admin. tips file for myself. I'm definitely adding the "rpm -qf" with the pipe to grep to that tips file.
On 11/8/24 10:15 AM, home user via users wrote:
While doing those "rpm -qf" commands, 2 questions came to mind.
- Suppose [dir] has sub-directories. If I do "rpm -qf [dir]/*", will
it also check [dir]'s sub-directories? If no, then 2. How do get the sub-directories checked without having to do them manually one-by-one?
find [dir] -type f -print0 | xargs -0 rpm -qf
On 11/8/24 5:18 PM, Samuel Sieb wrote:
On 11/8/24 10:15 AM, home user via users wrote:
While doing those "rpm -qf" commands, 2 questions came to mind.
- Suppose [dir] has sub-directories. If I do "rpm -qf [dir]/*", will it also check [dir]'s sub-directories?
If no, then 2. How do get the sub-directories checked without having to do them manually one-by-one?
find [dir] -type f -print0 | xargs -0 rpm -qf
I cooked up a simple test /lib/modules/ directory with a subdirectory and a few small text files. Worked fine.
Tried this on /lib/modules/6.11.5-200.fc40.x86_64/. Some files got listed (file names only) a huge number of times (multiple 40-line screens per file). These are (of course) owned by packages. I noticed kernel-modules-core-6.11.5-200.fc40.x86_64 to be listed an especially large number of times. Why? Can this repetition be prevented?
On Fri, Nov 8, 2024 at 8:15 PM home user via users users@lists.fedoraproject.org wrote:
On 11/8/24 5:18 PM, Samuel Sieb wrote:
On 11/8/24 10:15 AM, home user via users wrote:
While doing those "rpm -qf" commands, 2 questions came to mind.
- Suppose [dir] has sub-directories. If I do "rpm -qf [dir]/*", will it also check [dir]'s sub-directories?
If no, then 2. How do get the sub-directories checked without having to do them manually one-by-one?
find [dir] -type f -print0 | xargs -0 rpm -qf
I cooked up a simple test /lib/modules/ directory with a subdirectory and a few small text files. Worked fine.
Tried this on /lib/modules/6.11.5-200.fc40.x86_64/. Some files got listed (file names only) a huge number of times (multiple 40-line screens per file). These are (of course) owned by packages. I noticed kernel-modules-core-6.11.5-200.fc40.x86_64 to be listed an especially large number of times. Why? Can this repetition be prevented?
If a particular kernel was not properly (or maybe cleanly) removed, then there will be an artifact in /lib/modules, and the particular kernel's directory tree will _not_ be empty. A handful of small files is expected. You know about that bug. But a large number of files with megabytes of storage is not expected.
In your case -- a richly populated kernel under /lib/modules -- indicates the kernel was not properly (or maybe cleanly) removed. You should investigate why the dnf remove or rpm erase (or whatever you ran) did not complete successfully. Or, if the package was forcefully removed, then just delete the remaining directory tree in /lib/modules.
Jeff
On 11/8/24 6:33 PM, Jeffrey Walton wrote:
On Fri, Nov 8, 2024 at 8:15 PM home user via users users@lists.fedoraproject.org wrote:
On 11/8/24 5:18 PM, Samuel Sieb wrote:
On 11/8/24 10:15 AM, home user via users wrote:
While doing those "rpm -qf" commands, 2 questions came to mind.
- Suppose [dir] has sub-directories. If I do "rpm -qf [dir]/*", will it also check [dir]'s sub-directories?
If no, then 2. How do get the sub-directories checked without having to do them manually one-by-one?
find [dir] -type f -print0 | xargs -0 rpm -qf
I cooked up a simple test /lib/modules/ directory with a subdirectory and a few small text files. Worked fine.
Tried this on /lib/modules/6.11.5-200.fc40.x86_64/. Some files got listed (file names only) a huge number of times (multiple 40-line screens per file). These are (of course) owned by packages. I noticed kernel-modules-core-6.11.5-200.fc40.x86_64 to be listed an especially large number of times. Why? Can this repetition be prevented?
If a particular kernel was not properly (or maybe cleanly) removed, then there will be an artifact in /lib/modules, and the particular kernel's directory tree will _not_ be empty. A handful of small files is expected. You know about that bug. But a large number of files with megabytes of storage is not expected.
In your case -- a richly populated kernel under /lib/modules -- indicates the kernel was not properly (or maybe cleanly) removed. You should investigate why the dnf remove or rpm erase (or whatever you ran) did not complete successfully. Or, if the package was forcefully removed, then just delete the remaining directory tree in /lib/modules.
Jeff
Weekly patches are done via "dnf --refresh upgrade". Semi-annual upgrades are done via "dnf system-upgrade download --releasever={number]" followed by "dnf system-upgrade reboot". The clean-up of /boot and /lib/modules was done this morning before my late-this-morning post on this thread. I had to use rm and "rm -rf" to do that. Both directories are now nice and clean:
bash.1[~]: ls /boot config-6.11.5-200.fc40.x86_64 memtest86+x64.bin config-6.11.6-200.fc40.x86_64 symvers-6.11.5-200.fc40.x86_64.xz efi symvers-6.11.6-200.fc40.x86_64.xz grub2 System.map-6.11.5-200.fc40.x86_64 initramfs-6.11.5-200.fc40.x86_64.img System.map-6.11.6-200.fc40.x86_64 initramfs-6.11.6-200.fc40.x86_64.img vmlinuz-6.11.5-200.fc40.x86_64 loader vmlinuz-6.11.6-200.fc40.x86_64 lost+found -bash.2[~]: ls /lib/modules 6.11.5-200.fc40.x86_64 6.11.6-200.fc40.x86_64 -bash.3[~]:
On 11/8/24 5:14 PM, home user via users wrote:
On 11/8/24 5:18 PM, Samuel Sieb wrote:
On 11/8/24 10:15 AM, home user via users wrote:
While doing those "rpm -qf" commands, 2 questions came to mind.
- Suppose [dir] has sub-directories. If I do "rpm -qf [dir]/*",
will it also check [dir]'s sub-directories? If no, then 2. How do get the sub-directories checked without having to do them manually one-by-one?
find [dir] -type f -print0 | xargs -0 rpm -qf
I cooked up a simple test /lib/modules/ directory with a subdirectory and a few small text files. Worked fine.
Tried this on /lib/modules/6.11.5-200.fc40.x86_64/. Some files got listed (file names only) a huge number of times (multiple 40-line screens per file). These are (of course) owned by packages. I noticed kernel-modules-core-6.11.5-200.fc40.x86_64 to be listed an especially large number of times. Why? Can this repetition be prevented?
I'm not sure what you mean. Each file should only get listed once. If you see otherwise, please show what you're seeing. Most of the files are going to be owned by "kernel-modules-core" because that's what's there. There will likely be a few that are owned by kernel module subpackages for less common hardware.
What repetition are you wanting to prevent?
On 11/8/24 6:40 PM, Samuel Sieb wrote:
On 11/8/24 5:14 PM, home user via users wrote:
On 11/8/24 5:18 PM, Samuel Sieb wrote:
On 11/8/24 10:15 AM, home user via users wrote:
While doing those "rpm -qf" commands, 2 questions came to mind.
- Suppose [dir] has sub-directories. If I do "rpm -qf [dir]/*", will it also check [dir]'s sub-directories?
If no, then 2. How do get the sub-directories checked without having to do them manually one-by-one?
find [dir] -type f -print0 | xargs -0 rpm -qf
I cooked up a simple test /lib/modules/ directory with a subdirectory and a few small text files. Worked fine.
Tried this on /lib/modules/6.11.5-200.fc40.x86_64/. Some files got listed (file names only) a huge number of times (multiple 40-line screens per file). These are (of course) owned by packages. I noticed kernel-modules-core-6.11.5-200.fc40.x86_64 to be listed an especially large number of times. Why? Can this repetition be prevented?
I'm not sure what you mean. Each file should only get listed once. If you see otherwise, please show what you're seeing. Most of the files are going to be owned by "kernel-modules-core" because that's what's there. There will likely be a few that are owned by kernel module subpackages for less common hardware.
What repetition are you wanting to prevent?
Doing this:
-bash.3[~]: find /lib/modules/6.11.5-200.fc40.x86_64/ -type f -print0 | xargs -0 rpm -qf > findout.txt -bash.4[~]: ls -l findout.txt -rw-r--r--. 1 root root 179205 Nov 8 19:12 findout.txt -bash.5[~]:
and then using "view", the file findout.txt is 4437 lines long. List rules forbid attaching something that big. Shall I send that to you privately?
On 11/8/24 6:19 PM, home user via users wrote:
On 11/8/24 6:40 PM, Samuel Sieb wrote:
On 11/8/24 5:14 PM, home user via users wrote:
Tried this on /lib/modules/6.11.5-200.fc40.x86_64/. Some files got listed (file names only) a huge number of times (multiple 40-line screens per file). These are (of course) owned by packages. I noticed kernel-modules-core-6.11.5-200.fc40.x86_64 to be listed an especially large number of times. Why? Can this repetition be prevented?
I'm not sure what you mean. Each file should only get listed once. If you see otherwise, please show what you're seeing. Most of the files are going to be owned by "kernel-modules-core" because that's what's there. There will likely be a few that are owned by kernel module subpackages for less common hardware.
What repetition are you wanting to prevent?
Doing this:
-bash.3[~]: find /lib/modules/6.11.5-200.fc40.x86_64/ -type f -print0 | xargs -0 rpm -qf > findout.txt -bash.4[~]: ls -l findout.txt -rw-r--r--. 1 root root 179205 Nov 8 19:12 findout.txt -bash.5[~]:
and then using "view", the file findout.txt is 4437 lines long. List rules forbid attaching something that big. Shall I send that to you privately?
"wc -l findout.txt" will give you number of lines.
But that's about the expected number of files there. You're going to get a line for each file. What are you wanting instead?
On 11/8/24 9:06 PM, Samuel Sieb wrote:
On 11/8/24 6:19 PM, home user via users wrote:
On 11/8/24 6:40 PM, Samuel Sieb wrote:
On 11/8/24 5:14 PM, home user via users wrote:
Tried this on /lib/modules/6.11.5-200.fc40.x86_64/. Some files got listed (file names only) a huge number of times (multiple 40-line screens per file). These are (of course) owned by packages. I noticed kernel-modules-core-6.11.5-200.fc40.x86_64 to be listed an especially large number of times. Why? Can this repetition be prevented?
I'm not sure what you mean. Each file should only get listed once. If you see otherwise, please show what you're seeing. Most of the files are going to be owned by "kernel-modules-core" because that's what's there. There will likely be a few that are owned by kernel module subpackages for less common hardware.
What repetition are you wanting to prevent?
Doing this:
-bash.3[~]: find /lib/modules/6.11.5-200.fc40.x86_64/ -type f -print0 | xargs -0 rpm -qf > findout.txt -bash.4[~]: ls -l findout.txt -rw-r--r--. 1 root root 179205 Nov 8 19:12 findout.txt -bash.5[~]:
and then using "view", the file findout.txt is 4437 lines long. List rules forbid attaching something that big. Shall I send that to you privately?
"wc -l findout.txt" will give you number of lines.
But that's about the expected number of files there. You're going to get a line for each file. What are you wanting instead?
hmmm... Maybe some of that snow coming down outside is getting into my brain. Could it be that I'm misunderstanding the output?
I thought that in the case of a file that IS owned by a package, rpm -qf was displaying the name of the owned file. So I was expecting a file name to appear once, not 2000+ times!
It's now occurring to me that in the case of a file that is owned by a package, it's listing the name of the owning package, not the name of the owned file. Am I correct?
On 11/8/24 8:46 PM, home user via users wrote:
I thought that in the case of a file that IS owned by a package, rpm -qf was displaying the name of the owned file. So I was expecting a file name to appear once, not 2000+ times!
It's now occurring to me that in the case of a file that is owned by a package, it's listing the name of the owning package, not the name of the owned file. Am I correct?
That is correct.
And now I see why you're confused. It doesn't show the filename, only the package name, so you'll see an endless list of the package name, with possibly only a few filenames mixed in.
On Fri, 2024-11-08 at 21:53 -0800, Samuel Sieb wrote:
On 11/8/24 8:46 PM, home user via users wrote:
I thought that in the case of a file that IS owned by a package, rpm -qf was displaying the name of the owned file. So I was expecting a file name to appear once, not 2000+ times!
It's now occurring to me that in the case of a file that is owned by a package, it's listing the name of the owning package, not the name of the owned file. Am I correct?
That is correct.
And now I see why you're confused. It doesn't show the filename, only the package name, so you'll see an endless list of the package name, with possibly only a few filenames mixed in.
The OP probably wants to see files that don't belong to an installed package, so an additional filter would be appropriate, e.g.
...|grep "not owned by any package"
poc
On 11/9/24 5:08 AM, Patrick O'Callaghan wrote:
On Fri, 2024-11-08 at 21:53 -0800, Samuel Sieb wrote:
On 11/8/24 8:46 PM, home user via users wrote:
I thought that in the case of a file that IS owned by a package, rpm -qf was displaying the name of the owned file. So I was expecting a file name to appear once, not 2000+ times!
It's now occurring to me that in the case of a file that is owned by a package, it's listing the name of the owning package, not the name of the owned file. Am I correct?
That is correct.
And now I see why you're confused. It doesn't show the filename, only the package name, so you'll see an endless list of the package name, with possibly only a few filenames mixed in.
The OP probably wants to see files that don't belong to an installed package, so an additional filter would be appropriate, e.g.
...|grep "not owned by any package"
poc
Actually, the op (me!) had already figured that out and posted it in a post yesterday. I'm now believing all I really needed was to pipe through a count-only negative filter:
find [dir] -type f -print0 | xargs -0 rpm -qf | grep -cv " not owned "
A result > zero would indicate something in [dir] is owned by some package, so doing rm -rf [dir] is at best risky. A result of zero would indicate nothing in [dir] is owned by any package, so using rm -rf [dir] should be safe.
grep's -c and -v options are 2 more things I used to know and had forgotten. They can be quite useful.
On 11/8/24 10:53 PM, Samuel Sieb wrote:
On 11/8/24 8:46 PM, home user via users wrote:
I thought that in the case of a file that IS owned by a package, rpm -qf was displaying the name of the owned file. So I was expecting a file name to appear once, not 2000+ times!
It's now occurring to me that in the case of a file that is owned by a package, it's listing the name of the owning package, not the name of the owned file. Am I correct?
That is correct.
And now I see why you're confused. It doesn't show the filename, only the package name, so you'll see an endless list of the package name, with possibly only a few filenames mixed in.
ok. Once I've gone through another weekly patch without new problems (next Thursday, I hope), I'll tag this thread solved.
By the way, thank-you for reviving "wc -l" in my mind. A long long time ago, in a galaxy far far away, I knew that command. But it had faded away over the years. Or maybe last month's run of remove-retired-packages removed that from my head, along with removing rkhunter, spectacle, musescore, chkrootkit, probably kde, and more that I haven't yet stumbled onto.
On 11/9/24 3:59 PM, home user via users wrote:
On 11/8/24 10:53 PM, Samuel Sieb wrote:
On 11/8/24 8:46 PM, home user via users wrote:
I thought that in the case of a file that IS owned by a package, rpm -qf was displaying the name of the owned file. So I was expecting a file name to appear once, not 2000+ times!
It's now occurring to me that in the case of a file that is owned by a package, it's listing the name of the owning package, not the name of the owned file. Am I correct?
That is correct.
And now I see why you're confused. It doesn't show the filename, only the package name, so you'll see an endless list of the package name, with possibly only a few filenames mixed in.
ok. Once I've gone through another weekly patch without new problems (next Thursday, I hope), I'll tag this thread solved.
By the way, thank-you for reviving "wc -l" in my mind. A long long time ago, in a galaxy far far away, I knew that command. But it had faded away over the years. Or maybe last month's run of remove-retired-packages removed that from my head, along with removing rkhunter, spectacle, musescore, chkrootkit, probably kde, and more that I haven't yet stumbled onto.
I saw no new problems during/after today's weekly patches. /boot/ and /lib/modules/ look clean. I thank everyone who tried to help. I consider this thread SOLVED.
-
home user -
Jeffrey Walton -
Jonathan Billings -
Patrick O'Callaghan -
Samuel Sieb