Re: imminent /boot problem. [SOLVED (for a while!)]
home user composed on 2024-02-25 21:17 (UTC-0700): > On 2/24/24 11:49 PM, Tim via users wrote: I'm curious how you installed it in the first place, then? >> home user: >>> That was about 11 years ago, so my memory of that is foggy and >>> incomplete. >>> I installed windows-7 first, probably from a CD purchased from a >>> local (near Washington, D.C) store. >>> Then using either a CD burned by a co-worker who was a sys. admin. >>> (most likely), or a CD that came with a thick paperback introductory >>> sys. admin. book, or a CD that I burned from windows, I installed >>> Fedora. It took a few tries. Then one day the installation process >>> just worked (seemingly like magic). That's all that I recall. >> You can run live versions from a disc. Does the computer only have a >> CD drive, or does it have a DVD? CD-only would make it hard. > I have one cd/dvd drive. It's slow and, h, "touchy". I still use it for > some back-ups. Based on what others have said in this thread, I prefer to > not try any re-partitioning or installing. It's too risky for me. CD/DVD drives in desktop PCs made in this century are cheaply made commodities. I've paid as little as $17 for a brand new DVD writer in the past decade. They are typically held in place by 4 or fewer phillips screws, and connected to a data cable and a power cable. Changing one can take as little as about 3 minutes. If the PC is old enough (not terribly likely in a PC that isn't older than 11 years) it could have a PATA rather than an SATA interface. PATA drives have jumpers than need to be appropriately set in order for them to behave as expected, according to the cable type used and the position on a 2" wide 3-connector cable (most cables have 3, none have more, some only have 2). Touchiness and lack of predictability and reliability could be because you have an inappropriately set jumper that takes minimal effort to move. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: imminent /boot problem. [SOLVED (for a while!)]
On 2/25/24 4:52 AM, George N. White III wrote: On Thu, Feb 22, 2024 at 7:39 PM home user mailto:mattis...@comcast.net>> wrote: [...] I wrestled for many days this past fall trying to make a working LiveUSB. Couldn't get it to work. I was able to establish that neither the sticks nor the ports were the problem. When wrestling with this last fall, booting from a LiveUSB sometimes failed, sometimes succeeded. I did not sense any pattern to it. If the boot from a LiveUSB succeeded, the workstation would lock up quite quickly (few minutes) afterwards. I could not sense any pattern to it. By the way, the LiveUSB sticks were made using the "Fedora Media Writer" in Gnome. I find that upgrading Fedora more than a few times leaves you with a system that isn't the same as a fresh install. That can lead to confusion when trying to solve problems. Having a way to boot Fedora from other media can be useful when Fedora has issues. There have been systems configured so they wouldn't boot from USB. If my workstation is so configured, it's not by my knowing, intentional doing. Does yours have space for an extra internal drive? If a friend has a system with a couple USB ports that will boot a Fedora Live USB you could put a drive in a USB case and install Fedora in BIOS mode, then add the drive to your system. -- George N. White III For multiple reasons (some private), this is not an option for me. -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: imminent /boot problem. [SOLVED (for a while!)]
On 2/24/24 11:49 PM, Tim via users wrote: Tim: I'm curious how you installed it in the first place, then? home user: That was about 11 years ago, so my memory of that is foggy and incomplete. I installed windows-7 first, probably from a CD purchased from a local (near Washington, D.C) store. Then using either a CD burned by a co-worker who was a sys. admin. (most likely), or a CD that came with a thick paperback introductory sys. admin. book, or a CD that I burned from windows, I installed Fedora. It took a few tries. Then one day the installation process just worked (seemingly like magic). That's all that I recall. You can run live versions from a disc. Does the computer only have a CD drive, or does it have a DVD? CD-only would make it hard. I have one cd/dvd drive. It's slow and, h, "touchy". I still use it for some back-ups. Based on what others have said in this thread, I prefer to not try any re-partitioning or installing. It's too risky for me. -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: imminent /boot problem. [SOLVED (for a while!)]
On 2/22/24 11:21 AM, home user wrote: (f-38; gnome) Good morning, While doing my weekly "dnf upgrade" a little while ago, I got the following pop-up at the top of the screen" -- Low Disk Space on"boot" The volume "boot" has only 20.9 MB disk space remaining. Examine Ignore -- Seeing that a new kernel needs... over 74,000,000 (initrams*) over 14,700,000 (vmlinuz*) over 8,800,000 (System.map*) over 200,000 (config*) = over 97,700,000 total, I suspect that the next time I do weekly patches (next Thursday), it will fail. I'm only keeping 2 old kernels now. I did not do anything to shrink /boot. What has grown so much recently? What do I delete? Here's what's in /boot: - -bash.2[~]: ls -alS /boot total 414860 -rw---. 1 root root 116291735 Jun 1 2023 initramfs-0-rescue-70857e3fb05849139515e66a3fdc6b38.img -rw---. 1 root root 74107910 Feb 8 12:15 initramfs-6.7.3-100.fc38.x86_64.img -rw---. 1 root root 74063151 Feb 22 10:15 initramfs-6.7.5-100.fc38.x86_64.img -rw---. 1 root root 74060383 Feb 15 13:15 initramfs-6.7.4-100.fc38.x86_64.img -rwxr-xr-x. 1 root root 14806856 Feb 4 17:00 vmlinuz-6.7.4-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14786376 Jan 30 17:00 vmlinuz-6.7.3-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14786376 Feb 16 17:00 vmlinuz-6.7.5-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14329896 Jun 1 2023 vmlinuz-0-rescue-70857e3fb05849139515e66a3fdc6b38 -rw-r--r--. 1 root root 8851363 Feb 16 17:00 System.map-6.7.5-100.fc38.x86_64 -rw-r--r--. 1 root root 8850577 Feb 4 17:00 System.map-6.7.4-100.fc38.x86_64 -rw-r--r--. 1 root root 8849769 Jan 30 17:00 System.map-6.7.3-100.fc38.x86_64 -rw-r--r--. 1 root root 269368 Jan 30 17:00 config-6.7.3-100.fc38.x86_64 -rw-r--r--. 1 root root 269338 Feb 16 17:00 config-6.7.5-100.fc38.x86_64 -rw-r--r--. 1 root root 269327 Feb 4 17:00 config-6.7.4-100.fc38.x86_64 -rw-r--r--. 1 root root 147744 Jan 6 17:00 memtest86+x64.bin drwx--. 2 root root 12288 Mar 17 2013 lost+found dr-xr-xr-x. 6 root root 5120 Feb 22 10:15 . dr-xr-xr-x. 22 root root 4096 Oct 5 14:40 .. drwx--. 3 root root 1024 Jan 18 2023 efi drwx--. 6 root root 1024 Feb 22 10:55 grub2 drwxr-xr-x. 3 root root 1024 Oct 11 2018 loader -rw-r--r--. 1 root root 161 Nov 1 18:00 .vmlinuz-6.5.10-200.fc38.x86_64.hmac -rw-r--r--. 1 root root 160 Oct 19 18:00 .vmlinuz-6.5.8-200.fc38.x86_64.hmac -rw-r--r--. 1 root root 160 Jan 30 17:00 .vmlinuz-6.7.3-100.fc38.x86_64.hmac -rw-r--r--. 1 root root 160 Feb 4 17:00 .vmlinuz-6.7.4-100.fc38.x86_64.hmac -rw-r--r--. 1 root root 160 Feb 16 17:00 .vmlinuz-6.7.5-100.fc38.x86_64.hmac lrwxrwxrwx. 1 root root 45 Feb 8 12:15 symvers-6.7.3-100.fc38.x86_64.xz -> /lib/modules/6.7.3-100.fc38.x86_64/symvers.xz lrwxrwxrwx. 1 root root 45 Feb 15 13:15 symvers-6.7.4-100.fc38.x86_64.xz -> /lib/modules/6.7.4-100.fc38.x86_64/symvers.xz lrwxrwxrwx. 1 root root 45 Feb 22 10:15 symvers-6.7.5-100.fc38.x86_64.xz -> /lib/modules/6.7.5-100.fc38.x86_64/symvers.xz -bash.3[~]: - Thank-you in advance. With the removal of the oldest kernel and the space recovered by doing that, and with the changing the dnf configuration file so only one old kernel is kept in the future, I should have enough space for weekly patches for a while. (well, until the kernel grows too much more) I gonna go ahead and consider this issue SOLVED. I thank everyone who tried to help. -- ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: follow-up - Re: /boot problem. [SOLVED]
On 6/2/23 10:27 AM, stan via users wrote: On Fri, 2 Jun 2023 07:03:52 -0400 Go Canes wrote: On Fri, Jun 2, 2023 at 12:21 AM home user wrote: One more kernel update is needed to make sure the weekly patches does not keep too many kernels, and that the rescue kernel is updated. I don't believe the rescue kernel gets updated automatically. This is correct. It only gets updated automatically with the install of a new kernel if the old vmlinuz-0-rescue* and initramfs-0-rescue* are deleted manually before the install. It can be created manually with the following command (for the currently running kernel), also after manually deleting the two files above. I haven't checked, but probably best to run while in /boot. /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" /lib/modules/$(uname -r)/vmlinuz I sit corrected. I will try to keep those helps in mind. Thank-you Stan and "Go Canes". ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: follow-up - Re: /boot problem. [SOLVED]
On Fri, 2 Jun 2023 07:03:52 -0400 Go Canes wrote: > On Fri, Jun 2, 2023 at 12:21 AM home user > wrote: > > One more kernel update is needed to make sure the weekly patches > > does not keep too many kernels, and that the rescue kernel is > > updated. > > I don't believe the rescue kernel gets updated automatically. This is correct. It only gets updated automatically with the install of a new kernel if the old vmlinuz-0-rescue* and initramfs-0-rescue* are deleted manually before the install. It can be created manually with the following command (for the currently running kernel), also after manually deleting the two files above. I haven't checked, but probably best to run while in /boot. /usr/lib/kernel/install.d/51-dracut-rescue.install add $(uname -r) "" /lib/modules/$(uname -r)/vmlinuz ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: follow-up - Re: /boot problem. [SOLVED]
On Fri, Jun 2, 2023 at 12:21 AM home user wrote: > One more kernel update is needed to make sure the weekly patches does not > keep too many kernels, and that the rescue kernel is updated. I don't believe the rescue kernel gets updated automatically. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
follow-up - Re: /boot problem. [SOLVED]
On 5/18/23 4:21 PM, home user wrote: (f37 stand-alone dual-boot workstation) During this afternoon's patching (via dnf), a warning GUI popped up saying /boot is full. It offered me the option to move /boot files to trash, but no option to delete anything. I tried moving the rescue file to trash, but the GUI said it couldn't. After the dnf patching finished, I removed the rescue file via the rm command. But when I rebooted, the rescue option was still in the grub menu. 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? Please tell me what specific information you need to help me so I can provide it. thanks, Bill. I did my weekly patches this morning. It was the cleanest I've experienced in a few weeks. * the grub menu now includes a current rescue kernel. * there are now 3 regular kernels in the grub menu. * /boot is 69% used; I saw nothing in it that didn't belong (was too old). * no more akmods-shutdown.service during shutdown. One more kernel update is needed to make sure the weekly patches does not keep too many kernels, and that the rescue kernel is updated. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot problem. [SOLVED]
On Tue, 2023-05-23 at 18:08 +0930, Tim via users wrote: > Although re-installing something is rarely the solution. It really > only makes sense if you know you've lost some of the packages files. Which you can check using 'rpm -V ' poc ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot problem. [SOLVED]
On Mon, 2023-05-22 at 15:04 -0600, home user wrote: > The only ways an "upgrade over the top" should happen is if there's > something wrong in dnf or the kernels undergo serious growth. At > least I now know one thing to look for if this does happen. Actually, what I was referring to was when you do something upgrade to Fedora 38 over the top of Fedora-something-older. As opposed to a clean install on an empty drive. If you do install the same package twice on your existing system, because you thought something went awry, dnf should handle that fine. Although re-installing something is rarely the solution. It really only makes sense if you know you've lost some of the packages files. -- uname -rsvp Linux 3.10.0-1160.90.1.el7.x86_64 #1 SMP Thu May 4 15:21:22 UTC 2023 x86_64 Boilerplate: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the mailing list. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot problem. [SOLVED]
On 5/22/23 2:49 PM, Tim via users wrote: Tom Horsley: I don't know if it already appeared somewhere in this thread, but I think there is a DNF option you can set in the dnf.conf file to limit the number of old kernels it will keep around. That might help prevent a recurrence. home user: Yes, I set that back to 3 during this thread. Just remember that's only keeping track of the number of kernels installed by it. If you have left-overs from prior installs, as you did, they're not under its management and won't be part of the count. So, if you do an upgrade over the top in the future, you may have to manually deal with older kernels again. As a part of this thread's activities, older kernels have been cleaned out. That is, unless something is hiding from "ls" and other common Linux commands! I've never patched or upgraded other than via "yum" (in the earlier years) and "dnf upgrade" and "dnf system-upgrade" in more recent years. I have a strong sense that something, I don't know what, went seriously wrong with those dnf commands in the past 3 weekly patches. I opened threads in all 3 cases. Only the last one got real attention. The only ways an "upgrade over the top" should happen is if there's something wrong in dnf or the kernels undergo serious growth. At least I now know one thing to look for if this does happen. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot problem. [SOLVED]
Tom Horsley: >> I don't know if it already appeared somewhere in this thread, but I >> think there is a DNF option you can set in the dnf.conf file to >> limit the number of old kernels it will keep around. That might >> help prevent a recurrence. home user: > Yes, I set that back to 3 during this thread. Just remember that's only keeping track of the number of kernels installed by it. If you have left-overs from prior installs, as you did, they're not under its management and won't be part of the count. So, if you do an upgrade over the top in the future, you may have to manually deal with older kernels again. -- NB: All unexpected mail to my mailbox is automatically deleted. I will only get to see the messages that are posted to the list. The following system info data is generated fresh for each post: uname -rsvp Linux 6.2.15-100.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Thu May 11 16:51:53 UTC 2023 x86_64 ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot problem. [SOLVED]
On 5/22/23 12:17 PM, Tom Horsley wrote: On Mon, 22 May 2023 12:02:19 -0600 home user wrote: If the problem happens again, I'll open a new thread. I don't know if it already appeared somewhere in this thread, but I think there is a DNF option you can set in the dnf.conf file to limit the number of old kernels it will keep around. That might help prevent a recurrence. Yes, I set that back to 3 during this thread. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot problem. [SOLVED]
On Mon, 22 May 2023 12:02:19 -0600 home user wrote: > If the problem happens again, I'll open a new thread. I don't know if it already appeared somewhere in this thread, but I think there is a DNF option you can set in the dnf.conf file to limit the number of old kernels it will keep around. That might help prevent a recurrence. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: /boot problem. [SOLVED]
On 5/18/23 4:21 PM, home user wrote: (f37 stand-alone dual-boot workstation) During this afternoon's patching (via dnf), a warning GUI popped up saying /boot is full. It offered me the option to move /boot files to trash, but no option to delete anything. I tried moving the rescue file to trash, but the GUI said it couldn't. After the dnf patching finished, I removed the rescue file via the rm command. But when I rebooted, the rescue option was still in the grub menu. 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? Please tell me what specific information you need to help me so I can provide it. thanks, Bill. My /boot went from Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 485348 379984 75668 84% /boot to /dev/sda3 485348 130396325256 29% /boot The output from du -m for /boot dropped from 20 entries, total of 317 to: -bash.3[boot]: du -m 1 ./lost+found 3 ./grub2/fonts 1 ./grub2/themes/system 3 ./grub2/themes/starfield 3 ./grub2/themes 3 ./grub2/i386-pc 5 ./grub2/locale 12 ./grub2 6 ./efi/EFI/fedora 1 ./efi/EFI/BOOT 7 ./efi/EFI 7 ./efi 1 ./loader/entries 1 ./loader 128 . -bash.4[boot]: Great improvement! I'm marking this thread [SOLVED]. If the problem happens again, I'll open a new thread. I thank everyone who tried to help. ___ users mailing list -- users@lists.fedoraproject.org To unsubscribe send an email to users-le...@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
