[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#886642: marked as done (please default to a larger /boot for guided partitioning)

Your message dated Tue, 26 May 2020 17:55:11 +0200
with message-id <20200526155511.GA1106585@chou>
and subject line Re: Bug#886642: fixed? (please default to a larger /boot for guided partitioning)
has caused the Debian Bug report #886642,
regarding please default to a larger /boot for guided partitioning
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
886642: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=886642
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
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.

--- End Message ---
--- Begin Message --- 
Closing this since it should be fixed in dailies.

On Tue, May 26, 2020 at 03:22:22PM +0100, Jonathan Dowland wrote:
> 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.

That should happen in one of the existing partman-auto bugs if someone
wants to push for it.

Cheers,
Julien

--- End Message ---
Reply to: