Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #225754 > unrolled thread

Enlarging /boot

Back to article view | Back to linux.debian.user

Contents

  Enlarging /boot Erwan David <erwan@rail.eu.org> - 2020-08-02 22:40 +0200
    Re: Enlarging /boot Leslie Rhorer <lesrhorer@att.net> - 2020-08-02 23:50 +0200
      Re: Enlarging /boot Erwan David <erwan@rail.eu.org> - 2020-08-03 08:40 +0200
        Re: Enlarging /boot Andrew Cater <amacater@gmail.com> - 2020-08-03 09:50 +0200
          Re: Enlarging /boot Leslie Rhorer <lesrhorer@att.net> - 2020-08-04 00:20 +0200
        Re: Enlarging /boot David Wright <deblis@lionunicorn.co.uk> - 2020-08-03 18:30 +0200
    Re: Enlarging /boot Doug McGarrett <dmcgarrett@optonline.net> - 2020-08-02 23:50 +0200
      Re: Enlarging /boot Leslie Rhorer <lesrhorer@att.net> - 2020-08-03 00:00 +0200
    Re: Enlarging /boot David Wright <deblis@lionunicorn.co.uk> - 2020-08-03 05:40 +0200
    Re: Enlarging /boot didier.gaumet@gmail.com - 2020-08-03 10:10 +0200

#225754 — Enlarging /boot

I used the buster installer about 1 year ago,with a fully encrypted
disk, thus

a /boot/efi partition, a /boot partition then an encrypted lvm.

/boot is now not large enough to even have 2 kernels on it,
initramfs-tools cannot create the images.

I see this
/dev/nvme0n1p2                     237M   92M  133M  41% /boot
/dev/nvme0n1p1                     511M  5.3M  506M   2% /boot/efi

Is it possible to reduce /boot/efi and have some more room for /boot, or
should I reinstall the computer ?

[toc] | [next] | [standalone]

#225757

On 8/2/2020 3:32 PM, Erwan David wrote:
> I used the buster installer about 1 year ago,with a fully encrypted
> disk, thus
> 
> a /boot/efi partition, a /boot partition then an encrypted lvm.
> 
> /boot is now not large enough to even have 2 kernels on it,
> initramfs-tools cannot create the images.
> 
> I see this
> /dev/nvme0n1p2                     237M   92M  133M  41% /boot
> /dev/nvme0n1p1                     511M  5.3M  506M   2% /boot/efi
> 
> Is it possible to reduce /boot/efi and have some more room for /boot, or
> should I reinstall the computer ?

	Um, the kernel is only about 5M in size.  With 133M free, there should 
be plenty of room for multiple kernels.  The initrd image is usually 
under 40M, so there should be room for the entire boot image to be 
duplicated.  Note the current use is only 41%.  You shouldn't need more 
space, per se, except that normally the initrd is temporarily 
uncompressed while it is being created.  I think you could get around 
this by employing chroot.

	To answer your question, I am given to understand /boot/efi is a vfat 
file system, so it should be possible to shrink it, move the /boot 
partition, and then expand it.

[toc] | [prev] | [next] | [standalone]

#225769

Le 02/08/2020 à 23:48, Leslie Rhorer a écrit :
> On 8/2/2020 3:32 PM, Erwan David wrote:
>> I used the buster installer about 1 year ago,with a fully encrypted
>> disk, thus
>>
>> a /boot/efi partition, a /boot partition then an encrypted lvm.
>>
>> /boot is now not large enough to even have 2 kernels on it,
>> initramfs-tools cannot create the images.
>>
>> I see this
>> /dev/nvme0n1p2                     237M   92M  133M  41% /boot
>> /dev/nvme0n1p1                     511M  5.3M  506M   2% /boot/efi
>>
>> Is it possible to reduce /boot/efi and have some more room for /boot, or
>> should I reinstall the computer ?
> 
>     Um, the kernel is only about 5M in size.  With 133M free, there
> should be plenty of room for multiple kernels.  The initrd image is
> usually under 40M, so there should be room for the entire boot image to
> be duplicated.  Note the current use is only 41%.  You shouldn't need
> more space, per se, except that normally the initrd is temporarily
> uncompressed while it is being created.  I think you could get around
> this by employing chroot.

My initrd is 69 M...

>     To answer your question, I am given to understand /boot/efi is a
> vfat file system, so it should be possible to shrink it, move the /boot
> partition, and then expand it.

However both /boot/efi and /boot are critoical for the booting process,
thus my concerns.

[toc] | [prev] | [next] | [standalone]

#225770

[Multipart message — attachments visible in raw view] — view raw

If you have room for two kernels and you are booting from the newest one:
potentially, you can remove the older one to gain some space. If apt update
installs another kernel of the same version so you have two 4.19 - reboot
when the apt run finishes, make sure that the new kernel boots and runs
fine, then remove the older one. The trick is to check that you are booting
from the latest version - you don't want to remove a running kernel :(

On Mon, Aug 3, 2020 at 6:39 AM Erwan David <erwan@rail.eu.org> wrote:

> Le 02/08/2020 à 23:48, Leslie Rhorer a écrit :
> > On 8/2/2020 3:32 PM, Erwan David wrote:
> >> I used the buster installer about 1 year ago,with a fully encrypted
> >> disk, thus
> >>
> >> a /boot/efi partition, a /boot partition then an encrypted lvm.
> >>
> >> /boot is now not large enough to even have 2 kernels on it,
> >> initramfs-tools cannot create the images.
> >>
> >> I see this
> >> /dev/nvme0n1p2                     237M   92M  133M  41% /boot
> >> /dev/nvme0n1p1                     511M  5.3M  506M   2% /boot/efi
> >>
> >> Is it possible to reduce /boot/efi and have some more room for /boot, or
> >> should I reinstall the computer ?
> >
> >     Um, the kernel is only about 5M in size.  With 133M free, there
> > should be plenty of room for multiple kernels.  The initrd image is
> > usually under 40M, so there should be room for the entire boot image to
> > be duplicated.  Note the current use is only 41%.  You shouldn't need
> > more space, per se, except that normally the initrd is temporarily
> > uncompressed while it is being created.  I think you could get around
> > this by employing chroot.
>
> My initrd is 69 M...
>
> >     To answer your question, I am given to understand /boot/efi is a
> > vfat file system, so it should be possible to shrink it, move the /boot
> > partition, and then expand it.
>
> However both /boot/efi and /boot are critoical for the booting process,
> thus my concerns.
>
>
>

[toc] | [prev] | [next] | [standalone]

#225795

On 8/3/2020 2:49 AM, Andrew Cater wrote:
> If you have room for two kernels and you are booting from the newest 
> one: potentially, you can remove the older one to gain some space. If 
> apt update installs another kernel of the same version so you have two 
> 4.19 - reboot when the apt run finishes, make sure that the new kernel 
> boots and runs fine, then remove the older one. The trick is to check 
> that you are booting from the latest version - you don't want to remove 
> a running kernel :(

	That is not quite accurate.  One the kernel is loaded, it can be moved, 
removed, or updated.  The machine does not care.  If it is no longer 
available where the boot system expects to find it, then it must be 
replaced and if necessary the boot system must be updated t point to the 
new kernel before the machine can boot again using the existing boot 
system.  Generally, the machine can be booted using a different system, 
such as a live CD, for example, even if the existing boot system is broken.

>      > ????????Um, the kernel is only about 5M in size.?? With 133M free, there
>      > should be plenty of room for multiple kernels.?? The initrd image is
>      > usually under 40M, so there should be room for the entire boot
>     image to
>      > be duplicated.?? Note the current use is only 41%.?? You shouldn't need
>      > more space, per se, except that normally the initrd is temporarily
>      > uncompressed while it is being created.?? I think you could get around
>      > this by employing chroot.
> 
>     My initrd is 69 M...

	That is pretty typical.


>      > ????????To answer your question, I am given to understand /boot/efi is a
>      > vfat file system, so it should be possible to shrink it, move the
>     /boot
>      > partition, and then expand it.
> 
>     However both /boot/efi and /boot are critoical for the booting process,
>     thus my concerns.

	Yes, and it is also one reason why I think using chroot to create 
virtual environment on a larger file system and then copying the result 
over to the existing partition might be a better, safer solution for 
someone not well experienced in managing the boot process.

[toc] | [prev] | [next] | [standalone]

#225779

On Mon 03 Aug 2020 at 08:38:55 (+0200), Erwan David wrote:
> Le 02/08/2020 à 23:48, Leslie Rhorer a écrit :
> > On 8/2/2020 3:32 PM, Erwan David wrote:
> >> I used the buster installer about 1 year ago,with a fully encrypted
> >> disk, thus
> >>
> >> a /boot/efi partition, a /boot partition then an encrypted lvm.
> >>
> >> /boot is now not large enough to even have 2 kernels on it,
> >> initramfs-tools cannot create the images.
> >>
> >> I see this
> >> /dev/nvme0n1p2                     237M   92M  133M  41% /boot
> >> /dev/nvme0n1p1                     511M  5.3M  506M   2% /boot/efi
> >>
> >> Is it possible to reduce /boot/efi and have some more room for /boot, or
> >> should I reinstall the computer ?
> > 
> >     Um, the kernel is only about 5M in size.  With 133M free, there
> > should be plenty of room for multiple kernels.  The initrd image is
> > usually under 40M, so there should be room for the entire boot image to
> > be duplicated.  Note the current use is only 41%.  You shouldn't need
> > more space, per se, except that normally the initrd is temporarily
> > uncompressed while it is being created.  I think you could get around
> > this by employing chroot.
> 
> My initrd is 69 M...

In the absence of # du -sh /boot/*/ ; ls -l /boot/
that's a help. So you likely have one of System.map, config,
initrd.img and vmlinuz in /boot.

As long as you have other means of booting the system, you could try
copying initrd.img to a backup, and rebuilding it with MODULES=dep
in /etc/initramfs-tools/initramfs.conf, and see how much space that
would save. If you can still boot successfully with the dep version,
then you might have room now to install a second kernel, even with
MODULES=most restored.

It does make future upgrades a little more tedious.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#225758

On 8/2/20 4:32 PM, Erwan David wrote:
> I used the buster installer about 1 year ago,with a fully encrypted
> disk, thus
>
> a /boot/efi partition, a /boot partition then an encrypted lvm.
>
> /boot is now not large enough to even have 2 kernels on it,
> initramfs-tools cannot create the images.
>
> I see this
> /dev/nvme0n1p2                     237M   92M  133M  41% /boot
> /dev/nvme0n1p1                     511M  5.3M  506M   2% /boot/efi
>
> Is it possible to reduce /boot/efi and have some more room for /boot, or
> should I reinstall the computer ?
Perhaps you can make the partition larger, using an external version of 
gparted.
Download gparted and burn it to a cd or a bootable usb stick and make the
partition bigger. This will not destroy the data on the partition, but 
it can
give you as much extra space as you need. You will, of course, have to
shrink the partition that is next on the drive to make room for this 
operation.
You can do that without losing data on the other partition, assuming it is
not already full. gparted will caution you about the possible loss of data,
but typically there is no loss in doing these operations. These functions
will take a few minutes, so be patient.
--doug
>
>
>

[toc] | [prev] | [next] | [standalone]

#225759

On 8/2/2020 4:45 PM, Doug McGarrett wrote:
> On 8/2/20 4:32 PM, Erwan David wrote:
>> I used the buster installer about 1 year ago,with a fully encrypted
>> disk, thus
>>
>> a /boot/efi partition, a /boot partition then an encrypted lvm.
>>
>> /boot is now not large enough to even have 2 kernels on it,
>> initramfs-tools cannot create the images.
>>
>> I see this
>> /dev/nvme0n1p2                     237M   92M  133M  41% /boot
>> /dev/nvme0n1p1                     511M  5.3M  506M   2% /boot/efi
>>
>> Is it possible to reduce /boot/efi and have some more room for /boot, or
>> should I reinstall the computer ?
> Perhaps you can make the partition larger, using an external version of 
> gparted.
> Download gparted and burn it to a cd or a bootable usb stick and make the
> partition bigger. This will not destroy the data on the partition, but 
> it can
> give you as much extra space as you need. You will, of course, have to
> shrink the partition that is next on the drive to make room for this 
> operation.
> You can do that without losing data on the other partition, assuming it is
> not already full. gparted will caution you about the possible loss of data,
> but typically there is no loss in doing these operations. These functions
> will take a few minutes, so be patient.

	First - and this is *VERY* important - back up the data in both 
partitions.  They are both small so backing them up is not onerous.  I 
would munt (or remount) both partitions as read-only, and then copy 
everything on the partitions to separate files.

	Using a chroot is probably less dangerous, if the OP is something of a 
newbie.

[toc] | [prev] | [next] | [standalone]

#225763

On Sun 02 Aug 2020 at 22:32:50 (+0200), Erwan David wrote:
> I used the buster installer about 1 year ago,with a fully encrypted
> disk, thus
> 
> a /boot/efi partition, a /boot partition then an encrypted lvm.
> 
> /boot is now not large enough to even have 2 kernels on it,
> initramfs-tools cannot create the images.
> 
> I see this
> /dev/nvme0n1p2                     237M   92M  133M  41% /boot
> /dev/nvme0n1p1                     511M  5.3M  506M   2% /boot/efi

That looks reasonable. Can we see too? Please show us

# du -sh /boot/*/
# ls -l /boot/

> Is it possible to reduce /boot/efi and have some more room for /boot, or
> should I reinstall the computer ?

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#225771

Hello,

If I understand correctly, it seems the minimum size (32MB, 100MB or 260MB) of the ESP depends on the sector logical and physical size of the disk:
 https://docs.microsoft.com/en-us/windows-hardware/manufacture/desktop/configure-uefigpt-based-hard-drive-partitions#diskpartitionrules
 https://en.wikipedia.org/wiki/Advanced_Format#Categories

fdisk ou parted will inform you of these sizes

In my case:

didier@hp-notebook14:~$ sudo parted -l 
[...]
Model: CT500P1SSD8 (nvme)
Disk /dev/nvme0n1: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                          Flags
 1      17,4kB  16,8MB  16,8MB               Microsoft reserved partition  msftres
 2      16,8MB  571MB   555MB   ntfs         Basic data partition          hidden, diag
 3      571MB   676MB   105MB   fat32        EFI system partition          boot, esp
 4      676MB   52,4GB  51,8GB  ntfs         Basic data partition          msftdata
 5      52,4GB  53,1GB  700MB   ext4
 6      53,1GB  500GB   447GB                                              lvm

So my ESP has the minimum size for the sectors logical/physical size 
I am dual booting Debian 10 and Windows10

didier@hp-notebook14:~$ df /boot/efi
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
/dev/nvme0n1p3         98304   35864      62440  37% /boot/efi

IMO, you can safely reduce the size of your ESP

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web