Re: /boot problem.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 5/18/23 5:53 PM, Lukas Middendorf wrote:
On 19/05/2023 00:21, home user wrote:
[... snip ...]
The actual grub menu entry is caused by a file in /boot/loader/entries . If you manually remove the rescue files (initramfs and vmlinuz) but leave the file in /boot/loader/entries in place, you will still have the entry in the grub menu but it will not work.
The rescue kernel should automatically be regenerated on the next kernel update. To prevent that from happening, you also have to remove the package dracut-config-rescue.

Actually, I prefer having the rescue kernel.  I really did not want to delete the file that I deleted.  But I believed I had to do something, and deleting that file seemed like the best choice.  I hope that the rescue kernel will be properly re-created when I do the weekly patches next Thursday.  So am I correct in believing that I should leave dracut-config-rescue there?  Also, I only deleted one file this afternoon, probably the initramfs....  I see "vmlinuz-0-rescue-70857e3fb05849139515e66a3fdc6b38" in /boot now, but no initramfs file with "rescue" in the name.  Should I leave the vmlinuz... there?


 > I'm comfortable using rm in regular hard drive areas like /home.  But
 > I'm neither a trained nor a professional sys.admin.  I'm seriously
 > uneasy about simply rm-ing files in /boot.  What should I clear out of
 > /boot, and what's the best-practice way?

The only other "safe" way I can think of to significantly clear up space on /boot (unless you have some unusual files in there) is to uninstall old kernels. By default three kernel versions are kept at the same time, but this could be reduced to two by setting "installonly_limit=2" in /etc/dnf/dnf.conf
If you want an immediate result but not only on the next kernel update, you likely have to remove the rpm packages of the oldest kernel manually.

Late last year, I raised that limit from 3 to 4 as advised by this list.  I just dropped it back down to 3.
What's the correct, best-practice way to remove the oldest kernel?  ...or can that now wait until next Thursday's weekly patches, and "dnf upgrade" will do all the clean-up for me automatically?

Thanks,
Bill.
_______________________________________________
users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/users@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue



[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [EPEL Devel]     [Fedora Magazine]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Desktop]     [Fedora Fonts]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Fedora Sparc]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux