12:21 p.m.
(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.
1:32 p.m.
On 2/22/24 10:21, 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
rm *6.7.3* would open up a lot and you'd still have 2 kernel versions
2:01 p.m.
On Thu, Feb 22, 2024 at 2:33 PM Mike Wright <nobody(a)nospam.hostisimo.com> wrote:
On 2/22/24 10:21, 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
rm *6.7.3* would open up a lot and you'd still have 2 kernel versions
Yeah, it looks closer to 5 old kernels.
#!/usr/bin/env bash
mapfile -t old_kernels < <(dnf repoquery --installonly --latest-limit=-2 -q)
if [ "${#old_kernels[@]}" -eq 0 ]; then
echo "No old kernels found"
clean_lib_modules
exit 0
fi
if ! dnf -y remove "${old_kernels[@]}"; then
echo "Failed to remove old kernels"
exit 1
fi
# Force generation of new rescue kernel
# https://discussion.fedoraproject.org/t/update-rescue-image
# https://discussion.fedoraproject.org/t/questions-about-rescue-kernel
# https://www.mail-archive.com/users@lists.fedoraproject.org/msg159032.html
# https://www.reddit.com/r/Fedora/comments/wfr5hu/about_the_rescue_mode_on_...
echo "Generating new Rescue kernel"
rm -f /boot/*rescue*
kernel-install add "$(uname -r)" "/lib/modules/$(uname
-r)/vmlinuz"
Jeff
5:30 p.m.
On 2/22/24 1:01 PM, Jeffrey Walton wrote:
On Thu, Feb 22, 2024 at 2:33 PM Mike Wright
<nobody(a)nospam.hostisimo.com> wrote:
>
> On 2/22/24 10:21, 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?
[... snip ...]
Yeah, it looks closer to 5 old kernels.
[... snip ...]
I don't understand. Excluding the rescue kernel, there's only the current kernel
and the 2 most recent kernels. And the "pieces" of the kernels appear to all
match correctly (judging from the version numbers).
Is my only real choice to cut back from 2 old kernels to 1 old kernel?
5:46 p.m.
home user composed on 2024-02-22 16:30 (UTC-0700):
Is my only real choice to cut back from 2 old kernels to 1 old
kernel?
Maybe not. Most people don't need to run more than one kernel at a time, or retain
more than one as emergency fallback.
Does your overall configuration necessitate having boot on its own partition? If
not, and you have plenty of freespace on /, you could remount your /boot/
filesystem elsewhere, remove that filesystem from fstab, copy old filesystem
content to the now empty /boot/ directory on /, and finish by reinstalling bootloader.
Another possibility: if there is space that can be made available for a completely
new larger boot elsewhere, make it, and migrate in similar manner to moving old
/boot/'s content to /. /boot/ filesystem need not be on the same disk as /.
--
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
10:06 p.m.
On 2/22/24 4:46 PM, Felix Miata wrote:
home user composed on 2024-02-22 16:30 (UTC-0700):
> Is my only real choice to cut back from 2 old kernels to 1 old kernel?
Maybe not. Most people don't need to run more than one kernel at a time, or retain
more than one as emergency fallback.
Does your overall configuration necessitate having boot on its own partition? If
not, and you have plenty of freespace on /, you could remount your /boot/
filesystem elsewhere, remove that filesystem from fstab, copy old filesystem
content to the now empty /boot/ directory on /, and finish by reinstalling bootloader.
I don't know. The original install was done 10+ years ago. Not knowing any better, I
very probably just accepted the defaults. Much of what you suggest here is over my head.
Another possibility: if there is space that can be made available for
a completely
new larger boot elsewhere, make it, and migrate in similar manner to moving old
/boot/'s content to /. /boot/ filesystem need not be on the same disk as /.
There is only one hard drive.
Removing the oldest kernel (dnf remove kernel-core...) looks to have solved the problem,
at least for a while. But thank-you for trying to help.
10:27 p.m.
home user composed on 2024-02-22 21:06 (UTC-0700):
Felix Miata wrote:
...
> Does your overall configuration necessitate having boot on its
own partition? If
> not, and you have plenty of freespace on /, you could remount your /boot/
> filesystem elsewhere, remove that filesystem from fstab, copy old filesystem
> content to the now empty /boot/ directory on /, and finish by reinstalling
bootloader.
I don't know. The original install was done 10+ years ago. Not
knowing any better, I very probably just accepted the defaults. Much of what you suggest
here is over my head.
> Another possibility: if there is space that can be made available
for a completely
> new larger boot elsewhere, make it, and migrate in similar manner to moving old
> /boot/'s content to /. /boot/ filesystem need not be on the same disk as /.
There is only one hard drive.
Removing the oldest kernel (dnf remove kernel-core...) looks to have
solved the problem, at least for a while. But thank-you for trying to help.
For now you should be fine with that config reduction to 2 kernels, but in the
long run, it may be best to gain some understanding of what you have, so better to
avoid more unexpected trouble as the system further evolves.
Output from:
cat /etc/fstab
parted -l and/or fdisk -l
lsblk -f
would enable us to understand your configuration and enable recommendations to be
made if indicated, before you get caught in an inextricable bind.
--
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
12:44 p.m.
On 2/22/24 9:27 PM, Felix Miata wrote:
Output from:
cat /etc/fstab
-bash.1[~]: cat /etc/fstab
#
# /etc/fstab
# Created by anaconda on Sun Mar 17 20:21:35 2013
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
UUID=45e553d2-fa0c-4eae-95f6-7bf9086ab74c / ext4 defaults
1 1
#UUID=c6db3d91-f891-48a2-ae61-28ad5cc9c3a6 /boot ext4 defaults
1 2
UUID=df1e61c4-7840-48fd-8576-55057bdc4001 /home ext4 defaults
1 2
UUID=cf2cfe3e-82b0-4bac-9241-ea821420a228 swap swap defaults
0 0
UUID=c6db3d91-f891-48a2-ae61-28ad5cc9c3a6 /boot ext4 defaults 02
/dev/disk/by-id/usb-USB_SanDisk_3.2Gen1_0401b8a494eb06f12687672105f83c86a1b53ed10d0f8c8955682a74130710c68b5200000000000000000000b80cf781ff9d2b1897558107c2af0bab-0:0
/mnt/usb-USB_SanDisk_3.2Gen1_0401b8a494eb06f12687672105f83c86a1b53ed10d0f8c8955682a74130710c68b5200000000000000000000b80cf781ff9d2b1897558107c2af0bab-0:0
auto nosuid,nodev,nofail,noauto,x-gvfs-show 0 0
/dev/disk/by-id/usb-USB_SanDisk_3.2Gen1_04019f018d92e92855f1f2a63241c9207094cd5e76f7e91e1c6b58a6f6d65d64042600000000000000000000c04a6d3b001c2b1897558107c2af0beb-0:0-part1
/mnt/usb-USB_SanDisk_3.2Gen1_04019f018d92e92855f1f2a63241c9207094cd5e76f7e91e1c6b58a6f6d65d64042600000000000000000000c04a6d3b001c2b1897558107c2af0beb-0:0-part1
auto nosuid,nodev,nofail,x-gvfs-show 0 0
/dev/disk/by-id/usb-USB_SanDisk_3.2Gen1_04019f018d92e92855f1f2a63241c9207094cd5e76f7e91e1c6b58a6f6d65d64042600000000000000000000c04a6d3b001c2b1897558107c2af0beb-0:0
/mnt/usb-USB_SanDisk_3.2Gen1_04019f018d92e92855f1f2a63241c9207094cd5e76f7e91e1c6b58a6f6d65d64042600000000000000000000c04a6d3b001c2b1897558107c2af0beb-0:0
auto nosuid,nodev,nofail,noauto,x-gvfs-show 0 0
-bash.2[~]:
parted -l and/or fdisk -l
-bash.3[~]: parted -l
Model: ATA ST2000DM006-2DM1 (scsi)
Disk /dev/sda: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags:
Number Start End Size Type File system Flags
1 1049kB 106MB 105MB primary ntfs boot
2 106MB 952GB 952GB primary ntfs
3 952GB 952GB 524MB primary ext4
4 952GB 2000GB 1048GB extended
5 952GB 961GB 8389MB logical linux-swap(v1) swap
6 961GB 1014GB 53.7GB logical ext4
7 1014GB 2000GB 986GB logical ext4
-bash.4[~]:
-bash.4[~]: fdisk -l
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DM006-2DM1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xfde8da65
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 1859026943 1858820096 886.4G 7 HPFS/NTFS/exFAT
/dev/sda3 1859026944 1860050943 1024000 500M 83 Linux
/dev/sda4 1860050944 3907029167 2046978224 976.1G 5 Extended
/dev/sda5 1860052992 1876436991 16384000 7.8G 82 Linux swap / Solaris
/dev/sda6 1876439040 1981296639 104857600 50G 83 Linux
/dev/sda7 1981298688 3907028991 1925730304 918.3G 83 Linux
-bash.5[~]:
lsblk -f
-bash.5[~]: lsblk -f
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
├─sda1
│ ntfs System Reserved
│ 6000B3A500B38098
├─sda2
│ ntfs E4C6B5A1C6B57480
├─sda3
│ ext4 1.0 c6db3d91-f891-48a2-ae61-28ad5cc9c3a6 113.4M 70% /boot
├─sda4
│
├─sda5
│ swap 1 cf2cfe3e-82b0-4bac-9241-ea821420a228 [SWAP]
├─sda6
│ ext4 1.0 45e553d2-fa0c-4eae-95f6-7bf9086ab74c 18.6G 57% /
└─sda7
ext4 1.0 df1e61c4-7840-48fd-8576-55057bdc4001 829.1G 3% /home
sr0
sr1
-bash.6[~]:
would enable us to understand your configuration and enable
recommendations to be
made if indicated, before you get caught in an inextricable bind.
3:48 p.m.
On 2/23/24 10:44, home user wrote:
-bash.4[~]: fdisk -l
Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: ST2000DM006-2DM1
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0xfde8da65
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
/dev/sda2 206848 1859026943 1858820096 886.4G 7 HPFS/NTFS/exFAT
/dev/sda3 1859026944 1860050943 1024000 500M 83 Linux
/dev/sda4 1860050944 3907029167 2046978224 976.1G 5 Extended
/dev/sda5 1860052992 1876436991 16384000 7.8G 82 Linux swap /
Solaris
/dev/sda6 1876439040 1981296639 104857600 50G 83 Linux
/dev/sda7 1981298688 3907028991 1925730304 918.3G 83 Linux
You could take 1GB off your swap partition and move the /boot partition
to there.
If you had live boot capability, I would suggest moving the space up to
where /boot is now, but I don't think you can do that while running it.
4:31 p.m.
Samuel Sieb composed on 2024-02-23 16:48 (UTC-0500):
home user wrote:
> -bash.4[~]: fdisk -l
> Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> Disk model: ST2000DM006-2DM1
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: dos
> Disk identifier: 0xfde8da65
> Device Boot Start End Sectors Size Id Type
> /dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
> /dev/sda2 206848 1859026943 1858820096 886.4G 7 HPFS/NTFS/exFAT
> /dev/sda3 1859026944 1860050943 1024000 500M 83 Linux
> /dev/sda4 1860050944 3907029167 2046978224 976.1G 5 Extended
> /dev/sda5 1860052992 1876436991 16384000 7.8G 82 Linux swap /
> Solaris
> /dev/sda6 1876439040 1981296639 104857600 50G 83 Linux
> /dev/sda7 1981298688 3907028991 1925730304 918.3G 83 Linux
You could take 1GB off your swap partition and move the /boot
partition
to there.
That, or any other size that pleases, though if the swap is routinely used for
hibernating and requires it all, complications grow among the possibilities.
If you had live boot capability, I would suggest moving the space up
to
where /boot is now, but I don't think you can do that while running it.
With swap off and /boot unmounted, swap could be deleted, boot enlarged to
whatever size desired, then swap recreated in whatever remains unused. If live
boot is truly impossible, this process should be easy enough to do by temporarily
moving the disk to some other computer.
Another option would be to shrink either sda7 or sda2. With the latter option,
move sda3 then enlarge. With the former it's more complicate because of the MBR
partitioning, create a new partition. The new boot at the end of disk would have
to be created after deleting sda3 if you wish the new to remain a primary, because
you can't have more primaries than you already have. If you're OK to have the new
boot be a logical, then it's not an issue. Personally that wouldn't happen, as my
boot partitions are always ever primary, because that's where I put Grub, not on
the MBR, where Windows compatible code always stays.
To be clear, sda4 here is a special case. It defines a location within which
logical partitions live, but it doesn't need to be manually or consciously taken
into account for these processes. Better partitioning tools automatically recreate
it as and if required to fit any legal group of logicals. Therefore, adjusting it
shouldn't require it be given any thought beyond the fact that it consumes a
primary partition table entry. It can be pretended to not exist notwithstanding
existence of its partition table entry.
--
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
2:58 p.m.
On 2/23/24 3:31 PM, Felix Miata wrote:
Samuel Sieb composed on 2024-02-23 16:48 (UTC-0500):
> home user wrote:
>> -bash.4[~]: fdisk -l
>> Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
>> Disk model: ST2000DM006-2DM1
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 4096 bytes
>> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
>> Disklabel type: dos
>> Disk identifier: 0xfde8da65
>> Device Boot Start End Sectors Size Id Type
>> /dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
>> /dev/sda2 206848 1859026943 1858820096 886.4G 7 HPFS/NTFS/exFAT
>> /dev/sda3 1859026944 1860050943 1024000 500M 83 Linux
>> /dev/sda4 1860050944 3907029167 2046978224 976.1G 5 Extended
>> /dev/sda5 1860052992 1876436991 16384000 7.8G 82 Linux swap /
>> Solaris
>> /dev/sda6 1876439040 1981296639 104857600 50G 83 Linux
>> /dev/sda7 1981298688 3907028991 1925730304 918.3G 83 Linux
> You could take 1GB off your swap partition and move the /boot partition
> to there.
That, or any other size that pleases, though if the swap is routinely used for
hibernating and requires it all, complications grow among the possibilities.
> If you had live boot capability, I would suggest moving the space up to
> where /boot is now, but I don't think you can do that while running it.
With swap off and /boot unmounted, swap could be deleted, boot enlarged to
whatever size desired, then swap recreated in whatever remains unused. If live
boot is truly impossible, this process should be easy enough to do by temporarily
moving the disk to some other computer.
Another option would be to shrink either sda7 or sda2. With the latter option,
move sda3 then enlarge. With the former it's more complicate because of the MBR
partitioning, create a new partition. The new boot at the end of disk would have
to be created after deleting sda3 if you wish the new to remain a primary, because
you can't have more primaries than you already have. If you're OK to have the
new
boot be a logical, then it's not an issue. Personally that wouldn't happen, as
my
boot partitions are always ever primary, because that's where I put Grub, not on
the MBR, where Windows compatible code always stays.
To be clear, sda4 here is a special case. It defines a location within which
logical partitions live, but it doesn't need to be manually or consciously taken
into account for these processes. Better partitioning tools automatically recreate
it as and if required to fit any legal group of logicals. Therefore, adjusting it
shouldn't require it be given any thought beyond the fact that it consumes a
primary partition table entry. It can be pretended to not exist notwithstanding
existence of its partition table entry.
No other computer.
No live boot. Tried making one multiple times with multiple sticks and multiple ports.
Even a local youngish professional programmer (specializing in embedded and micro) could
not figure it out.
I'm heavily leaning on being satisfied with space recovered by deleting one old kernel
and limiting the system to one old kernel henceforth.
8:10 p.m.
On Sat, 2024-02-24 at 13:58 -0700, home user wrote:
No other computer.
No live boot. Tried making one multiple times with multiple sticks
and multiple ports. Even a local youngish professional programmer
(specializing in embedded and micro) could not figure it out.
I'm curious how you installed it in the first place, then?
--
uname -rsvp
Linux 3.10.0-1160.108.1.el7.x86_64 #1 SMP Thu Jan 25 16:17:31 UTC 2024 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.
10:17 p.m.
On 2/24/24 7:10 PM, Tim via users wrote:
On Sat, 2024-02-24 at 13:58 -0700, home user wrote:
> No other computer.
> No live boot. Tried making one multiple times with multiple sticks
> and multiple ports. Even a local youngish professional programmer
> (specializing in embedded and micro) could not figure it out.
I'm curious how you installed it in the first place, then?
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.
12:49 a.m.
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 still have one ancient motherboard that cannot boot from USB sticks.
It's only options for USB booting are USB floppy and USB zip drives,
neither of which like USB anything else. It's also an extremely
useless motherboard, small RAM size, and without SATA ports, so I don't
really care.
I did reinstall Win98 on it last year just for self-torture reasons.
It was even dreadful at that.
--
uname -rsvp
Linux 3.10.0-1160.108.1.el7.x86_64 #1 SMP Thu Jan 25 16:17:31 UTC 2024 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.
8:39 a.m.
On Sun, Feb 25, 2024 at 1:49 AM Tim via users
<users(a)lists.fedoraproject.org> wrote:
I still have one ancient motherboard that cannot boot from USB
sticks.
It's only options for USB booting are USB floppy and USB zip drives,
neither of which like USB anything else. It's also an extremely
useless motherboard, small RAM size, and without SATA ports, so I don't
really care.
Once upon a time you could use "plop boot manager" to boot off of USB
devices if the motherboard didn't provide support. Of course this
meant that you had to have something that could boot plop, but as it
was very small this would typically be a floppy disk.
12:28 p.m.
Tim:
> I still have one ancient motherboard that cannot boot from USB
> sticks.
Go Canes:
Once upon a time you could use "plop boot manager" to boot
off of USB
devices if the motherboard didn't provide support. Of course this
meant that you had to have something that could boot plop, but as it
was very small this would typically be a floppy disk.
I thought it used to be possible to use a GRUB boot floppy. Not that
there's a floppy drive in this PC, though I could connect one.
It is old and quite useless. I'd probably be better off with something
like a Raspberry Pi if I were going to try and use something low grunt
for running things around the house. But since I have a server running
all the time, it makes little sense to run yet another thing.
I'd like to run the few WiFi controlled lights I have locally, all this
cloud stuff goes against the grain, I loathe things controlled by
mobile phones, even though I am doing that. For that reason all the
main lighting has no smarts. And I've heard tales of ambulances coming
to someone's rescue, and being unable to switch the lights on.
I'm also dubious about automatically switching on devices that could be
the cause of a fire. If something went "pfft!" when you switched it
on, you'd immediately switch it off again. But automatics switch
things on when you're not observing them.
Lightbulbs are relatively safe, in the grand scheme of things. The old
incandescents especially so. I have seen a compact fluorescent sizzle,
smoke, and spark. I don't know if it would actually have caught fire
if I didn't immediately switch it off. But all the electronics packed
into them aren't that trustworthy. LEDs seem a bit less kablooey than
compact fluoros, more likely to die with just a whimper.
--
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
1:38 p.m.
On Sun, Feb 25, 2024 at 11:29 AM Tim via users <
users(a)lists.fedoraproject.org> wrote:
I'd like to run the few WiFi controlled lights I have locally
(The rest of this has nothing directly to do with Fedora)
I do this with Phillips Hue lights and Home Assistant. The Hue integration
in Home Assistant communicates directly with the API on the Hue bridge, so
the lights can be controlled without the cloud. The lights don't actually
use WiFi, they communicate with the Hue bridge directly (using a wireless
protocol but not IP). There is a pre-made Raspberry Pi 4 image for Home
Assistant that works quite well. It might be overkill to set up Home
Assistant just for a few lights, but I use it for a number of other devices
as well (some of which do require the cloud, but I chose to use it knowing
that). Home Assistant also has programmable automations so I can do things
like turn on the porch light at sunset and so forth. There is a Home
Assistant phone app, but it also can be configured via a web browser so you
don't HAVE to use the phone app.
And I've heard tales of ambulances coming
to someone's rescue, and being unable to switch the lights on.
The Hue bulbs I have can be operated by the normal light switch. When
automating, the switch is on all the time, but turning the switch off and
back on makes the light come on full power, and then switching it off again
of course turns it off. Of course the automations no longer work if the
light has been powered off, but this isn't going to be a great concern if
it was powered off by a paramedic coming to the house :-) In fact the
worst problem is if there is a power outage, when power is restored all the
Hue lights come on. Power outages are quite rare here, and if there is one,
I can turn the lights off again remotely using Home Assistant.
Lightbulbs are relatively safe, in the grand scheme of things.
I think the chances of the relatively low power Hue bulbs being the cause
of a fire are quite remote.
--Greg
5:02 p.m.
On Sun, Feb 25, 2024 at 1:29 PM Tim via users
<users(a)lists.fedoraproject.org> wrote:
I'd like to run the few WiFi controlled lights I have locally,
all this
cloud stuff goes against the grain, I loathe things controlled by
mobile phones, even though I am doing that. For that reason all the
main lighting has no smarts. And I've heard tales of ambulances coming
to someone's rescue, and being unable to switch the lights on.
I have some tp-link stuff [no personal connection other than a
satisfied user]. Wi-fi, no hub required, and you can control them
from the Fedora command-line using the python kasa package [which
makes it sort-of relevant to the list, although you can use the kasa
package with any suitable Linux]. In theory you can also set them up
to work with the various voice assistants.
10:17 p.m.
New subject: 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, hmmmm, "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.
11:05 p.m.
New subject: 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, hmmmm,
"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
2:48 p.m.
On 2/23/24 2:48 PM, Samuel Sieb wrote:
On 2/23/24 10:44, home user wrote:
> -bash.4[~]: fdisk -l
> Disk /dev/sda: 1.82 TiB, 2000398934016 bytes, 3907029168 sectors
> Disk model: ST2000DM006-2DM1
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 4096 bytes
> Disklabel type: dos
> Disk identifier: 0xfde8da65
>
> Device Boot Start End Sectors Size Id Type
> /dev/sda1 * 2048 206847 204800 100M 7 HPFS/NTFS/exFAT
> /dev/sda2 206848 1859026943 1858820096 886.4G 7 HPFS/NTFS/exFAT
> /dev/sda3 1859026944 1860050943 1024000 500M 83 Linux
> /dev/sda4 1860050944 3907029167 2046978224 976.1G 5 Extended
> /dev/sda5 1860052992 1876436991 16384000 7.8G 82 Linux swap / Solaris
> /dev/sda6 1876439040 1981296639 104857600 50G 83 Linux
> /dev/sda7 1981298688 3907028991 1925730304 918.3G 83 Linux
You could take 1GB off your swap partition and move the /boot partition to there.
If you had live boot capability, I would suggest moving the space up to where /boot is
now, but I don't think you can do that while running it.
With this being a dual-boot computer, having only one permanent storage device (the one
hard drive), no other computers, and not being able to make a live boot, it seems best to
not try changing the partitioning. It seems too risky. I hope that someday I'll get
a new computer. Then I'll (hopefully) install (including partitioning) it more
wisely.
1:58 p.m.
On Thu, Feb 22, 2024 at 1:22 PM home user <mattisonw(a)comcast.net> 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?
Perhaps you can delete old btrfs or zfs snapshots.
Jeff
2:23 p.m.
On 2/22/24 12:58 PM, Jeffrey Walton wrote:
On Thu, Feb 22, 2024 at 1:22 PM home user
<mattisonw(a)comcast.net> 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?
Perhaps you can delete old btrfs or zfs snapshots.
I don't think I have brtfs; I've never heard of zfs. I have whatever was standard
for Fedora in March 2013. Am I correct in assuming that this does not apply?
3:50 p.m.
On 2/22/24 10:21, 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.
How big is your boot partition?
4:46 p.m.
On 2/22/24 2:50 PM, Samuel Sieb wrote:
On 2/22/24 10:21, 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.
How big is your boot partition?
-bash.1[~]: df /boot
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/sda3 485348 435267 20385 96% /boot
-bash.2[~]:
I realize it's not possible to remember everything about everyone who comes here for
help. To help you help me...
This is an 11 year old home workstation.
It's dual boot: Fedora-38 and windows-7.
I seriously doubt that the /boot partition can be made larger, but I'm no sys.admin.
and I could be wrong.
5:02 p.m.
On 02/22/2024 03:46 PM, home user wrote:
It's dual boot: Fedora-38 and windows-7.
I seriously doubt that the /boot partition can be made larger, but I'm
no sys.admin. and I could be wrong.
Dual boot doesn't matter. /boot is only used by Linux, and generally
isn't ever mounted when you're using Windows. And yes, you can make it
larger using parted or GParted, but you'd have to boot from a LiveUSB
for that and I wouldn't recommend it unless you're either comfortable
moving and resizing partitions or desperate enough to get more space
into it and in either case, only after making a full backup.
BTW, I have a python script that prunes the old kernels in /boot,
leaving you with only the most recent one. It was provided by Fedora
back in '11, if you're worried about programs by unknown third parties.
If you want, I can email it to you; ask off-list if you want it.
5:38 p.m.
On 2/22/24 4:02 PM, Joe Zeff wrote:
On 02/22/2024 03:46 PM, home user wrote:
> It's dual boot: Fedora-38 and windows-7.
>
> I seriously doubt that the /boot partition can be made larger, but I'm no
sys.admin. and I could be wrong.
Dual boot doesn't matter. /boot is only used by Linux, and generally isn't ever
mounted when you're using Windows. And yes, you can make it larger using parted or
GParted, but you'd have to boot from a LiveUSB for that and I wouldn't recommend
it unless you're either comfortable moving and resizing partitions or desperate enough
to get more space into it and in either case, only after making a full backup.
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.
BTW, I have a python script that prunes the old kernels in /boot,
leaving you with only the most recent one. It was provided by Fedora back in '11, if
you're worried about programs by unknown third parties. If you want, I can email it to
you; ask off-list if you want it.
--
Jeffrey provided a script in his post. I also have the commands from a clean-up-kernels
thread I had in December. But thank-you for your offer.
5:52 a.m.
On Thu, Feb 22, 2024 at 7:39 PM home user <mattisonw(a)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.
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. 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
10:40 p.m.
New subject: 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 <mattisonw(a)comcast.net
<mailto:mattisonw@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.
5:56 p.m.
On 2/22/24 10:21, home user wrote:
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.
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
You think you're only keeping 2 kernels, but you definitely have a full
3 kernels there (plus the rescue one). Your /boot partition is too
small, but if you actually reduce it down to 2 kernels, you should be fine.
You could also probably migrate the /boot directory into /, but without
having a live USB option, that might be a bit risky.
9:32 p.m.
On 2/22/24 4:56 PM, Samuel Sieb wrote:
On 2/22/24 10:21, home user wrote:
> 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.
>
> 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
You think you're only keeping 2 kernels, but you definitely have a full 3 kernels
there (plus the rescue one).
No, I don't think I'm only keeping 2 kernels. I'm keeping 2 old kernels.
There's also the current kernel and the rescue.
Your /boot partition is too small, but if you actually reduce it
down to 2 kernels, you should be fine.
ok.
Here I go...
-----
-bash.1[~]: rpm -qa kernel-core
kernel-core-6.7.3-100.fc38.x86_64
kernel-core-6.7.4-100.fc38.x86_64
kernel-core-6.7.5-100.fc38.x86_64
-bash.2[~]: dnf remove kernel-core-6.7.3-100.fc38.x86_64
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Removing:
kernel-core x86_64 6.7.3-100.fc38 @updates 66 M
Removing dependent packages:
kernel x86_64 6.7.3-100.fc38 @updates 0
kernel-modules x86_64 6.7.3-100.fc38 @updates 57 M
kernel-modules-core x86_64 6.7.3-100.fc38 @updates 32 M
kmod-nvidia-470xx-6.7.3-100.fc38.x86_64
x86_64 3:470.223.02-2.fc38 @@commandline 25 M
Transaction Summary
================================================================================
Remove 5 Packages
Freed space: 180 M
Is this ok [y/N]: y
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Erasing : kernel-6.7.3-100.fc38.x86_64 1/5
Running scriptlet: kernel-6.7.3-100.fc38.x86_64 1/5
Erasing : kernel-modules-6.7.3-100.fc38.x86_64 2/5
Running scriptlet: kernel-modules-6.7.3-100.fc38.x86_64 2/5
Erasing : kmod-nvidia-470xx-6.7.3-100.fc38.x86_64-3:470.223.02 3/5
Running scriptlet: kmod-nvidia-470xx-6.7.3-100.fc38.x86_64-3:470.223.02 3/5
Erasing : kernel-modules-core-6.7.3-100.fc38.x86_64 4/5
Running scriptlet: kernel-core-6.7.3-100.fc38.x86_64 5/5
Erasing : kernel-core-6.7.3-100.fc38.x86_64 5/5
Running scriptlet: kernel-core-6.7.3-100.fc38.x86_64 5/5
Verifying : kernel-6.7.3-100.fc38.x86_64 1/5
Verifying : kernel-core-6.7.3-100.fc38.x86_64 2/5
Verifying : kernel-modules-6.7.3-100.fc38.x86_64 3/5
Verifying : kernel-modules-core-6.7.3-100.fc38.x86_64 4/5
Verifying : kmod-nvidia-470xx-6.7.3-100.fc38.x86_64-3:470.223.02 5/5
Removed:
kernel-6.7.3-100.fc38.x86_64
kernel-core-6.7.3-100.fc38.x86_64
kernel-modules-6.7.3-100.fc38.x86_64
kernel-modules-core-6.7.3-100.fc38.x86_64
kmod-nvidia-470xx-6.7.3-100.fc38.x86_64-3:470.223.02-2.fc38.x86_64
Complete!
-bash.3[~]: rpm -qa kernel-core
kernel-core-6.7.4-100.fc38.x86_64
kernel-core-6.7.5-100.fc38.x86_64
-bash.4[~]: ls -S /boot
initramfs-0-rescue-70857e3fb05849139515e66a3fdc6b38.img
initramfs-6.7.5-100.fc38.x86_64.img
initramfs-6.7.4-100.fc38.x86_64.img
vmlinuz-6.7.4-100.fc38.x86_64
vmlinuz-6.7.5-100.fc38.x86_64
vmlinuz-0-rescue-70857e3fb05849139515e66a3fdc6b38
System.map-6.7.5-100.fc38.x86_64
System.map-6.7.4-100.fc38.x86_64
config-6.7.5-100.fc38.x86_64
config-6.7.4-100.fc38.x86_64
memtest86+x64.bin
lost+found
efi
grub2
loader
symvers-6.7.4-100.fc38.x86_64.xz
symvers-6.7.5-100.fc38.x86_64.xz
-bash.5[~]: df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 4096 0 4096 0% /dev
tmpfs 8158692 0 8158692 0% /dev/shm
tmpfs 3263480 1796 3261684 1% /run
/dev/sda6 51422028 29286488 19497716 61% /
tmpfs 8158696 0 8158696 0% /tmp
/dev/sda3 485348 339543 116109 75% /boot
/dev/sda7 947550748 30064516 869326592 4% /home
tmpfs 1631736 3888 1627848 1% /run/user/1001
-bash.6[~]:
-----
You could also probably migrate the /boot directory into /, but
without having a live USB option, that might be a bit risky.
That does look risky, live USB or no live USB!
Now I need to hunt down the other steps from my December thread. I'll post more when
that's done.
9:46 p.m.
On 2/22/24 19:32, home user wrote:
On 2/22/24 4:56 PM, Samuel Sieb wrote:
> On 2/22/24 10:21, home user wrote:
>> 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.
>>
>> 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
>
> You think you're only keeping 2 kernels, but you definitely have a
> full 3 kernels there (plus the rescue one).
No, I don't think I'm only keeping 2 kernels. I'm keeping 2 old
kernels. There's also the current kernel and the rescue.
Sorry, I misinterpreted it. You're keeping 2 *old* kernels and I read
it as keeping 2 kernels *total*. If you change the installonly_limit=3
to 2 in /etc/dnf/dnf.conf then it will only keep 1 old kernel automatically.
9:53 p.m.
On 2/22/24 8:46 PM, Samuel Sieb wrote:
On 2/22/24 19:32, home user wrote:
Sorry, I misinterpreted it. You're keeping 2 *old* kernels and I read it as keeping
2 kernels *total*.
Well, I'm not the best of writers!
If you change the installonly_limit=3 to 2 in /etc/dnf/dnf.conf then
it will only keep 1 old kernel automatically.
--
Thank-you! I was about to start digging through my December thread to find that. You
saved me the trouble.
It's done.
I just rebooted; the grub menu looks fine.
I'm putting this aside until weekly patches installs a new kernel. That should be an
adequate test of the fix.
6:44 a.m.
On Thu, Feb 22, 2024 at 2:22 PM home user <mattisonw(a)comcast.net> 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?
Is there anything in your /boot/lost+found?
--
George N. White III
1:19 p.m.
On 2/23/24 5:44 AM, George N. White III wrote:
On Thu, Feb 22, 2024 at 2:22 PM home user <mattisonw(a)comcast.net
<mailto:mattisonw@comcast.net>> wrote:
Is there anything in your /boot/lost+found?
/boot/lost+found/:
total 20
drwx------. 2 root root 12288 Mar 17 2013 .
dr-xr-xr-x. 6 root root 5120 Feb 22 20:21 ..
-bash.12[boot]:
But what is odd is the ls -l output for /boot/lost+found/ itself. Why is an empty
directory taking up 12288 bytes? Other directories that are not empty are only taking up
1024 bytes.
3:34 p.m.
On Fri, Feb 23, 2024 at 12:19:51PM -0700, home user wrote:
On 2/23/24 5:44 AM, George N. White III wrote:
> On Thu, Feb 22, 2024 at 2:22 PM home user <mattisonw(a)comcast.net
<mailto:mattisonw@comcast.net>> wrote:
>
>
> Is there anything in your /boot/lost+found?
/boot/lost+found/:
total 20
drwx------. 2 root root 12288 Mar 17 2013 .
dr-xr-xr-x. 6 root root 5120 Feb 22 20:21 ..
-bash.12[boot]:
But what is odd is the ls -l output for /boot/lost+found/ itself. Why is an empty
directory taking up 12288 bytes? Other directories that are not empty are only taking up
1024 bytes.
Directories expand in size when a lot of directory entries exist.
They do not shrink when those entries are removed.
You can manually shrink it by rmdir the L&F directory then recreate it.
But do you really care about 11K bytes?
--
Jon H. LaBadie jonfu(a)jgcomp.com
2:16 p.m.
On 2/23/24 2:34 PM, Jon LaBadie wrote:
On Fri, Feb 23, 2024 at 12:19:51PM -0700, home user wrote:
> On 2/23/24 5:44 AM, George N. White III wrote:
>> On Thu, Feb 22, 2024 at 2:22 PM home user <mattisonw(a)comcast.net
<mailto:mattisonw@comcast.net>> wrote:
>>
>
>>
>> Is there anything in your /boot/lost+found?
>
> /boot/lost+found/:
> total 20
> drwx------. 2 root root 12288 Mar 17 2013 .
> dr-xr-xr-x. 6 root root 5120 Feb 22 20:21 ..
> -bash.12[boot]:
>
> But what is odd is the ls -l output for /boot/lost+found/ itself. Why is an empty
directory taking up 12288 bytes? Other directories that are not empty are only taking up
1024 bytes.
Directories expand in size when a lot of directory entries exist.
They do not shrink when those entries are removed.
You can manually shrink it by rmdir the L&F directory then recreate it.
But do you really care about 11K bytes?
Something I did not know. Thank-you.
You're right, it's only 11K. Relative to the original problem, not significant.
2:34 p.m.
On 2/24/24 12:16, home user wrote:
On 2/23/24 2:34 PM, Jon LaBadie wrote:
> On Fri, Feb 23, 2024 at 12:19:51PM -0700, home user wrote:
>> On 2/23/24 5:44 AM, George N. White III wrote:
>>> On Thu, Feb 22, 2024 at 2:22 PM home user <mattisonw(a)comcast.net
>>> <mailto:mattisonw@comcast.net>> wrote:
>>>
>>
>>>
>>> Is there anything in your /boot/lost+found?
>>
>> /boot/lost+found/:
>> total 20
>> drwx------. 2 root root 12288 Mar 17 2013 .
>> dr-xr-xr-x. 6 root root 5120 Feb 22 20:21 ..
>> -bash.12[boot]:
>>
>> But what is odd is the ls -l output for /boot/lost+found/ itself.
>> Why is an empty directory taking up 12288 bytes? Other directories
>> that are not empty are only taking up 1024 bytes.
>
> Directories expand in size when a lot of directory entries exist.
> They do not shrink when those entries are removed.
>
> You can manually shrink it by rmdir the L&F directory then recreate it.
> But do you really care about 11K bytes?
>
Something I did not know. Thank-you.
You're right, it's only 11K. Relative to the original problem, not
significant.
That directory is also special. There might be consequences for
recreating it. I don't know if it's accessed by name or inode.
3:02 p.m.
On 2/24/24 1:34 PM, Samuel Sieb wrote:
On 2/24/24 12:16, home user wrote:
> On 2/23/24 2:34 PM, Jon LaBadie wrote:
>> On Fri, Feb 23, 2024 at 12:19:51PM -0700, home user wrote:
>>> On 2/23/24 5:44 AM, George N. White III wrote:
>>>> On Thu, Feb 22, 2024 at 2:22 PM home user <mattisonw(a)comcast.net
<mailto:mattisonw@comcast.net>> wrote:
>>>>
>>>
>>>>
>>>> Is there anything in your /boot/lost+found?
>>>
>>> /boot/lost+found/:
>>> total 20
>>> drwx------. 2 root root 12288 Mar 17 2013 .
>>> dr-xr-xr-x. 6 root root 5120 Feb 22 20:21 ..
>>> -bash.12[boot]:
>>>
>>> But what is odd is the ls -l output for /boot/lost+found/ itself. Why is an
empty directory taking up 12288 bytes? Other directories that are not empty are only
taking up 1024 bytes.
>>
>> Directories expand in size when a lot of directory entries exist.
>> They do not shrink when those entries are removed.
>>
>> You can manually shrink it by rmdir the L&F directory then recreate it.
>> But do you really care about 11K bytes?
>>
>
> Something I did not know. Thank-you.
>
> You're right, it's only 11K. Relative to the original problem, not
significant.
That directory is also special. There might be consequences for recreating it. I
don't know if it's accessed by name or inode.
That's the first I've ever heard of that! I learn something new once in a while.
Thank-you.
I'm definitely leaving it.
12:50 a.m.
Samuel Sieb (re: lost & found directory):
That directory is also special. There might be consequences for
recreating it. I don't know if it's accessed by name or inode.
I would imagine there'd have to be reserved space in the partition so
it doesn't otherwise fill up 100% making it impossible to use.
--
uname -rsvp
Linux 3.10.0-1160.108.1.el7.x86_64 #1 SMP Thu Jan 25 16:17:31 UTC 2024 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.
1:31 a.m.
On 2/24/24 22:50, Tim via users wrote:
Samuel Sieb (re: lost & found directory):
> That directory is also special. There might be consequences for
> recreating it. I don't know if it's accessed by name or inode.
I would imagine there'd have to be reserved space in the partition so
it doesn't otherwise fill up 100% making it impossible to use.
The lost and found directory is for fsck to link lost files into. They
aren't copied, so it doesn't use any more space.
3:51 p.m.
On 2/23/24 11:19, home user wrote:
On 2/23/24 5:44 AM, George N. White III wrote:
> On Thu, Feb 22, 2024 at 2:22 PM home user <mattisonw(a)comcast.net
> <mailto:mattisonw@comcast.net>> wrote:
>
>
> Is there anything in your /boot/lost+found?
/boot/lost+found/:
total 20
drwx------. 2 root root 12288 Mar 17 2013 .
dr-xr-xr-x. 6 root root 5120 Feb 22 20:21 ..
-bash.12[boot]:
But what is odd is the ls -l output for /boot/lost+found/ itself. Why
is an empty directory taking up 12288 bytes? Other directories that are
not empty are only taking up 1024 bytes.
That directory might have some space pre-allocated so that entries can
be created even when the filesystem is in a bad state, since that's what
it's for.
2:50 p.m.
On 2/23/24 2:51 PM, Samuel Sieb wrote:
On 2/23/24 11:19, home user wrote:
> On 2/23/24 5:44 AM, George N. White III wrote:
>> On Thu, Feb 22, 2024 at 2:22 PM home user <mattisonw(a)comcast.net
<mailto:mattisonw@comcast.net>> wrote:
>>
>
>>
>> Is there anything in your /boot/lost+found?
>
> /boot/lost+found/:
> total 20
> drwx------. 2 root root 12288 Mar 17 2013 .
> dr-xr-xr-x. 6 root root 5120 Feb 22 20:21 ..
> -bash.12[boot]:
>
> But what is odd is the ls -l output for /boot/lost+found/ itself. Why is an empty
directory taking up 12288 bytes? Other directories that are not empty are only taking up
1024 bytes.
That directory might have some space pre-allocated so that entries can be created even
when the filesystem is in a bad state, since that's what it's for.
That makes sense.
As I vaguely implied in my response to Jon, I'm leaving it.
3:09 p.m.
New subject: 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.
80
days inactive
84
days old
44 comments
12 participants
participants (12)
-
Felix Miata -
George N. White III -
Go Canes -
Greg Woods -
home user -
Jeffrey Walton -
Joe Zeff -
Jon LaBadie -
Mike Wright -
old sixpack13 -
Samuel Sieb -
Tim