Bug#886642: please default to a larger /boot for guided partitioning

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Bug#886642: please default to a larger /boot for guided partitioning

Jonathan Dowland
Package: debian-installer
Version: 20171204
Severity: wishlist

Hi there! Filing this after a discussion on IRC. For various guided
partitioning profiles (at least "use entire disk and use LVM") the created
/boot is 256M in size[1].

I'd like to suggest a larger default, at least 512M[2]. Note: this would only
change the default for guided partitioning and would not prevent someone from
manually specifying a smaller size.

Rationale:

with current kernel and default initramfs/generator settings, you need roughly
33.2M for a vmlinuz/initramfs/system.map triplet on amd64. So there's enough
room for 7 at a time, but you also need at least 10M for grub, and that may
very a lot depending on the specifics of the host.

I think the default should leave enough room for a user to install more rescue
options, since it can be very hard/impossible to grow /boot later on if they
decide they want it. GRML currently requires ~280M for the small version (600M
for the fully featured version). grml-rescueboot is a very nice integration
package to add grml ISOs to the GRUB menu and it would be nice if it would be
usable on a default installation without having the foresight to manually set
the /boot size larger. (There's also grub-imageboot as a more generic solution,
the user may wish to put e.g. BIOS/firmware update ISOs in /boot for use with
this, etc.)


This seems like a nice bug for a beginner to patch, and I am a beginner for
d-i (but anyone else who wants to try please don't let me stop you)


[1] perhaps things are more complex than that and it depends on the size of the
    disk; it has appeared 256G for me with VM tests (=8G drive) and real drives
    (=512G)

[2] Exactly how large, I'm sure, many might have an opinion on; let the discussion
    commence!

-- System Information:
Debian Release: 9.1
  APT prefers stable
  APT policy: (990, 'stable'), (600, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.9.68-x86_64-linode89 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)

--

⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.

Reply | Threaded
Open this post in threaded view
|

Bug#886642: please default to a larger /boot for guided partitioning

Tobias Hansen-3
Control: severity -1 important

Please someone do this, having these small default sizes for /boot is really annoying and has been the only reason I had to reinstall Debian on several systems over the years. Let me explain.

I usually use guided partitioning to set up encrypted LVM. Doing this, it is not that simple to change the size of /boot. I think it is equivalent to doing the whole partitioning manually.
Also, having an encrypted LVM starting right after /boot, it is very complicated to change the size of /boot later. So it is important to have a sensible default for the size of /boot.

I have one system where /boot is 162M which was apparently the default a few years ago. Even after changing the initrd encryption to xz, every single kernel upgrade fails, because dkms does a backup of the initrd, so one needs at least 3-4 times the space of the initrd to be available to do an update. After the failed update I always have to delete the dkms backup and run apt install -f.

I just did a fresh install of Debian 10 (amd64) and guess what, the size of /boot is 256M, with the size of the default initrd.img 64.2M. System.map and vmlinuz add another 8.7M. Free space on /boot: 147M. This will probably make kernel updates fail in 2 years if the encryption is not changed to xz. (Of course always making sure that only a single kernel image is installed before the update.)

512M is already a low value for the size of /boot today.

Best,
Tobias


On Mon, 8 Jan 2018 11:50:05 +0000 Jonathan Dowland <[hidden email]> wrote:

> Package: debian-installer
> Version: 20171204
> Severity: wishlist
>
> Hi there! Filing this after a discussion on IRC. For various guided
> partitioning profiles (at least "use entire disk and use LVM") the created
> /boot is 256M in size[1].
>
> I'd like to suggest a larger default, at least 512M[2]. Note: this would only
> change the default for guided partitioning and would not prevent someone from
> manually specifying a smaller size.
>
> Rationale:
>
> with current kernel and default initramfs/generator settings, you need roughly
> 33.2M for a vmlinuz/initramfs/system.map triplet on amd64. So there's enough
> room for 7 at a time, but you also need at least 10M for grub, and that may
> very a lot depending on the specifics of the host.
>
> I think the default should leave enough room for a user to install more rescue
> options, since it can be very hard/impossible to grow /boot later on if they
> decide they want it. GRML currently requires ~280M for the small version (600M
> for the fully featured version). grml-rescueboot is a very nice integration
> package to add grml ISOs to the GRUB menu and it would be nice if it would be
> usable on a default installation without having the foresight to manually set
> the /boot size larger. (There's also grub-imageboot as a more generic solution,
> the user may wish to put e.g. BIOS/firmware update ISOs in /boot for use with
> this, etc.)
>
>
> This seems like a nice bug for a beginner to patch, and I am a beginner for
> d-i (but anyone else who wants to try please don't let me stop you)
>
>
> [1] perhaps things are more complex than that and it depends on the size of the
>     disk; it has appeared 256G for me with VM tests (=8G drive) and real drives
>     (=512G)
>
> [2] Exactly how large, I'm sure, many might have an opinion on; let the discussion
>     commence!
>
> -- System Information:
> Debian Release: 9.1
>   APT prefers stable
>   APT policy: (990, 'stable'), (600, 'unstable')
> Architecture: amd64 (x86_64)
>
> Kernel: Linux 4.9.68-x86_64-linode89 (SMP w/2 CPU cores)
> Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE=en_GB.UTF-8 (charmap=UTF-8)
> Shell: /bin/sh linked to /bin/dash
> Init: systemd (via /run/systemd/system)
>
> --
>
> ⢀⣴⠾⠻⢶⣦⠀
> ⣾⠁⢠⠒⠀⣿⡁ Jonathan Dowland
> ⢿⡄⠘⠷⠚⠋⠀ https://jmtd.net
> ⠈⠳⣄⠀⠀⠀⠀ Please do not CC me, I am subscribed to the list.
>
>

Reply | Threaded
Open this post in threaded view
|

Bug#886642: fixed? (please default to a larger /boot for guided partitioning)

Vincent McIntyre-4
In reply to this post by Jonathan Dowland
Hi

I thought this would have been fixed by this commit

https://salsa.debian.org/installer-team/partman-auto/-/commit/79bea1c75d2fd9fbd6eb01c1bea6de2914d24d22

which will be available in the 'daily' build of the installer.
I don't know what the prospects are for having this applied to
the 'stable' installer.

Kind regards
Vince
Reply | Threaded
Open this post in threaded view
|

Bug#886642: fixed? (please default to a larger /boot for guided partitioning)

Holger Wansing-4
Hi,

"McIntyre, Vincent (CASS, Marsfield)" <[hidden email]> wrote:
> Hi
>
> I thought this would have been fixed by this commit
>
> https://salsa.debian.org/installer-team/partman-auto/-/commit/79bea1c75d2fd9fbd6eb01c1bea6de2914d24d22
>
> which will be available in the 'daily' build of the installer.
> I don't know what the prospects are for having this applied to
> the 'stable' installer.

This is indeed fixed for bullseye, tracked in #893886 / #951709, leading to /boot
getting a size between 512 and 768MB (depending on disc size).

@Tobias: you can try a daily build from
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/
to confirm it works for you for installation of bullseye.

I was not aware of this bug, so did not close it...

Should this be considered for backporting to stable?


Holger


--
Holger Wansing <[hidden email]>
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Reply | Threaded
Open this post in threaded view
|

Bug#886642: fixed? (please default to a larger /boot for guided partitioning)

Ben Hutchings-3
On Mon, 2020-05-25 at 13:22 +0200, Holger Wansing wrote:

> Hi,
>
> "McIntyre, Vincent (CASS, Marsfield)" <[hidden email]> wrote:
> > Hi
> >
> > I thought this would have been fixed by this commit
> >
> > https://salsa.debian.org/installer-team/partman-auto/-/commit/79bea1c75d2fd9fbd6eb01c1bea6de2914d24d22
> >
> > which will be available in the 'daily' build of the installer.
> > I don't know what the prospects are for having this applied to
> > the 'stable' installer.
>
> This is indeed fixed for bullseye, tracked in #893886 / #951709, leading to /boot
> getting a size between 512 and 768MB (depending on disc size).
>
> @Tobias: you can try a daily build from
> https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/
> to confirm it works for you for installation of bullseye.
>
> I was not aware of this bug, so did not close it...
>
> Should this be considered for backporting to stable?
I think it should, though there is a small risk of regression if people
install on very small storage devices.

Ben.

--
Ben Hutchings
Nothing is ever a complete failure;
it can always serve as a bad example.



signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Bug#886642: fixed? (please default to a larger /boot for guided partitioning)

Jonathan Dowland-6
In reply to this post by Holger Wansing-4
Hi!

On Mon, May 25, 2020 at 01:22:03PM +0200, Holger Wansing wrote:
>This is indeed fixed for bullseye, tracked in #893886 / #951709, leading to /boot
>getting a size between 512 and 768MB (depending on disc size).

Thanks for fixing this,

>I was not aware of this bug, so did not close it...

I'm not sure what to do with it, now. Partman is done and those bugs
archived. This is against debian-installer, and I presume there's some
lag before it picks up/bundles a fixed partman, so perhaps this bug
should track that. Can someone with more of a clue tell me if that makes
sense?

>Should this be considered for backporting to stable?

And I'm guessing that should be tracked in yet another bug.