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

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

Hmmm... /boot is too small. what's the best way to increase it's size?

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

Contents

  Hmmm... /boot is too small. what's the best way to increase it's size? "Rick Thomas" <rick.thomas@pobox.com> - 2020-05-10 05:30 +0200
    Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Andy Smith <andy@strugglers.net> - 2020-05-10 05:40 +0200
      Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Andy Smith <andy@strugglers.net> - 2020-05-10 05:50 +0200
      Re: Hmmm... /boot is too small. what's the best way to increase it's  size? The Wanderer <wanderer@fastmail.fm> - 2020-05-10 06:00 +0200
        Re: Hmmm... /boot is too small. what's the best way to increase it's  size? elvis <elvis@dogonfire.com> - 2020-05-11 07:50 +0200
    Re: Hmmm... /boot is too small. what's the best way to increase  it's size? Charles Curley <charlescurley@charlescurley.com> - 2020-05-10 06:40 +0200
      Re: Hmmm... /boot is too small. what's the best way to increase it's size? "Rick Thomas" <rick.thomas@pobox.com> - 2020-05-10 09:10 +0200
        Re: Hmmm... /boot is too small. what's the best way to increase it's size? "Rick Thomas" <rick.thomas@pobox.com> - 2020-05-10 11:30 +0200
          Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-10 12:30 +0200
            Re: Hmmm... /boot is too small. what's the best way to increase it's size? "Rick Thomas" <rick.thomas@pobox.com> - 2020-05-10 13:30 +0200
              Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-11 08:10 +0200
    Re: Hmmm... /boot is too small. what's the best way to increase it's  size? "Will Mengarini" <seldon@eskimo.com> - 2020-05-10 07:20 +0200
      Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-10 09:10 +0200
      Re: Hmmm... /boot is too small. what's the best way to increase it's size? "Rick Thomas" <rick.thomas@pobox.com> - 2020-05-10 09:20 +0200
      Re: Hmmm... /boot is too small. what's the best way to increase it's  size? David Christensen <dpchrist@holgerdanske.com> - 2020-05-10 10:20 +0200
        Re: Hmmm... /boot is too small. what's the best way to increase it's size? "Rick Thomas" <rick.thomas@pobox.com> - 2020-05-10 11:30 +0200
          Re: Hmmm... /boot is too small. what's the best way to increase it's size? rhkramer@gmail.com - 2020-05-10 14:00 +0200
          Re: Hmmm... /boot is too small. what's the best way to increase it's  size? David Christensen <dpchrist@holgerdanske.com> - 2020-05-10 21:40 +0200
            Re: Hmmm... /boot is too small. what's the best way to increase it's size? "Rick Thomas" <rick.thomas@pobox.com> - 2020-05-11 01:20 +0200
              Re: Hmmm... /boot is too small. what's the best way to increase it's  size? elvis <elvis@dogonfire.com> - 2020-05-11 07:40 +0200
              Re: Hmmm... /boot is too small. what's the best way to increase it's  size? David Christensen <dpchrist@holgerdanske.com> - 2020-05-11 09:40 +0200
            Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-11 08:20 +0200
              Re: Hmmm... /boot is too small. what's the best way to increase it's  size? David Christensen <dpchrist@holgerdanske.com> - 2020-05-11 10:20 +0200
                Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Andrei POPESCU <andreimpopescu@gmail.com> - 2020-05-11 15:10 +0200
          Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Tom Dial <tddial@comcast.net> - 2020-05-11 06:10 +0200
      Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Greg Wooledge <wooledg@eeg.ccf.org> - 2020-05-11 13:40 +0200
        Re: Hmmm... /boot is too small. what's the best way to increase  it's size? Celejar <celejar@gmail.com> - 2020-05-11 16:30 +0200
          Re: Hmmm... /boot is too small. what's the best way to increase it's  size? David Wright <deblis@lionunicorn.co.uk> - 2020-05-11 18:30 +0200
            Re: Hmmm... /boot is too small. what's the best way to increase  it's size? Celejar <celejar@gmail.com> - 2020-05-11 18:50 +0200
    Re: Hmmm... /boot is too small. what's the best way to increase it's  size? David Wright <deblis@lionunicorn.co.uk> - 2020-05-10 16:20 +0200
      Re: Hmmm... /boot is too small. what's the best way to increase it's size? Sven Hartge <sven@svenhartge.de> - 2020-05-10 16:40 +0200
        Re: Hmmm... /boot is too small. what's the best way to increase it's  size? David Wright <deblis@lionunicorn.co.uk> - 2020-05-10 17:20 +0200
    Re: Hmmm... /boot is too small. what's the best way to increase it's  size? Jonathan Dowland <jon+debian-user@dow.land> - 2020-05-14 11:30 +0200

Page 2 of 2 — ← Prev page 1 [2]

#222363 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On 2020-05-10 15:53, Rick Thomas wrote:
> 
> 
> On Sun, May 10, 2020, at 12:30 PM, David Christensen wrote:
> 
>> As for using GRML, I have never heard of it.  The Debian Installer can
>> get the job done.
> 
> GRML [1]  says: "Grml is a bootable live system (Live-CD) based on Debian. Grml includes a collection of GNU/Linux software especially for system administrators. Users don't have to install anything on fixed storage. Grml is especially well suited for administrative tasks like installation, deployment and system rescue. Read more..."
> 
> There's also Debian Live, which also has all the features I'll need to do a full backup, repartition, and restore.  The installer in rescue mode is more limited than either of these alternatives.

You are right -- I was focusing on the disk partitioning and Debian 
installation steps.  The d-i rescue shell has a limited set of tools for 
general system administration chores.


For "everything else", I install Debian onto a USB flash drive and then 
add my favorite packages, hosts file, profile, scripts, libraries, etc.. 
  This gives me the control and flexibility of a complete Debian system, 
and I don't have to climb yet another learning curve.


David

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

#222359 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

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

On Du, 10 mai 20, 12:30:29, David Christensen wrote:
> 
> As for using GRML, I have never heard of it.  The Debian Installer can get
> the job done.  That said, I have about a half dozen machines and have been
> feeling the need for installation and deployment automation. I have heard of
> Puppet more than once.  Lucas [1] recommends Ansible [2], so I will probably
> try that.

Puppet and ansible are for configuration management, you need something 
like FAI for installation.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#222367 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On 2020-05-10 23:12, Andrei POPESCU wrote:
> On Du, 10 mai 20, 12:30:29, David Christensen wrote:
>>
>> As for using GRML, I have never heard of it.  The Debian Installer can get
>> the job done.  That said, I have about a half dozen machines and have been
>> feeling the need for installation and deployment automation. I have heard of
>> Puppet more than once.  Lucas [1] recommends Ansible [2], so I will probably
>> try that.
> 
> Puppet and ansible are for configuration management, you need something
> like FAI for installation.

I am not doing "unattended mass deployment of Linux":

https://fai-project.org/


Running an installer (or restoring an image), booting the system, and 
then configuring the system over SSH is already part of my work flow. 
If Ansible can help me with the last step for Debian, FreeBSD, macOS, 
Windows, Linode, and potentially other operating systems, I would be 
happy.  But, I am not encouraged by all the RedHat marketing hype.


David

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

#222375 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

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

On Lu, 11 mai 20, 01:09:46, David Christensen wrote:
> On 2020-05-10 23:12, Andrei POPESCU wrote:
> > On Du, 10 mai 20, 12:30:29, David Christensen wrote:
> > > 
> > > As for using GRML, I have never heard of it.  The Debian Installer can get
> > > the job done.  That said, I have about a half dozen machines and have been
> > > feeling the need for installation and deployment automation. I have heard of
> > > Puppet more than once.  Lucas [1] recommends Ansible [2], so I will probably
> > > try that.
> > 
> > Puppet and ansible are for configuration management, you need something
> > like FAI for installation.

Just discovered vmdb2 which appears to combine nicely with ansible.

Kind regards,
Andrei
-- 
http://wiki.debian.org/FAQsFromDebianUser

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

#222355 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On 5/10/20 03:07, Rick Thomas wrote:
> On Sun, May 10, 2020, at 1:17 AM, David Christensen wrote:
>> On 2020-05-09 22:05, Will Mengarini wrote:
>>> * Rick Thomas <rick.thomas@pobox.com> [20-05/09=Sa 20:05 -0700]:
>>>> What's the best way to increase the size of /boot?
>>> By creating a reliable backup and reformatting the disk to
>>> the new format.  I've never found it to be cost-effective
>>> to try anything else. 
>> +1

As Charles Curley suggested, 248M usually is enough to hold a reasonable
number of kernels, configs, and initrd files, along with the contents of
/boot/grub. It might be worthwhile to examine it for extraneous files.

But if /boot turns out to need more space, you could unmount /dev/sda1
and /dev/sda2, remount /dev/sda2 on (for example) /mnt, move its
contents to /boot, remount /dev/sda1, and reinstall grub.

After finishing, you could make an LVM physical volume on /dev/sda2 and
add it to one of the other volume groups, although both seem to have
plenty of space.

Regards
Tom Dial

> 
> Yeah, that's probably what I'll do.  Fortunately, it's an amd64 machine, so I'll be able to use GRML to do the work.
> Enjoy!
> Rick
> 

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

#222373 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On Sat, May 09, 2020 at 10:05:40PM -0700, Will Mengarini wrote:
> * Rick Thomas <rick.thomas@pobox.com> [20-05/09=Sa 20:05 -0700]:
> > [...] died for lack of space in /boot [...]
> 
> Long ago I stopped bothering with a separate /boot, and behold, I yet
> live.  ISTR the Debian installer doesn't default to creating one either.

Unless you're doing some kind(s) of disk encryption.  Which apparently is
a thing that some laptop users go for in a major way.

As a non-laptop person, my understanding is that, at least with some
implementations of disk encryption, you need an UN-encrypted /boot to
get the whole thing started.  After that, the root file system and any
other local file systems can be encrypted, and the code from /boot will
be able to prompt you for the passphrase or whatever.

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

#222377 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On Mon, 11 May 2020 07:36:27 -0400
Greg Wooledge <wooledg@eeg.ccf.org> wrote:

> On Sat, May 09, 2020 at 10:05:40PM -0700, Will Mengarini wrote:
> > * Rick Thomas <rick.thomas@pobox.com> [20-05/09=Sa 20:05 -0700]:
> > > [...] died for lack of space in /boot [...]
> > 
> > Long ago I stopped bothering with a separate /boot, and behold, I yet
> > live.  ISTR the Debian installer doesn't default to creating one either.
> 
> Unless you're doing some kind(s) of disk encryption.  Which apparently is
> a thing that some laptop users go for in a major way.

And some desktop / server users. I'd rather not have to worry about the
sensitive data on my disks when I decommission them / they fail.

> As a non-laptop person, my understanding is that, at least with some
> implementations of disk encryption, you need an UN-encrypted /boot to
> get the whole thing started.  After that, the root file system and any
> other local file systems can be encrypted, and the code from /boot will
> be able to prompt you for the passphrase or whatever.

Yes. FDE including boot is doable, but it takes more work (and isn't
necessarily worth it, depending on the threat model - see above):

https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

Celejar

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

#222379 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On Mon 11 May 2020 at 10:27:48 (-0400), Celejar wrote:
> On Mon, 11 May 2020 07:36:27 -0400 Greg Wooledge <wooledg@eeg.ccf.org> wrote:
> > On Sat, May 09, 2020 at 10:05:40PM -0700, Will Mengarini wrote:
> > > * Rick Thomas <rick.thomas@pobox.com> [20-05/09=Sa 20:05 -0700]:
> > > > [...] died for lack of space in /boot [...]
> > > 
> > > Long ago I stopped bothering with a separate /boot, and behold, I yet
> > > live.  ISTR the Debian installer doesn't default to creating one either.
> > 
> > Unless you're doing some kind(s) of disk encryption.  Which apparently is
> > a thing that some laptop users go for in a major way.
> 
> And some desktop / server users. I'd rather not have to worry about the
> sensitive data on my disks when I decommission them / they fail.

I'm surprised that more people aren't concerned about theft, and also
their increasing obligations under confidentiality/privacy rules/laws.

> > As a non-laptop person, my understanding is that, at least with some
> > implementations of disk encryption, you need an UN-encrypted /boot to
> > get the whole thing started.  After that, the root file system and any
> > other local file systems can be encrypted, and the code from /boot will
> > be able to prompt you for the passphrase or whatever.
> 
> Yes. FDE including boot is doable, but it takes more work (and isn't
> necessarily worth it, depending on the threat model - see above):

I don't encrypt root because it's far too useful to be able to remotely
boot up. To keep things simple, I set up my laptops similarly, except
that unlocking is earlier, in the boot sequence rather than after the
system is fully up.

> https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html

I notice that this page (of 09 Jun 2019) mentions a typical /boot
partition of 256MB, and laments not being able to reclaim the space
if /boot is merged into the root filesystem.

Cheers,
David.

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

#222380 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On Mon, 11 May 2020 11:21:35 -0500
David Wright <deblis@lionunicorn.co.uk> wrote:

> On Mon 11 May 2020 at 10:27:48 (-0400), Celejar wrote:

...

> > Yes. FDE including boot is doable, but it takes more work (and isn't
> > necessarily worth it, depending on the threat model - see above):
> 
> I don't encrypt root because it's far too useful to be able to remotely
> boot up. To keep things simple, I set up my laptops similarly, except
> that unlocking is earlier, in the boot sequence rather than after the
> system is fully up.

Well, I currently don't encrypt /boot, but since I'm anyway using the
iDRAC console to supply the LUKS password, I suppose it wouldn't
actually be *that* much more difficult to encrypt the entire disk and
boot from virtual media over iDRAC:

https://www.dell.com/support/article/en-us/sln296648/using-the-virtual-media-function-on-idrac-6-7-8-and-9

Celejar

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

#222341 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On Sat 09 May 2020 at 20:05:48 (-0700), Rick Thomas wrote:
> I recently did a "apt update ; apt upgrade" and it died for lack of space in /boot when trying to install the latest kernel.
> 
> I purged a couple of old kernel packages (still present in the 'stable' repo, so they weren't obsolete) to make enough space and tried again.  Worked this time, but I would have liked to have the old kernels around as fallbacks just in case of a regression...
> 
> Here's the disk layout:
> 
> rbthomas@milli:~$ lsblk
> NAME                  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> sda                     8:0    0 111.8G  0 disk 
> ├─sda1                  8:1    0   512M  0 part /boot/efi
> ├─sda2                  8:2    0   244M  0 part /boot
> └─sda3                  8:3    0 111.1G  0 part 
>   ├─debian--vg-root   253:0    0    28G  0 lvm  /
>   ├─debian--vg-swap_1 253:1    0   7.9G  0 lvm  [SWAP]
>   └─debian--vg-home   253:2    0  75.2G  0 lvm  /home
> sdb                     8:16   1   239G  0 disk 
> └─sdb1                  8:17   1   239G  0 part /media/rbthomas/Spare
> mmcblk0               179:0    0 238.3G  0 disk 
> └─mmcblk0p1           179:1    0 238.3G  0 part /media/rbthomas/Downloads
> rbthomas@milli:~$ 
> 
> rbthomas@milli:~$ df -HTP | grep -v tmpfs
> Filesystem                  Type      Size  Used Avail Use% Mounted on
> /dev/mapper/debian--vg-root ext4       30G  9.9G   19G  36% /
> /dev/sda2                   ext2      248M   78M  158M  34% /boot
> /dev/sda1                   vfat      536M  144k  536M   1% /boot/efi
> /dev/mapper/debian--vg-home ext4       79G  4.4G   71G   6% /home
> /dev/sdb1                   ext4      252G   63M  239G   1% /media/rbthomas/Spare
> /dev/mmcblk0p1              ext4      251G   63M  238G   1% /media/rbthomas/Downloads
> rbthomas@milli:~$ 
> 
> 
> What's the best way to increase the size of /boot ?
> 
> I can easily create a gig or so of space by a shrink/resize of /home, but how do I add that space to /dev/sda2 ?
> 
> I can't just move up the end of /dev/sda2 = start of /dev/sda3 without backing up and restoring, can I?

Apparently you have at least two kernels in under 80M, so one wonders
how many you need to have available for booting at any one moment.

If the answer is many, you could shrink some of them by rebuilding
their initrd.img files with MODULES=dep, which could reduce each
kernel's size from ~40M to <10M.

75G for /home is pretty small (the only disk I have that small is a
2004 laptop) so I'd look for an opportunity to repartition in the
near to mid-term. (Is this one that you've converted to sysv, for
example, or is it encrypted—excuses like that.)

All of which assumes that you actually need a separate /boot …
… and that you didn't repartition it already, before dawn.

Cheers,
David.

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

#222342

David Wright <deblis@lionunicorn.co.uk> wrote:

> If the answer is many, you could shrink some of them by rebuilding
> their initrd.img files with MODULES=dep, which could reduce each
> kernel's size from ~40M to <10M.

While this will reduce this initrd size, you should also mention the
consequences of doing this:

 It only includes the modules update-initramfs thinks are needed to boot
 the system.

But this also results in two important consequences:

1) You lose portability of the system. By only including the modules
   needed to boot in the current hardware this may limit your ability to
   boot the system on different hardware.

2) MODULES=dep is a codepath less tested. In my experience this can lead
   to modules missing which are needed for successful boot, resulting in
   a failed or incomplete boot.

Grüße,
Sven

-- 
Sigmentation fault. Core dumped.

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

#222343 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On Sun 10 May 2020 at 16:30:56 (+0200), Sven Hartge wrote:
> David Wright <deblis@lionunicorn.co.uk> wrote:
> 
> > If the answer is many, you could shrink some of them by rebuilding
> > their initrd.img files with MODULES=dep, which could reduce each
> > kernel's size from ~40M to <10M.
> 
> While this will reduce this initrd size, you should also mention the
> consequences of doing this:
> 
>  It only includes the modules update-initramfs thinks are needed to boot
>  the system.
> 
> But this also results in two important consequences:
> 
> 1) You lose portability of the system. By only including the modules
>    needed to boot in the current hardware this may limit your ability to
>    boot the system on different hardware.
> 
> 2) MODULES=dep is a codepath less tested. In my experience this can lead
>    to modules missing which are needed for successful boot, resulting in
>    a failed or incomplete boot.

That's why I wrote "some".

We have no idea what this machine/disk is used for, nor how many
kernels is considered reasonable. But with ~240M available, we're in
the realm of compromise. The suggestion has already been made to
backup (then presumably remove) some kernels. Copying the initrd.img
files before rebuilding as dep is even easier. Were a disaster to
befall, the OP has already mentioned having GRML available. Gigs
of space is available in the df listing presented. So expanding
/boot just doesn't seem urgent enough to be done at five in the
morning.

Cheers,
David.

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

#222482 — Re: Hmmm... /boot is too small. what's the best way to increase it's size?

On Sat, May 09, 2020 at 08:05:48PM -0700, Rick Thomas wrote:
>NAME                  MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
>├─sda1                  8:1    0   512M  0 part /boot/efi
>├─sda2                  8:2    0   244M  0 part /boot

>What's the best way to increase the size of /boot ?

First, of course, make sure you have a rescue boot method available
(live CD or whatever), and up-to-date backups.

I would look into swapping /boot and /boot/EFI. But I would also double
check what properties the EFI partition needs, besides the files within
it (and filesystem, etc.), are there any requirements on the partition
type, label, etc., and make sure to set those correctly on sda2 (and
unset them on sda1!)

At least on my machine the EFI partition is almost unused (check that
too for yours, of course!), so swapping them would give you another
256M in /boot, without needing to repartition, reinstall, etc.

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

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

csiph-web