Re: /boot too Small in F40
On 02/07/2024 10:38, Stephen Morris wrote: My / partition is on a 3TB hard disk and is using BTRFS. I've put /boot on an SSD, where I have /boot for Ubuntu, Drive C for windows and the UEFI partition, for hoped boot performance improvements. I would assume the performance difference to be not noticeable. The kernel image and initrd are written once on kernel install/update and copied into RAM once at the very start of the boot process and not touched again afterwards. So except perhaps for a few seconds of boot time and a few seconds on kernel updates, there will not be any difference in performance. /boot is likely the part of your system files that gives you the least performance benefit from being placed on an SSD vs. HDD. Grub can boot from BTRFS directly. -- ___ 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 too Small in F40
On 30/6/24 13:23, Samuel Sieb wrote: On 6/29/24 6:36 PM, Stephen Morris wrote: Hi, My /boot partition is 512MB, which in F39 was more than ample for 5 kernels and a rescue image, but in F40 that partition is now to small for a new rescue image to be created when a new kernel is installed. The rescue image in F40 seems to be around 102MB in size which is more that double the size of any kernel, I don't know what size it was in F39. That is normal. It contains all the kernel modules, so it is much bigger. And it's the initramfs, not kernel. The kernel is the same size. Thanks Samuel, yes, the initramfs is huge at 651MB each. At the time I was getting the space issue I misread the size of these files and thought they were smaller that the rescue file. I've tried dropping the number of kernels retained to 4, but that still produces out of space conditions on new kernel installs with the rescue image. Is F40 now rebuilding the rescue image where F39 didn't? The rescue kernel is always rebuilt if you delete the old one. There's a setting somewhere to stop that. I did delete the old rescue kernel which was 102MB in size, with the rebuilt rescue kernel being around only 15MB in size. If I drop back to retaining only 3 kernels will that provide enough free space, currently /boot is using 360.2MB with 88MB free of the 512MB partition? My /boot is about 350MB with 3 kernels and the rescue. Is F40 really that much bigger the F39 that the /boot partition size, which I have always used across multiple Fedora versions, is no longer big enough to handle what F40 does relative to kernels? My latest F40 initramfs is actually smaller than the previous one and the F39 one. My initramfs for the 6.9.6 kernel is slightly bigger than the one for kernel 6.9.4, and both of them are smaller than the ones for kernels 6.8.11 and 6.8.10. I don't know what the size of the F39 one was. I have my /boot partition on an SSD. I could run gparted to resize the boot partition by resizing the Windows drive C partition which is on the disk before it (a 512MB /boot partition for Ubuntu is immediately after the Fedora partition), but I don't really want to change the size of the Windows partition? 512MB is enough for the default 3 kernels. Why do you need more than that? I potentially don't need more than 3, I was just trying to keep a bigger safety net for non-booting kernels. I have been in the situation where the latest two kernels of the installed 3 wouldn't boot. regards, Steve OpenPGP_0x594338B1DE179AB2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ 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 too Small in F40
On 30/6/24 23:01, George N. White III wrote: On Sat, Jun 29, 2024 at 10:36 PM Stephen Morris wrote: Hi, My /boot partition is 512MB, which in F39 was more than ample for 5 kernels and a rescue image, but in F40 that partition is now to small for a new rescue image to be created when a new kernel is installed. The rescue image in F40 seems to be around 102MB in size which is more that double the size of any kernel, I don't know what size it was in F39. I've tried dropping the number of kernels retained to 4, but that still produces out of space conditions on new kernel installs with the rescue image. Is F40 now rebuilding the rescue image where F39 didn't? If I drop back to retaining only 3 kernels will that provide enough free space, currently /boot is using 360.2MB with 88MB free of the 512MB partition? Is F40 really that much bigger the F39 that the /boot partition size, which I have always used across multiple Fedora versions, is no longer big enough to handle what F40 does relative to kernels? I have my /boot partition on an SSD. I could run gparted to resize the boot partition by resizing the Windows drive C partition which is on the disk before it (a 512MB /boot partition for Ubuntu is immediately after the Fedora partition), but I don't really want to change the size of the Windows partition? You could create a new partition somewhere else, but others have found old cruft in /boot, so try comparing with what I have (on dual boot with Windows 11 and F40) below. % sudo du -sm /boot 439 /boot % sudo du -sm /boot/* 1 /boot/config-6.9.4-200.fc40.x86_64 1 /boot/confg-6.9.5-200.fc40.x86_64 1 /boot/config-6.9.6-200.fc40.x86_64 100 /boot/efi 3 /boot/grub2 162 /boot/initramfs-0-rescue-0a5117a885584ae1b650c3c575315b73.img 29 /boot/initramfs-6.9.4-200.fc40.x86_64.img 29 /boot/initramfs-6.9.5-200.fc40.x86_64.img 29 /boot/initramfs-6.9.6-200.fc40.x86_64.img 1 /boot/loader 1 /boot/lost+found 1 /boot/memtest86+x64.efi 1 /boot/symvers-6.9.4-200.fc40.x86_64.xz 1 /boot/symvers-6.9.5-200.fc40.x86_64.xz 1 /boot/symvers-6.9.6-200.fc40.x86_64.xz 9 /boot/System.map-6.9.4-200.fc40.x86_64 9 /boot/System.map-6.9.5-200.fc40.x86_64 9 /boot/System.map-6.9.6-200.fc40.x86_64 16 /boot/vmlinuz-0-rescue-0a5117a885584ae1b650c3c575315b73 16 /boot/vmlinuz-6.9.4-200.fc40.x86_64 16 /boot/vmlinuz-6.9.5-200.fc40.x86_64 16 /boot/vmlinuz-6.9.6-200.fc40.x86_64 -- George N. White III Thanks George, I've checked my /boot against yours and it is much the same except I also have an EXTLINUX folder that I don't know where it came from, that contains .c32 files, but all those files are fairly small. From Samuel's email, the biggest files in /boot are the initramfs files at 651MB each. But also at the time I was getting the issues the rescue image as 102MB in size. regards, Steve OpenPGP_0x594338B1DE179AB2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ 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 too Small in F40
On 1/7/24 08:27, Lukas Middendorf wrote: On 30/06/2024 03:36, Stephen Morris wrote: I've tried dropping the number of kernels retained to 4, but that still produces out of space conditions on new kernel installs with the rescue image. You can also consider disabling the rescue kernel generation. I have never had any use for it. I think the only time you would need to use the rescue kernel is when some fundamental hardware change (like different mainboard-CPU-combo) requires different kernel modules to boot than what is included in your normal initrd. In case this situation happens, you can enable the rescue kernel generation again. Ideally before the hardware change (if this is a planned operation), but it should also be possible by mounting and chrooting from a live system (if your old system just died). Disabling the rescue kernel should be as easy as uninstalling the package dracut-config-rescue. Is F40 really that much bigger the F39 that the /boot partition size, which I have always used across multiple Fedora versions, is no longer big enough to handle what F40 does relative to kernels? Do you really need the separate /boot partition? I have not had separate /boot partitions for at least a decade now. Especially with multiple parallel installations, it is much simpler to not have / and /boot on different partitions. And that way you waste less space and you can't get the size of /boot wrong. You only need a separate /boot if your / can not be read by grub directly. Where is your / located and what FS do you use for it? My / partition is on a 3TB hard disk and is using BTRFS. I've put /boot on an SSD, where I have /boot for Ubuntu, Drive C for windows and the UEFI partition, for hoped boot performance improvements. regards, Steve OpenPGP_0x594338B1DE179AB2.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature -- ___ 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 too Small in F40
On 30/06/2024 03:36, Stephen Morris wrote: I've tried dropping the number of kernels retained to 4, but that still produces out of space conditions on new kernel installs with the rescue image. You can also consider disabling the rescue kernel generation. I have never had any use for it. I think the only time you would need to use the rescue kernel is when some fundamental hardware change (like different mainboard-CPU-combo) requires different kernel modules to boot than what is included in your normal initrd. In case this situation happens, you can enable the rescue kernel generation again. Ideally before the hardware change (if this is a planned operation), but it should also be possible by mounting and chrooting from a live system (if your old system just died). Disabling the rescue kernel should be as easy as uninstalling the package dracut-config-rescue. Is F40 really that much bigger the F39 that the /boot partition size, which I have always used across multiple Fedora versions, is no longer big enough to handle what F40 does relative to kernels? Do you really need the separate /boot partition? I have not had separate /boot partitions for at least a decade now. Especially with multiple parallel installations, it is much simpler to not have / and /boot on different partitions. And that way you waste less space and you can't get the size of /boot wrong. You only need a separate /boot if your / can not be read by grub directly. Where is your / located and what FS do you use for it? -- ___ 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 too Small in F40
On Sat, Jun 29, 2024 at 10:36 PM Stephen Morris wrote: > Hi, > My /boot partition is 512MB, which in F39 was more than ample for 5 > kernels and a rescue image, but in F40 that partition is now to small > for a new rescue image to be created when a new kernel is installed. The > rescue image in F40 seems to be around 102MB in size which is more that > double the size of any kernel, I don't know what size it was in F39. > I've tried dropping the number of kernels retained to 4, but that > still produces out of space conditions on new kernel installs with the > rescue image. > Is F40 now rebuilding the rescue image where F39 didn't? > If I drop back to retaining only 3 kernels will that provide enough free > space, currently /boot is using 360.2MB with 88MB free of the 512MB > partition? > Is F40 really that much bigger the F39 that the /boot partition size, > which I have always used across multiple Fedora versions, is no longer > big enough to handle what F40 does relative to kernels? > I have my /boot partition on an SSD. I could run gparted to resize the > boot partition by resizing the Windows drive C partition which is on the > disk before it (a 512MB /boot partition for Ubuntu is immediately after > the Fedora partition), but I don't really want to change the size of the > Windows partition? > You could create a new partition somewhere else, but others have found old cruft in /boot, so try comparing with what I have (on dual boot with Windows 11 and F40) below. % sudo du -sm /boot 439 /boot % sudo du -sm /boot/* 1 /boot/config-6.9.4-200.fc40.x86_64 1 /boot/confg-6.9.5-200.fc40.x86_64 1 /boot/config-6.9.6-200.fc40.x86_64 100 /boot/efi 3 /boot/grub2 162 /boot/initramfs-0-rescue-0a5117a885584ae1b650c3c575315b73.img 29 /boot/initramfs-6.9.4-200.fc40.x86_64.img 29 /boot/initramfs-6.9.5-200.fc40.x86_64.img 29 /boot/initramfs-6.9.6-200.fc40.x86_64.img 1 /boot/loader 1 /boot/lost+found 1 /boot/memtest86+x64.efi 1 /boot/symvers-6.9.4-200.fc40.x86_64.xz 1 /boot/symvers-6.9.5-200.fc40.x86_64.xz 1 /boot/symvers-6.9.6-200.fc40.x86_64.xz 9 /boot/System.map-6.9.4-200.fc40.x86_64 9 /boot/System.map-6.9.5-200.fc40.x86_64 9 /boot/System.map-6.9.6-200.fc40.x86_64 16 /boot/vmlinuz-0-rescue-0a5117a885584ae1b650c3c575315b73 16 /boot/vmlinuz-6.9.4-200.fc40.x86_64 16 /boot/vmlinuz-6.9.5-200.fc40.x86_64 16 /boot/vmlinuz-6.9.6-200.fc40.x86_64 -- George N. White III -- ___ 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 too Small in F40
On 6/29/24 6:36 PM, Stephen Morris wrote: Hi, My /boot partition is 512MB, which in F39 was more than ample for 5 kernels and a rescue image, but in F40 that partition is now to small for a new rescue image to be created when a new kernel is installed. The rescue image in F40 seems to be around 102MB in size which is more that double the size of any kernel, I don't know what size it was in F39. That is normal. It contains all the kernel modules, so it is much bigger. And it's the initramfs, not kernel. The kernel is the same size. I've tried dropping the number of kernels retained to 4, but that still produces out of space conditions on new kernel installs with the rescue image. Is F40 now rebuilding the rescue image where F39 didn't? The rescue kernel is always rebuilt if you delete the old one. There's a setting somewhere to stop that. If I drop back to retaining only 3 kernels will that provide enough free space, currently /boot is using 360.2MB with 88MB free of the 512MB partition? My /boot is about 350MB with 3 kernels and the rescue. Is F40 really that much bigger the F39 that the /boot partition size, which I have always used across multiple Fedora versions, is no longer big enough to handle what F40 does relative to kernels? My latest F40 initramfs is actually smaller than the previous one and the F39 one. I have my /boot partition on an SSD. I could run gparted to resize the boot partition by resizing the Windows drive C partition which is on the disk before it (a 512MB /boot partition for Ubuntu is immediately after the Fedora partition), but I don't really want to change the size of the Windows partition? 512MB is enough for the default 3 kernels. Why do you need more than that? -- ___ 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 too small
Once upon a time, Chris Murphy said: > GRUB hidden boot menu feature depends on a really curious file called grubenv Just to note: boot-time grubenv modification is used for more than boot success/fail detection. Setting a default boot option during boot and setting a boot-once option (at least) also use it. So any solution to using btrfs needs to handle "modify grubenv", not just the specific case of "hidden boot menu". -- Chris Adams -- ___ 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 too small
On Tue, May 14, 2024, at 7:27 PM, richard emberson wrote: > Poking about I see that the default workstation disk layout: >https://docs.fedoraproject.org/en-US/workstation-docs/disk-config/ > has /boot on a ext4 partition and everything else on btrfs. > Also, the replacement for Anaconda will not happen until Fedora 41: Now Fedora 42. https://lists.fedoraproject.org/archives/list/de...@lists.fedoraproject.org/message/EIKMTS3SYSKH7R2VIJ37NMSYDCIUK466/ > So, are you saying that with Fedora 41, it will be the default for the > /boot partition to use btrfs? There are some unresolved issues before we do this. I think top on the list is fscrypt support for Btrfs (it's in final code review prior to being merged so hopefully this year). That way we can have a non-encrypted /boot on Btrfs subvolume for GRUB2, and not have to do the dirty work of configuring GRUB for LUKS. But then we can have per directory encryption. Like we could eventually have / encrypted with a key sealed in the TPM so it just automatically gets unlocked during startup, but it's protected from tampering when at rest (off). And then use a different key based on user login passphrase or a hardware key like a FIDO device, e.g. systemd-homed, per user home. A lot of this is being worked on already but I can't tell you when it'll land in a future Fedora version until it's farther along. GRUB hidden boot menu feature depends on a really curious file called grubenv in order to know if the boot has failed, and if it's failed, to show the otherwise hidden boot menu (kernel list). The grubenv file was conceived in ancient times when it was acceptable for GRUB to find the file (via file system read only drivers), and overwrite the contents of its blocks, modifying typically just one byte, in order to reset the boot counter. Then later if the boot succeeds, the grubenv is modified in (linux) user space. But when this file is on Btrfs, modifying the contents of a file outside the kernel code (by GRUB just changing bytes on disk in a single sector) is indistinguishable by Btrfs from corruption, because GRUB does not have a btrfs write driver - it's read only, so it doesn't recompute checksums, and rewrite all the leaf and node blocks to correctly update the file system for this change. Therefore the file will fail checksum verification by Btrfs, so it can't be read, and thus the file would need to be replaced in user space every time... we don't really need the data in it, probably? I have to think about it some more. Or alternatively we rethink the hidden grub menu feature. There's been a bunch of ideas where the grubenv data should go instead because really none of the file system developers like the current approach of code that isn't upstream (kernel) based writing inside the file system area. It's now frowned on. Another consideration is that /boot on Btrfs means it's harder to support other bootloaders like sd-boot, which don't contain file system drivers like GRUB's read-only drivers. There's a couple of different projects to create an EFI FS driver for Btrfs so that the UEFI pre-boot environment can read Btrfs natively - therefore any bootloader would be able to read it. The drawback with this is, it needs to be UEFI Secure Boot signed, and we need some plan and policy how that would work - per distribution btrfs drivers? Or is there a way to make it generically supportable across distributions with a single signature? That's off the top of my head there might be some other things. -- Chris Murphy -- ___ 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 too small
On Tue, May 14, 2024, at 2:12 PM, Tim via users wrote: > On Tue, 2024-05-14 at 08:27 -0700, richard emberson wrote: >> Back on 05/03/2024 I posted the question: >> "How to increase size of /boot partition" >> I had the same problem. >> >> As was noted by some, I had not upgraded for a long, long time: >> "This type of layout and partition sizes is ancient. /tmp isn't even a >> partition now." > > Does /boot still need to be its own partition, these days? Indirectly yes, because the installer doesn't configure GRUB2 for unlocking a LUKS encrypted partition (so that GRUB can find the kernel and initramfs, load them, and start the kernel). Therefore, on Fedora /boot is not encrypted, and LUKS unlock for root is done in the initramfs. Otherwise it's not necessary, GRUB2 has Btrfs support since forever. -- Chris Murphy -- ___ 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 too small
On Wed, May 15, 2024 at 1:45 AM Chris Adams wrote: > Once upon a time, Michal Schorm said: > > On Tue, May 14, 2024 at 8:13 PM Tim via users > > wrote: > > > Does /boot still need to be its own partition, these days? > > > /boot/efi has to be, but that's mapped into /boot, already. > > > > Definitely not. > > It does for a variety of cases, such as an encrypted root filesystem. I do have full disk encryption /boot included. Or do you want your kernels to be tampered with by anyone that gets hands onto your computer? It is a bit more complex, but not that much. The main trick was to automatically bake an extra decryption key into the kernel every time it's installed, so you don't need to put it in twice. (Once for GRUB to find the kernel, second time for kernel to be able to touch the FS) -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, May 15, 2024 at 1:45 AM Chris Adams wrote: > > Once upon a time, Michal Schorm said: > > On Tue, May 14, 2024 at 8:13 PM Tim via users > > wrote: > > > Does /boot still need to be its own partition, these days? > > > /boot/efi has to be, but that's mapped into /boot, already. > > > > Definitely not. > > It does for a variety of cases, such as an encrypted root filesystem. > > -- > Chris Adams > -- > ___ > 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 -- ___ 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 too small
On Wed, May 15, 2024 at 1:29 AM richard emberson wrote: > Poking about I see that the default workstation disk layout: >https://docs.fedoraproject.org/en-US/workstation-docs/disk-config/ > has /boot on a ext4 partition and everything else on btrfs. > Also, the replacement for Anaconda will not happen until Fedora 41: > > https://forums.fedoraforum.org/showthread.php?332111-Fedora-40-will-remain-with-existing-anaconda > > So, are you saying that with Fedora 41, it will be the default for the /boot > partition to use btrfs? > Or, is this something that works for you? It is something that works for me. Back when I started poking around BTRFS, going from person to person, asking tons of questions of what would or would not be possible, which resulted in un-clogging the pipes that blocked widespread BTRFS adoption in Fedora, the full system on BTRFS layout was what I was suggesting. I'm so glad people were willing to adopt BTRFS (both Fedora developers allowing that and actually making that happen; and the users alike), but I feel like the job is half-done. The biggest obstacle of any change to the default FS layouts is - in my opinion - GRUB. The GRUB configuration can be so clean, brief and nice, even for very complicated setups - when you tailor it exactly to your needs. However making auto-generated configurations that would work for everyone, covering most possible configurations is an entirely different thing - which GRUB doesn't handle well IMO. Sorrows of dual booting and similar themes are common on discussion.fedoraproject.org. Even though I see the BTRFS adoption in Fedora as quite a success. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Wed, May 15, 2024 at 1:29 AM richard emberson wrote: > > Poking about I see that the default workstation disk layout: >https://docs.fedoraproject.org/en-US/workstation-docs/disk-config/ > has /boot on a ext4 partition and everything else on btrfs. > Also, the replacement for Anaconda will not happen until Fedora 41: > > https://forums.fedoraforum.org/showthread.php?332111-Fedora-40-will-remain-with-existing-anaconda > > So, are you saying that with Fedora 41, it will be the default for the /boot > partition to use btrfs? > Or, is this something that works for you? > > Thanks. > Richard > On 5/14/24 3:38 PM, Michal Schorm wrote: > > On Tue, May 14, 2024 at 8:13 PM Tim via users > > wrote: > >> Does /boot still need to be its own partition, these days? > >> /boot/efi has to be, but that's mapped into /boot, already. > > > > Definitely not. > > And it actually creates all kinds of problems when separated. > > > > The best *trivial* setup and usage should be having everything on > > BTRFS (except EFI, as you said), > > and maintain some amount of snapshots you can revert to anytime in > > case of any issues. > > > > When /boot is on the BTRFS, the snapshot contains the whole system, > > and ensures bootability of the snapshots. > > > > When /boot is on a standalone partition, the snapshot contains kernel > > modules, but not the actual kernel. > > When booting a new kernel (from /boot) with old kernel modules (from > > the snapshot), the modules can't be loaded, leaving you with a kind of > > crippled system. (bootable, but only partly usable) > > Which is far from what people would usually expect. > > > > -- > > > > A better, but more complicated setup consists of various snapshots of > > various subvolumes which are mounted to various locations. (e.g. > > standalone subvolumes for /home, games, backups, ... whatever) > > Often managed by some software (snapper, timeshit, ... not sure about > > the specific names), rather than the btrfs commands themselves. > > > > -- > > > > I managed to craft a setup that changes which snapshot (or which OS) > > will boot by changing just a single symlink. > > That too would be (likely ?) impossible with /boot on a separate partition. > > > > -- > > > > Michal Schorm > > Software Engineer > > Core Services - Databases Team > > Red Hat > > > > -- > > > > On Tue, May 14, 2024 at 8:13 PM Tim via users > > wrote: > >> > >> On Tue, 2024-05-14 at 08:27 -0700, richard emberson wrote: > >>> Back on 05/03/2024 I posted the question: > >>> "How to increase size of /boot partition" > >>> I had the same problem. > >>> > >>> As was noted by some, I had not upgraded for a long, long time: > >>> "This type of layout and partition sizes is ancient. /tmp isn't even > >>> a partition now." > >> > >> Does /boot still need to be its own partition, these days? > >> > >> /boot/efi has to be, but that's mapped into /boot, already. > >> > >> > >> -- > >> > >> 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 >
Re: /boot too small
Once upon a time, Michal Schorm said: > On Tue, May 14, 2024 at 8:13 PM Tim via users > wrote: > > Does /boot still need to be its own partition, these days? > > /boot/efi has to be, but that's mapped into /boot, already. > > Definitely not. It does for a variety of cases, such as an encrypted root filesystem. -- Chris Adams -- ___ 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 too small
Michal Schorm wrote: >The best *trivial* setup and usage should be having everything on >BTRFS (except EFI, as you said), >and maintain some amount of snapshots you can revert to anytime in >case of any issues. I look forward to a complete set of instructions for this approach in the Fedora documentation web site. I'm sure many of us will want to adopt this approach. -- Dave Close, Compata, Irvine CA "'Always' and 'never' are two d...@compata.com, +1 714 434 7359words you should always remember dhcl...@alumni.caltech.edu never to use." --Wendell Johnson -- ___ 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 too small
Poking about I see that the default workstation disk layout: https://docs.fedoraproject.org/en-US/workstation-docs/disk-config/ has /boot on a ext4 partition and everything else on btrfs. Also, the replacement for Anaconda will not happen until Fedora 41: https://forums.fedoraforum.org/showthread.php?332111-Fedora-40-will-remain-with-existing-anaconda So, are you saying that with Fedora 41, it will be the default for the /boot partition to use btrfs? Or, is this something that works for you? Thanks. Richard On 5/14/24 3:38 PM, Michal Schorm wrote: On Tue, May 14, 2024 at 8:13 PM Tim via users wrote: Does /boot still need to be its own partition, these days? /boot/efi has to be, but that's mapped into /boot, already. Definitely not. And it actually creates all kinds of problems when separated. The best *trivial* setup and usage should be having everything on BTRFS (except EFI, as you said), and maintain some amount of snapshots you can revert to anytime in case of any issues. When /boot is on the BTRFS, the snapshot contains the whole system, and ensures bootability of the snapshots. When /boot is on a standalone partition, the snapshot contains kernel modules, but not the actual kernel. When booting a new kernel (from /boot) with old kernel modules (from the snapshot), the modules can't be loaded, leaving you with a kind of crippled system. (bootable, but only partly usable) Which is far from what people would usually expect. -- A better, but more complicated setup consists of various snapshots of various subvolumes which are mounted to various locations. (e.g. standalone subvolumes for /home, games, backups, ... whatever) Often managed by some software (snapper, timeshit, ... not sure about the specific names), rather than the btrfs commands themselves. -- I managed to craft a setup that changes which snapshot (or which OS) will boot by changing just a single symlink. That too would be (likely ?) impossible with /boot on a separate partition. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, May 14, 2024 at 8:13 PM Tim via users wrote: On Tue, 2024-05-14 at 08:27 -0700, richard emberson wrote: Back on 05/03/2024 I posted the question: "How to increase size of /boot partition" I had the same problem. As was noted by some, I had not upgraded for a long, long time: "This type of layout and partition sizes is ancient. /tmp isn't even a partition now." Does /boot still need to be its own partition, these days? /boot/efi has to be, but that's mapped into /boot, already. -- 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 -- ___ 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 -- ___ 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 too small
On Tue, May 14, 2024 at 8:13 PM Tim via users wrote: > Does /boot still need to be its own partition, these days? > /boot/efi has to be, but that's mapped into /boot, already. Definitely not. And it actually creates all kinds of problems when separated. The best *trivial* setup and usage should be having everything on BTRFS (except EFI, as you said), and maintain some amount of snapshots you can revert to anytime in case of any issues. When /boot is on the BTRFS, the snapshot contains the whole system, and ensures bootability of the snapshots. When /boot is on a standalone partition, the snapshot contains kernel modules, but not the actual kernel. When booting a new kernel (from /boot) with old kernel modules (from the snapshot), the modules can't be loaded, leaving you with a kind of crippled system. (bootable, but only partly usable) Which is far from what people would usually expect. -- A better, but more complicated setup consists of various snapshots of various subvolumes which are mounted to various locations. (e.g. standalone subvolumes for /home, games, backups, ... whatever) Often managed by some software (snapper, timeshit, ... not sure about the specific names), rather than the btrfs commands themselves. -- I managed to craft a setup that changes which snapshot (or which OS) will boot by changing just a single symlink. That too would be (likely ?) impossible with /boot on a separate partition. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, May 14, 2024 at 8:13 PM Tim via users wrote: > > On Tue, 2024-05-14 at 08:27 -0700, richard emberson wrote: > > Back on 05/03/2024 I posted the question: > >"How to increase size of /boot partition" > > I had the same problem. > > > > As was noted by some, I had not upgraded for a long, long time: > >"This type of layout and partition sizes is ancient. /tmp isn't even a > > partition now." > > Does /boot still need to be its own partition, these days? > > /boot/efi has to be, but that's mapped into /boot, already. > > > -- > > 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 -- ___ 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 too small
On Tue, 2024-05-14 at 08:27 -0700, richard emberson wrote: > Back on 05/03/2024 I posted the question: > "How to increase size of /boot partition" > I had the same problem. > > As was noted by some, I had not upgraded for a long, long time: > "This type of layout and partition sizes is ancient. /tmp isn't even a > partition now." Does /boot still need to be its own partition, these days? /boot/efi has to be, but that's mapped into /boot, already. -- 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 too small
Back on 05/03/2024 I posted the question: "How to increase size of /boot partition" I had the same problem. As was noted by some, I had not upgraded for a long, long time: "This type of layout and partition sizes is ancient. /tmp isn't even a partition now." So, I decided to re-install. I pretty much used the installation default partitioning except that I made /boot 2GB (a little future proofing). This also allowed me to go from ext4 to btrfs (except /boot of course). Richard On 5/14/24 12:38 AM, Patrick Dupre via users wrote: Hello, During an update, I get Error Summary - Disk Requirements: At least 7MB more space needed on the /boot filesystem. How can I fix it without currently resizing /boot? Thank drwx--. 5 root root 4096 May 14 08:36 grub2 lrwxrwxrwx. 1 root root45 Mar 7 13:24 symvers-6.7.7-100.fc38.x86_64.xz -> /lib /modules/6.7.7-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81850041 Mar 7 13:24 initramfs-6.7.7-100.fc38.x86_64.img -rw-r--r--. 1 root root269378 Mar 1 01:00 config-6.7.7-100.fc38.x86_64 -rw-r--r--. 1 root root 8851783 Mar 1 01:00 System.map-6.7.7-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14794568 Mar 1 01:00 vmlinuz-6.7.7-100.fc38.x86_64 lrwxrwxrwx. 1 root root45 Feb 13 17:38 symvers-6.7.4-100.fc38.x86_64.xz -> /lib /modules/6.7.4-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81905180 Feb 13 17:37 initramfs-6.7.4-100.fc38.x86_64.img -rw-r--r--. 1 root root269327 Feb 5 01:00 config-6.7.4-100.fc38.x86_64 -rw-r--r--. 1 root root 8850577 Feb 5 01:00 System.map-6.7.4-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14806856 Feb 5 01:00 vmlinuz-6.7.4-100.fc38.x86_64 lrwxrwxrwx. 1 root root46 Jan 25 13:39 symvers-6.6.13-100.fc38.x86_64.xz -> /li b/modules/6.6.13-100.fc38.x86_64/symvers.xz -rw---. 1 root root 42503616 Jan 25 13:39 initramfs-6.6.13-100.fc38.x86_64.img -rw-r--r--. 1 root root266375 Jan 20 01:00 config-6.6.13-100.fc38.x86_64 -rw---. 1 root root 8786049 Jan 20 01:00 System.map-6.6.13-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14676712 Jan 20 01:00 vmlinuz-6.6.13-100.fc38.x86_64 -rw-r--r--. 1 root root147744 Jan 7 01:00 memtest86+x64.bin drwx--. 4 root root 4096 Jun 20 2023 efi drwxr-xr-x. 2 root root 4096 Jun 20 2023 extlinux -rw---. 1 root root 103940590 Jul 21 2022 initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img -rwxr-xr-x. 1 root root 11802352 Jul 21 2022 vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 drwxr-xr-x. 3 root root 4096 Jul 21 2022 loader drwx--. 2 root root 16384 Jul 21 2022 lost+found === Patrick DUPRÉ | | email: pdu...@gmx.com === -- ___ 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 -- ___ 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 too small
Note sure this with post to list with the Bold marked text, but sending it to your email as well. If list rejects it will repost without Rich Text, and Perhaps mark lines with (B) that were bold?? Good Luck. A couple of things I would recommend. Have an old Lenovo R61 notebook that also has a 500M boot so changed the installonly reduced by at least 1 from the default 3. First change /etc/dnf/dnf.conf to have installonly_limit=2 Then would remove the rescue kernel files since those are the largest and probable least useful. Probable just move them to another partition that has space. Pulled data from email and put in spreadsheet and changed size to ~MB and name. Would remove or move these files to another partition with space. That would leave the latest 2 kernels. 99 initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf4 78 initramfs-6.7.4-100.fc38.x86_64.img 78 initramfs-6.7.7-100.fc38.x86_64.img 40 initramfs-6.6.13-100.fc38.x86_64.img 14 vmlinuz-6.7.4-100.fc38.x86_64 14 vmlinuz-6.7.7-100.fc38.x86_64 13 vmlinuz-6.6.13-100.fc38.x86_64 11 vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 8 System.map-6.7.7-100.fc38.x86_64 8 System.map-6.7.4-100.fc38.x86_64 8 System.map-6.6.13-100.fc38.x86_64 0 config-6.7.7-100.fc38.x86_64 0 config-6.7.4-100.fc38.x86_64 0 config-6.6.13-100.fc38.x86_64 That should make lots of space. The recue kernel would probable be rebuilt on next kernel update or dnf reinstall kernel-core. Unless you have disabled that?? ++ Michael D. Setzer II - Computer Science Instructor (Retired) mailto:mi...@guam.net mailto:msetze...@gmail.com mailto:msetze...@gmx.com Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ ++ -- ___ 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 too small
On Tue, May 14, 2024 at 3:38 AM Patrick Dupre via users < users@lists.fedoraproject.org> wrote: > Hello, > > During an update, I get > > Error Summary > - > Disk Requirements: >At least 7MB more space needed on the /boot filesystem. > > > How can I fix it without currently resizing /boot? > Remove old kernels. Something like `dnf remove kernel-*6.6.13-100*` and `dnf remove kernel-*6.7.4-100*`. You could also delete the rescue kernel and regenerate it later. Something like `rm /boot/*rescue*`. > drwx--. 5 root root 4096 May 14 08:36 grub2 > lrwxrwxrwx. 1 root root45 Mar 7 13:24 > symvers-6.7.7-100.fc38.x86_64.xz -> /lib > /modules/6.7.7-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 81850041 Mar 7 13:24 > initramfs-6.7.7-100.fc38.x86_64.img > -rw-r--r--. 1 root root269378 Mar 1 01:00 config-6.7.7-100.fc38.x86_64 > -rw-r--r--. 1 root root 8851783 Mar 1 01:00 > System.map-6.7.7-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14794568 Mar 1 01:00 > vmlinuz-6.7.7-100.fc38.x86_64 > lrwxrwxrwx. 1 root root45 Feb 13 17:38 > symvers-6.7.4-100.fc38.x86_64.xz -> /lib > /modules/6.7.4-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 81905180 Feb 13 17:37 > initramfs-6.7.4-100.fc38.x86_64.img > -rw-r--r--. 1 root root269327 Feb 5 01:00 config-6.7.4-100.fc38.x86_64 > -rw-r--r--. 1 root root 8850577 Feb 5 01:00 > System.map-6.7.4-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14806856 Feb 5 01:00 > vmlinuz-6.7.4-100.fc38.x86_64 > lrwxrwxrwx. 1 root root46 Jan 25 13:39 > symvers-6.6.13-100.fc38.x86_64.xz -> /li > b/modules/6.6.13-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 42503616 Jan 25 13:39 > initramfs-6.6.13-100.fc38.x86_64.img > -rw-r--r--. 1 root root266375 Jan 20 01:00 > config-6.6.13-100.fc38.x86_64 > -rw---. 1 root root 8786049 Jan 20 01:00 > System.map-6.6.13-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14676712 Jan 20 01:00 > vmlinuz-6.6.13-100.fc38.x86_64 > -rw-r--r--. 1 root root147744 Jan 7 01:00 memtest86+x64.bin > drwx--. 4 root root 4096 Jun 20 2023 efi > drwxr-xr-x. 2 root root 4096 Jun 20 2023 extlinux > -rw---. 1 root root 103940590 Jul 21 2022 > initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img > -rwxr-xr-x. 1 root root 11802352 Jul 21 2022 > vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 > > drwxr-xr-x. 3 root root 4096 Jul 21 2022 loader > drwx--. 2 root root 16384 Jul 21 2022 lost+found > Jeff -- ___ 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 too small
df -h /boot Filesystem Size Used Avail Use% Mounted on /dev/sda6 488M 445M 6.5M 99% /boot Sent: Tuesday, May 14, 2024 at 10:02 AM From: "Barry Scott" To: "Community support for Fedora users" Cc: "Patrick Dupre" Subject: Re: /boot too small On 14 May 2024, at 08:38, Patrick Dupre via users wrote: How can I fix it without currently resizing /boot? How big is your /boot? What does this report? df -h /boot If its 1GB then that should be lots of space and its worth checking where the space has been used up. Have a look with ncdu or du to see what directories are taking up the space. There have been people that reported full /boot and found unexpected backup files in there. Barry -- ___ 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 too small
> On 14 May 2024, at 08:38, Patrick Dupre via users > wrote: > > How can I fix it without currently resizing /boot? How big is your /boot? What does this report? df -h /boot If its 1GB then that should be lots of space and its worth checking where the space has been used up. Have a look with ncdu or du to see what directories are taking up the space. There have been people that reported full /boot and found unexpected backup files in there. Barry -- ___ 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 too small
On 14/05/2024 08:54, Michal Schorm wrote: Hi, for an immediate workaround, remove the oldest kernel. Here are the steps together with an example output: 1) List installed kernel-core packages: # rpm -qa | grep kernel-core | sort kernel-core-6.8.4-200.fc39.x86_64 kernel-core-6.8.6-200.fc39.x86_64 kernel-core-6.8.7-200.fc39.x86_64 2) Remove the oldest one # dnf remove Dependencies resolved. PackageArch Version Repository Size Removing: kernel-corex86_64 6.8.4-200.fc39@updates66 M Removing dependent packages: kernel x86_64 6.8.4-200.fc39@updates 0 kernel-modules x86_64 6.8.4-200.fc39@updates58 M kernel-modules-corex86_64 6.8.4-200.fc39@updates32 M kernel-modules-extra x86_64 6.8.4-200.fc39@updates 2.4 M Transaction Summary Remove 5 Packages Freed space: 159 M 3) profit you have extra ~160 MB now. System update should have enough space to install the new kernel now. 4) Once finished, I'd recommend you to try to enlarge your /boot/ partition a bit (e.g. 100 - 500 MB ?) to avoid this problem permanently. Michal Schorm Software Engineer Core Services - Databases Team Red Hat I had the same problem a few days ago and did the same. I posted this reply but HyperKitty doesn't find it. So.. But I installed f40 a few days ago, and today "dnf upgrade" installed kernel-6.8.8 but *not* vmlinuz-6.8.8, so booting failed. My /boot partition is 450 GB, and I now have two bootable f40 kernels and a recent rescue kernel. There's no room for another. You probably don't have a "recovery" option. I now have "installonly_limit=2" in /etc/dnf/dnf.conf, but a new "dnf upgrade" after that said there was "nothing to do". What did work was ( while running 6.8.7): sudo dnf remove kernel-core-6.8.8 sudo dnf upgrade and then when "systemctl list-jobs" was clear, "sudo systemctl reboot" I, too, would prefer to have a bigger /boot, but this info might help. John P -- On Tue, May 14, 2024 at 9:44 AM Patrick Dupre via users wrote: Hello, During an update, I get Error Summary - Disk Requirements: At least 7MB more space needed on the /boot filesystem. How can I fix it without currently resizing /boot? Thank drwx--. 5 root root 4096 May 14 08:36 grub2 lrwxrwxrwx. 1 root root45 Mar 7 13:24 symvers-6.7.7-100.fc38.x86_64.xz -> /lib /modules/6.7.7-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81850041 Mar 7 13:24 initramfs-6.7.7-100.fc38.x86_64.img -rw-r--r--. 1 root root269378 Mar 1 01:00 config-6.7.7-100.fc38.x86_64 -rw-r--r--. 1 root root 8851783 Mar 1 01:00 System.map-6.7.7-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14794568 Mar 1 01:00 vmlinuz-6.7.7-100.fc38.x86_64 lrwxrwxrwx. 1 root root45 Feb 13 17:38 symvers-6.7.4-100.fc38.x86_64.xz -> /lib /modules/6.7.4-100.fc38.x86_64/symvers.xz -rw---. 1 root root 81905180 Feb 13 17:37 initramfs-6.7.4-100.fc38.x86_64.img -rw-r--r--. 1 root root269327 Feb 5 01:00 config-6.7.4-100.fc38.x86_64 -rw-r--r--. 1 root root 8850577 Feb 5 01:00 System.map-6.7.4-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14806856 Feb 5 01:00 vmlinuz-6.7.4-100.fc38.x86_64 lrwxrwxrwx. 1 root root46 Jan 25 13:39 symvers-6.6.13-100.fc38.x86_64.xz -> /li b/modules/6.6.13-100.fc38.x86_64/symvers.xz -rw---. 1 root root 42503616 Jan 25 13:39 initramfs-6.6.13-100.fc38.x86_64.img -rw-r--r--. 1 root root266375 Jan 20 01:00 config-6.6.13-100.fc38.x86_64 -rw---. 1 root root 8786049 Jan 20 01:00 System.map-6.6.13-100.fc38.x86_64 -rwxr-xr-x. 1 root root 14676712 Jan 20 01:00 vmlinuz-6.6.13-100.fc38.x86_64 -rw-r--r--. 1 root root147744 Jan 7 01:00 memtest86+x64.bin drwx--. 4 root root 4096 Jun 20 2023 efi drwxr-xr-x. 2 root root 4096 Jun 20 2023 extlinux -rw---. 1 root root 103940590 Jul 21 2022 initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img -rwxr-xr-x. 1 root root 11802352 Jul 21 2022 vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 drwxr-xr-x. 3 root root 4096 Jul 21 2022 loader drwx--. 2 root root 16384 Jul 21 2022 lost+found === Patrick DUPRÉ | | email: pdu...@gmx.com === -- -- ___ 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:
Re: /boot too small
Hi, for an immediate workaround, remove the oldest kernel. Here are the steps together with an example output: 1) List installed kernel-core packages: # rpm -qa | grep kernel-core | sort kernel-core-6.8.4-200.fc39.x86_64 kernel-core-6.8.6-200.fc39.x86_64 kernel-core-6.8.7-200.fc39.x86_64 2) Remove the oldest one # dnf remove Dependencies resolved. PackageArch Version Repository Size Removing: kernel-corex86_64 6.8.4-200.fc39@updates66 M Removing dependent packages: kernel x86_64 6.8.4-200.fc39@updates 0 kernel-modules x86_64 6.8.4-200.fc39@updates58 M kernel-modules-corex86_64 6.8.4-200.fc39@updates32 M kernel-modules-extra x86_64 6.8.4-200.fc39@updates 2.4 M Transaction Summary Remove 5 Packages Freed space: 159 M 3) profit you have extra ~160 MB now. System update should have enough space to install the new kernel now. 4) Once finished, I'd recommend you to try to enlarge your /boot/ partition a bit (e.g. 100 - 500 MB ?) to avoid this problem permanently. -- Michal Schorm Software Engineer Core Services - Databases Team Red Hat -- On Tue, May 14, 2024 at 9:44 AM Patrick Dupre via users wrote: > > Hello, > > During an update, I get > > Error Summary > - > Disk Requirements: >At least 7MB more space needed on the /boot filesystem. > > > How can I fix it without currently resizing /boot? > Thank > > drwx--. 5 root root 4096 May 14 08:36 grub2 > lrwxrwxrwx. 1 root root45 Mar 7 13:24 > symvers-6.7.7-100.fc38.x86_64.xz -> /lib > /modules/6.7.7-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 81850041 Mar 7 13:24 > initramfs-6.7.7-100.fc38.x86_64.img > -rw-r--r--. 1 root root269378 Mar 1 01:00 config-6.7.7-100.fc38.x86_64 > -rw-r--r--. 1 root root 8851783 Mar 1 01:00 > System.map-6.7.7-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14794568 Mar 1 01:00 vmlinuz-6.7.7-100.fc38.x86_64 > lrwxrwxrwx. 1 root root45 Feb 13 17:38 > symvers-6.7.4-100.fc38.x86_64.xz -> /lib > /modules/6.7.4-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 81905180 Feb 13 17:37 > initramfs-6.7.4-100.fc38.x86_64.img > -rw-r--r--. 1 root root269327 Feb 5 01:00 config-6.7.4-100.fc38.x86_64 > -rw-r--r--. 1 root root 8850577 Feb 5 01:00 > System.map-6.7.4-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14806856 Feb 5 01:00 vmlinuz-6.7.4-100.fc38.x86_64 > lrwxrwxrwx. 1 root root46 Jan 25 13:39 > symvers-6.6.13-100.fc38.x86_64.xz -> /li > b/modules/6.6.13-100.fc38.x86_64/symvers.xz > -rw---. 1 root root 42503616 Jan 25 13:39 > initramfs-6.6.13-100.fc38.x86_64.img > -rw-r--r--. 1 root root266375 Jan 20 01:00 config-6.6.13-100.fc38.x86_64 > -rw---. 1 root root 8786049 Jan 20 01:00 > System.map-6.6.13-100.fc38.x86_64 > -rwxr-xr-x. 1 root root 14676712 Jan 20 01:00 vmlinuz-6.6.13-100.fc38.x86_64 > -rw-r--r--. 1 root root147744 Jan 7 01:00 memtest86+x64.bin > drwx--. 4 root root 4096 Jun 20 2023 efi > drwxr-xr-x. 2 root root 4096 Jun 20 2023 extlinux > -rw---. 1 root root 103940590 Jul 21 2022 > initramfs-0-rescue-c60d54440c4d444a9eb5a084a65edf40.img > -rwxr-xr-x. 1 root root 11802352 Jul 21 2022 > vmlinuz-0-rescue-c60d54440c4d444a9eb5a084a65edf40 > > drwxr-xr-x. 3 root root 4096 Jul 21 2022 loader > drwx--. 2 root root 16384 Jul 21 2022 lost+found > > > === > Patrick DUPRÉ | | email: pdu...@gmx.com > === > -- > ___ > 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 -- ___ 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
