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 belie
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
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.
_
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 tr
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 mailin
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
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,
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
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 numbe
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
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 tr
On 5/22/23 8:38 AM, stan via users wrote:
On Sun, 21 May 2023 19:28:14 +0200
Lukas Middendorf wrote:
Thanks for comments.
[... snip ...]
There is quite some potential for mistakes that will break the boot
process.
Yes, there sure is. Given this new addition, I would not recommend
this unles
On 5/22/23 8:01 AM, stan via users wrote:
On Sun, 21 May 2023 21:02:19 -0600
home user wrote:
question does come to mind from my first reading: What you say about
using CDs will work with DVDs too, right?
Yes, I actually have a dvd burner that can handle CDs as well. Make
sure that you tick
On 5/21/23 11:56 PM, Samuel Sieb wrote:
On 5/21/23 20:02, home user wrote:
I notice that the themes/starfield subdirectory has quite a few (31) files, all
from July 06, 2017, a few quite big. But should not assume that being old
means they're no longer needed.
My question: Is anything in this
On 5/21/23 10:20 PM, Mike Wright wrote:
On 5/21/23 20:02, home user wrote:
On 5/18/23 4:21 PM, home user wrote:
[... snip ...]
There are two more /boot subdirectories I want to look at:
/boot/grub2/i386-pc/
/boot/grub2/themes/starfield/
I did an "ls -lRt" on /boot/grub2/ and put the output (a
On Sun, 21 May 2023 19:28:14 +0200
Lukas Middendorf wrote:
Thanks for comments.
> On 21/05/2023 18:05, stan via users wrote:
> > 1. Caveat: This is a complex procedure, and from your past posts of
> > your skill level, maybe too risky for you to do.
> > There is lots of room in / for /boot. Rig
On Sun, 21 May 2023 21:02:19 -0600
home user wrote:
> question does come to mind from my first reading: What you say about
> using CDs will work with DVDs too, right?
Yes, I actually have a dvd burner that can handle CDs as well. Make
sure that you tick the box that validates the burn after it
On 5/21/23 20:02, home user wrote:
I notice that the themes/starfield subdirectory has quite a few (31)
files, all from July 06, 2017, a few quite big. But should not assume
that being old means they're no longer needed.
My question: Is anything in this directory still needed. I'd like to
eit
On 5/21/23 20:02, home user wrote:
On 5/18/23 4:21 PM, home user wrote:
[... snip ...]
There are two more /boot subdirectories I want to look at:
/boot/grub2/i386-pc/
/boot/grub2/themes/starfield/
I did an "ls -lRt" on /boot/grub2/ and put the output (as a text file)
onto the google drive her
On 5/18/23 4:21 PM, home user wrote:
[... snip ...]
There are two more /boot subdirectories I want to look at:
/boot/grub2/i386-pc/
/boot/grub2/themes/starfield/
I did an "ls -lRt" on /boot/grub2/ and put the output (as a text file) onto the
google drive here:
"https://drive.google.com/file/d/
On 21/05/2023 18:05, stan via users wrote:
1. Caveat: This is a complex procedure, and from your past posts of
your skill level, maybe too risky for you to do.
There is lots of room in / for /boot. Right now you are using a
separate /boot, but there is a way to use a /boot under the
root partiti
Ignore this post if you are happy with the current resolution to your
issue.
On Sat, 20 May 2023 18:17:56 -0600
home user wrote:
> On 5/20/23 3:03 PM, Patrick O'Callaghan wrote:
> > On Sun, 2023-05-21 at 04:12 +0930, Tim via users wrote:
> >> On Sat, 2023-05-20 at 17:07 +0100, Patrick O'Callag
On 5/19/23 5:46 AM, Jeffrey Walton wrote:
On Thu, May 18, 2023 at 9:29 PM home user wrote:
[...]
-
bash.7[~]: df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs40960 4096 0% /dev
tmpfs81540120 8154012 0% /dev/shm
tmpfs
On 5/20/23 8:48 PM, Samuel Sieb wrote:
On 5/20/23 19:36, home user wrote:
On 5/18/23 4:21 PM, home user wrote:
(f37 stand-alone dual-boot workstation)
(not replying to anyone else's post)
-
-bash.12[boot]: ls -a
. symvers-6.2.10-200.fc37.x86_64.gz
..
On 5/19/23 4:40 AM, Lukas Middendorf wrote:
On 19/05/2023 03:24, home user wrote:
On 5/18/23 6:30 PM, Felix Miata wrote:
I have not seen initrd-plymouth.img and {initramfs,vmlinuz}-fedup previously,
but I guess they are leftovers from some earlier system upgrade. I don't think
they are neede
On 5/20/23 19:36, home user wrote:
On 5/18/23 4:21 PM, home user wrote:
(f37 stand-alone dual-boot workstation)
(not replying to anyone else's post)
-
-bash.12[boot]: ls -a
. symvers-6.2.10-200.fc37.x86_64.gz
.. symvers
On 5/18/23 4:21 PM, home user wrote:
(f37 stand-alone dual-boot workstation)
(not replying to anyone else's post)
-
-bash.12[boot]: ls -a
. symvers-6.2.10-200.fc37.x86_64.gz
..symvers-6.2.12-200.fc37.x86_64.gz
config-6.
On 5/20/23 19:09, home user wrote:
On 5/20/23 7:54 PM, home user wrote:
On 5/20/23 7:51 PM, Samuel Sieb wrote:
On 5/20/23 18:44, home user wrote:
From what I see in the Fedora doc, is this my next step:
"grub2-mkconfig -o /boot/grub2/grub.cfg"?
If no, what? ...or is grub menu clean-up done?
On 5/18/23 6:30 PM, Felix Miata wrote:
home user composed on 2023-05-18 16:21 (UTC-0600):
What size is the filesystem on which /boot/ lives? Separate partition? BTRFS?
I don't recall answering this.
size = 485348
separate partition: yes (based on Disks display)
BTRFS: no; it's Ext4.
On 5/20/23 7:54 PM, home user wrote:
On 5/20/23 7:51 PM, Samuel Sieb wrote:
On 5/20/23 18:44, home user wrote:
From what I see in the Fedora doc, is this my next step:
"grub2-mkconfig -o /boot/grub2/grub.cfg"?
If no, what? ...or is grub menu clean-up done?
That is how to do it, but unless
Sorry I should write 'sudo dnf reinstall kernel kernel-*'
On Sat, 2023-05-20 at 19:53 -0600, home user wrote:
> On 5/20/23 7:25 PM, Igor Bezrodnik wrote:
> > Can you try to do just reinstall kernel like 'sudo dnf kernel
> > kernel-*'
>
> ?
> I looked at the man page for dnf. There is no "kernel"
On 5/20/23 7:51 PM, Samuel Sieb wrote:
On 5/20/23 18:44, home user wrote:
From what I see in the Fedora doc, is this my next step:
"grub2-mkconfig -o /boot/grub2/grub.cfg"?
If no, what? ...or is grub menu clean-up done?
That is how to do it, but unless there's still something in the menu yo
On 5/20/23 7:25 PM, Igor Bezrodnik wrote:
Can you try to do just reinstall kernel like 'sudo dnf kernel kernel-*'
?
I looked at the man page for dnf. There is no "kernel" command for dnf.
[... snip ...]
___
users mailing list -- users@lists.fedorapr
On 5/20/23 18:44, home user wrote:
From what I see in the Fedora doc, is this my next step:
"grub2-mkconfig -o /boot/grub2/grub.cfg"?
If no, what? ...or is grub menu clean-up done?
That is how to do it, but unless there's still something in the menu you
don't want, you're done.
___
On 5/20/23 7:32 PM, Samuel Sieb wrote:
On 5/20/23 18:17, home user wrote:
On 5/20/23 7:07 PM, Samuel Sieb wrote:
On 5/20/23 18:01, home user wrote:
On 5/20/23 6:53 PM, Samuel Sieb wrote:
On 5/20/23 17:17, home user wrote:
[... snip ...]
How do I get the grub menu corrected?
Assuming the
On 5/20/23 18:17, home user wrote:
On 5/20/23 7:07 PM, Samuel Sieb wrote:
On 5/20/23 18:01, home user wrote:
On 5/20/23 6:53 PM, Samuel Sieb wrote:
On 5/20/23 17:17, home user wrote:
[... snip ...]
How do I get the grub menu corrected?
Assuming the BLS conversion happened, look in /boot/
On Sun, 2023-05-21 at 11:25 +1000, Igor Bezrodnik wrote:
> Can you try to do just reinstall kernel like 'sudo dnf install kernel
> kernel-*'
> On Sat, 2023-05-20 at 19:17 -0600, home user wrote:
> > On 5/20/23 7:07 PM, Samuel Sieb wrote:
> > > On 5/20/23 18:01, home user wrote:
> > > > On 5/20/23 6
Can you try to do just reinstall kernel like 'sudo dnf kernel kernel-*'
On Sat, 2023-05-20 at 19:17 -0600, home user wrote:
> On 5/20/23 7:07 PM, Samuel Sieb wrote:
> > On 5/20/23 18:01, home user wrote:
> > > On 5/20/23 6:53 PM, Samuel Sieb wrote:
> > > > On 5/20/23 17:17, home user wrote:
> [...
On 5/20/23 7:07 PM, Samuel Sieb wrote:
On 5/20/23 18:01, home user wrote:
On 5/20/23 6:53 PM, Samuel Sieb wrote:
On 5/20/23 17:17, home user wrote:
[... snip ...]
How do I get the grub menu corrected?
Assuming the BLS conversion happened, look in /boot/loader/entries/ and remove
any entr
On 5/20/23 18:01, home user wrote:
On 5/20/23 6:53 PM, Samuel Sieb wrote:
On 5/20/23 17:17, home user wrote:
I am seriously considering enlarging /boot. But I anticipate that
would take even more help from this list than this current problem.
So we're back to where this left off
You do
On 5/20/23 6:53 PM, Samuel Sieb wrote:
On 5/20/23 17:17, home user wrote:
I am seriously considering enlarging /boot. But I anticipate that would take
even more help from this list than this current problem. So we're back to
where this left off
You don't want to be messing around with
On 5/20/23 17:17, home user wrote:
I am seriously considering enlarging /boot. But I anticipate that would
take even more help from this list than this current problem. So we're
back to where this left off
You don't want to be messing around with changing partition sizes if you
don't ha
On 5/20/23 3:03 PM, Patrick O'Callaghan wrote:
On Sun, 2023-05-21 at 04:12 +0930, Tim via users wrote:
On Sat, 2023-05-20 at 17:07 +0100, Patrick O'Callaghan wrote:
Apologies if you've already considered this, but I wonder why you
don't
just do a fresh install of F38 (or F37). It would have bee
On Sun, 2023-05-21 at 04:12 +0930, Tim via users wrote:
> On Sat, 2023-05-20 at 17:07 +0100, Patrick O'Callaghan wrote:
> > Apologies if you've already considered this, but I wonder why you
> > don't
> > just do a fresh install of F38 (or F37). It would have been much
> > quicker than all the futzi
On Sat, 2023-05-20 at 17:07 +0100, Patrick O'Callaghan wrote:
> Apologies if you've already considered this, but I wonder why you don't
> just do a fresh install of F38 (or F37). It would have been much
> quicker than all the futzing around you've had to do, and you could
> have seized the opportun
On Sat, 2023-05-20 at 09:16 -0600, home user wrote:
> So as was pointed out by more than one poster, some grub clean-up is
> needed. How do I do that?
Apologies if you've already considered this, but I wonder why you don't
just do a fresh install of F38 (or F37). It would have been much
quicker t
Last night, when I shut down the workstation for the night, it took quite a
while (minutes); it was running akmod. I had done no installs and no upgrades
since the previous boot (earlier in the day). I had only done dnf removes and
rm commands. Why was akmod run during that shutdown?!
On 5/
>
> That brings the du -m down from 317 to 294.
>
> I've noticed a bunch of "hidden" files in /boot. Here's an ls -lrta output
> for /boot
> -
> -bash.38[boot]: ls -lrta
> total 281371
> drwx--. 2 root root12288 Mar 17 2013 lost+found
> -rw-r--r--. 1 root root 5897400 May 21 20
On Fri, May 19, 2023 at 3:05 PM home user wrote:
> bash.1[~]: rpm -q kernel
> kernel-6.2.14-200.fc37.x86_64
> kernel-6.2.15-200.fc37.x86_64
> bash.2[~]:
> --
> The grub menu no longer shows 6.2.9. It still shows 6.2.10.
> The grub menu shows a 6.2.12, but the rpm -q does not.
Basically,
(responding to 3 posts by Barry)
On 5/19/23 2:55 PM, Barry Scott wrote:
[... snip ...]
317 - that is very big.
What is that 317M consistening of?
Try this command to see what is going on:
du -sh /boot/*
And you do not need /boot/grub you are using /boot/grub2 now not /boot/grub.
Barry
> On 19 May 2023, at 20:22, home user wrote:
>
> On 5/19/23 12:16 PM, George N. White III wrote:
>> Have you checked for excessive space used in sub-directories of /boot? Here:
>> % doas du -sm /boot/efi /boot/extlinux /boot/loader /boot/lost+found
>> /boot/grub2
>> 19 /boot/efi
>> 2 /boot/ex
On 5/19/23 12:16 PM, George N. White III wrote:
Have you checked for excessive space used in sub-directories of /boot? Here:
% doas du -sm /boot/efi /boot/extlinux /boot/loader /boot/lost+found /boot/grub2
19 /boot/efi
2 /boot/extlinux
1 /boot/loader
1 /boot/lost+found
3 /boot/grub2
doas?
no
On 5/19/23 12:30, Go Canes wrote:
On Fri, May 19, 2023 at 1:58 PM home user wrote:
bash.2[~]: rpm -q kernel
kernel-6.2.8-100.fc36.x86_64
kernel-6.2.9-200.fc37.x86_64
kernel-6.2.14-200.fc37.x86_64
kernel-6.2.15-200.fc37.x86_64
bash.3[~]:
--
bash.5[~]: dnf remove kernel-core-6.2.9-100.fc3
On Fri, May 19, 2023 at 1:58 PM home user wrote:
> bash.2[~]: rpm -q kernel
> kernel-6.2.8-100.fc36.x86_64
> kernel-6.2.9-200.fc37.x86_64
> kernel-6.2.14-200.fc37.x86_64
> kernel-6.2.15-200.fc37.x86_64
> bash.3[~]:
> --
> bash.5[~]: dnf remove kernel-core-6.2.9-100.fc36.x86_64
> No match f
Have you checked for excessive space used in sub-directories of /boot?
Here:
% doas du -sm /boot/efi /boot/extlinux /boot/loader /boot/lost+found
/boot/grub2
19 /boot/efi
2 /boot/extlinux
1 /boot/loader
1 /boot/lost+found
3 /boot/grub2
--
George N. White III
_
On 5/18/23 22:03, Samuel Sieb wrote:
On 5/18/23 20:36, Tim via users wrote:
On Thu, 2023-05-18 at 20:15 -0600, home user wrote:
What's the correct, best-practice way to remove the oldest kernel?
To remove a kernel, make sure that you're not currently using it. Then
it's simply rpm --erase or
> On 19 May 2023, at 14:13, Patrick O'Callaghan wrote:
>
> On Fri, 2023-05-19 at 14:03 +0100, Barry Scott wrote:
>> For comparison here is the sizes of /boot and the folders inside it
>> on my file server.
>>
>> $ du -sh /boot/*
>> 252K/boot/config-6.2.11-300.fc38.x86_64
>> 252K/boot/c
On Fri, 2023-05-19 at 14:03 +0100, Barry Scott wrote:
> For comparison here is the sizes of /boot and the folders inside it
> on my file server.
>
> $ du -sh /boot/*
> 252K/boot/config-6.2.11-300.fc38.x86_64
> 252K/boot/config-6.2.13-300.fc38.x86_64
> 252K/boot/config-6.2.14-300.fc38.x
For comparison here is the sizes of /boot and the folders inside it on my file
server.
$ du -sh /boot/*
252K/boot/config-6.2.11-300.fc38.x86_64
252K/boot/config-6.2.13-300.fc38.x86_64
252K/boot/config-6.2.14-300.fc38.x86_64
7.1M/boot/efi
2.4M/boot/grub2
80M /boot/initramfs
On Thu, May 18, 2023 at 9:29 PM home user wrote:
> [...]
> -
> bash.7[~]: df
> Filesystem 1K-blocks Used Available Use% Mounted on
> devtmpfs40960 4096 0% /dev
> tmpfs81540120 8154012 0% /dev/shm
> tmpfs3261608 1696 3
On 19/05/2023 03:24, home user wrote:
On 5/18/23 6:30 PM, Felix Miata wrote:
I put the output of "tree /boot" on the google drive here:
"https://drive.google.com/file/d/1MlfEduVC62KVLnnBJMXbmUd0_zkhDnHF/view?usp=sharing";.
I do not know what does not belong.
I have not seen initrd-plymouth.img
> On 19 May 2023, at 02:29, home user wrote:
>
> On 5/18/23 6:30 PM, Felix Miata wrote:
>> home user composed on 2023-05-18 16:21 (UTC-0600):
> [... snip ...]
>
> Added information:
> This workstation is 10 years old; Fedora was installed on it in spring 2013.
>
>> How many kernels are insta
On 5/18/23 20:36, Tim via users wrote:
On Thu, 2023-05-18 at 20:15 -0600, home user wrote:
What's the correct, best-practice way to remove the oldest kernel?
To remove a kernel, make sure that you're not currently using it. Then
it's simply rpm --erase or dnf erase kernel-(with the full versi
On Thu, 2023-05-18 at 20:15 -0600, home user wrote:
> What's the correct, best-practice way to remove the oldest kernel?
To remove a kernel, make sure that you're not currently using it. Then
it's simply rpm --erase or dnf erase kernel-(with the full version
numbers).
On my system these are inst
On Thu, 2023-05-18 at 20:25 -0600, home user wrote:
> The boot partition has been big enough for over 10 years, including
> the time I've had 4 kernels + 1 rescue kernel (since late last
> year). I'm puzzled about how the /boot partition is now too small.
> Has the kernel grown significantly?
No
On 5/18/23 7:24 PM, home user wrote:
On 5/18/23 6:30 PM, Felix Miata wrote:
home user composed on 2023-05-18 16:21 (UTC-0600):
[... snip ...]
I vaguely recall late last year being advised by this list to expand this from
3 to 4 or 5. I did that, to 4, but I don't remember how.
Q1: How do I
On 5/18/23 6:17 PM, Tim via users wrote:
Bill:
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.
If I might make a suggestion: You might want a larger boot partiti
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 wi
On 5/18/23 6:30 PM, Felix Miata wrote:
home user composed on 2023-05-18 16:21 (UTC-0600):
[... snip ...]
Added information:
This workstation is 10 years old; Fedora was installed on it in spring 2013.
How many kernels are installed, more than two? If yes, uninstall the oldest.
4 kernels.
I
home user composed on 2023-05-18 16:21 (UTC-0600):
> (f37 stand-alone dual-boot workstation)
> During this afternoon's patching (via dnf), a warning GUI popped up saying
> /boot is full. ...
> I'm comfortable using rm in regular hard drive areas like /home. But I'm
> neither a trained nor a p
Bill:
> 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.
If I might make a suggestion: You might want a larger boot partition.
If you're not lacking space in ot
On 19/05/2023 00:21, home user wrote:
> During this afternoon's patching (via dnf), a warning GUI popped up
> saying /boot is full. [...] 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.
The act
72 matches
Mail list logo
