/boot too small

[Patrick Dupre]

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 root        45 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 root    269378 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 root        45 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 root    269327 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 root        46 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 root    266375 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 root    147744 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: pdupre(a)gmx.com
===========================================================================

[Michal Schorm]

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 <oldest of the packages above>
Dependencies resolved.
====================================================================
 Package                Arch     Version           Repository  Size
====================================================================
Removing:
 kernel-core            x86_64   6.8.4-200.fc39    @updates    66 M
Removing dependent packages:
 kernel                 x86_64   6.8.4-200.fc39    @updates     0
 kernel-modules         x86_64   6.8.4-200.fc39    @updates    58 M
 kernel-modules-core    x86_64   6.8.4-200.fc39    @updates    32 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
<users(a)lists.fedoraproject.org&gt; 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 root        45 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 root    269378 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 root        45 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 root    269327 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 root        46 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 root    266375 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 root    147744 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: pdupre(a)gmx.com
>  ===========================================================================
>  --
>  _______________________________________________
>  users mailing list -- users(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[John Pilkington]

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 <oldest of the packages above>
>  Dependencies resolved.
>  ====================================================================
>    Package                Arch     Version           Repository  Size
>  ====================================================================
>  Removing:
>    kernel-core            x86_64   6.8.4-200.fc39    @updates    66 M
>  Removing dependent packages:
>    kernel                 x86_64   6.8.4-200.fc39    @updates     0
>    kernel-modules         x86_64   6.8.4-200.fc39    @updates    58 M
>    kernel-modules-core    x86_64   6.8.4-200.fc39    @updates    32 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
>  <users(a)lists.fedoraproject.org&gt; 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 root        45 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 root    269378 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 root        45 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 root    269327 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 root        46 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 root    266375 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 root    147744 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: pdupre(a)gmx.com
> > ===========================================================================
> > --

[Barry Scott]

>  On 14 May 2024, at 08:38, Patrick Dupre via users
> <users(a)lists.fedoraproject.org&gt; 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

[Jeffrey Walton]

On Tue, May 14, 2024 at 3:38 AM Patrick Dupre via users <
users(a)lists.fedoraproject.org&gt; 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 root        45 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 root    269378 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 root        45 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 root    269327 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 root        46 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 root    266375 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 root    147744 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

[Michael D. Setzer II]

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:[e-mail]                            
 mailto:[e-mail]
 mailto:[e-mail]
 Guam - Where America's Day Begins                        
 G4L Disk Imaging Project maintainer 
 http://sourceforge.net/projects/g4l/
+------------------------------------------------------------+

[richard emberson]

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 root        45 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 root    269378 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 root        45 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 root    269327 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 root        46 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 root    266375 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 root    147744 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: pdupre(a)gmx.com
> ===========================================================================
> --
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Tim]

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

[Michal Schorm]

On Tue, May 14, 2024 at 8:13 PM Tim via users
<users(a)lists.fedoraproject.org&gt; 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
<users(a)lists.fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to users-leave(a)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/[e-mail]
>  Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[richard emberson]

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-remai...

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
> <users(a)lists.fedoraproject.org&gt; 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
> <users(a)lists.fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>> To unsubscribe send an email to users-leave(a)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/[e-mail]
>> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
> --
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Michal Schorm]

On Wed, May 15, 2024 at 1:29 AM richard emberson
<emberson.rich(a)gmail.com&gt; 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-remai...
>
>  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
<emberson.rich(a)gmail.com&gt; 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-remai...
>
>  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
> > <users(a)lists.fedoraproject.org&gt; 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
> > <users(a)lists.fedoraproject.org&gt; 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(a)lists.fedoraproject.org
> >> To unsubscribe send an email to users-leave(a)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/[e-mail]
> >> Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
> > --
> > _______________________________________________
> > users mailing list -- users(a)lists.fedoraproject.org
> > To unsubscribe send an email to users-leave(a)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/[e-mail]
> > Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
> --
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Dave Close]

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
dave(a)compata.com, [phone]    words you should always remember
dhclose(a)alumni.caltech.edu           never to use." --Wendell Johnson

[Chris Adams]

Once upon a time, Michal Schorm <mschorm(a)redhat.com&gt; said:
>  On Tue, May 14, 2024 at 8:13 PM Tim via users
>  <users(a)lists.fedoraproject.org&gt; 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 <linux(a)cmadams.net&gt;

[Michal Schorm]

On Wed, May 15, 2024 at 1:45 AM Chris Adams <linux(a)cmadams.net&gt; wrote:
>  Once upon a time, Michal Schorm <mschorm(a)redhat.com&gt; said:
>  > On Tue, May 14, 2024 at 8:13 PM Tim via users
>  > <users(a)lists.fedoraproject.org&gt; 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 <linux(a)cmadams.net&gt; wrote:
>
>  Once upon a time, Michal Schorm <mschorm(a)redhat.com&gt; said:
>  > On Tue, May 14, 2024 at 8:13 PM Tim via users
>  > <users(a)lists.fedoraproject.org&gt; 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 <linux(a)cmadams.net&gt;
> --
> _______________________________________________
> users mailing list -- users(a)lists.fedoraproject.org
> To unsubscribe send an email to users-leave(a)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/[e-mail]
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue