Debian Installer Bullseye Alpha 3 Switches To Linux 5.9, Larger /boot

[phoronix]

Phoronix: Debian Installer Bullseye Alpha 3 Switches To Linux 5.9, Larger /boot

While the Debian 11 "Bullseye" freezes don't get started until January, the Debian Installer for Bullseye has been in alpha for just over a year. Today marks the third alpha release of the Debian Installer for Bullseye...

http://www.phoronix.com/scan.php?page=news_item&px=Debian-11-Installer-Alpha-3

[leech]

Awesome, looking forward to another release of the best Linux Distro around. They try to be one 'for everyone' and do a mighty fine job at it.

Pop_OS is awesome, but it doesn't support any sort of advanced partitioning at all... I had to partition out and create a raid 0 setup in Debian, then install Pop_OS on top for my thinkpad (as it has better support out of the box for nvidia optimus stuff... I don't have time to dick with that as much as I used to.)

Maybe Bullseye will have a better out of box experience for my P52!

[wswartzendruber]

I'd be quite surprised if they didn't go with Linux 5.10.

[luben]

I'd be quite surprised if they didn't go with Linux 5.10.

5.10 is not released yet

[wswartzendruber]

5.10 is not released yet

Neither is Debian 11.

[Sonadow]

Another notable difference with this Debian Installer update is partman-auto for the automatic partitioning increasing the size of /boot. When needing to make a separate /boot partition such as for full-disk encryption use-cases, the size will now be 512~768M rather than 128~256M as is the current default. This increase is being made since the current default has long been considered "too small" in that often times three kernel images can't even fit in /boot any longer without being filled up.

About time they realized that.

On my machines, /boot is always at least 1GB, no thanks to some bad experience with Ubuntu performing automatic kernel updates even after explicitly disabling automatic updates.

Even though Fedora, OpenSUSE and Debian don't do that, paranoia still dictates that /boot be at least 1GB.

[Trevelyan]

I wish they could use the EFI partition for the kernel and initrd, instead of a separate /boot.

I once did something like:
/dev/sda1 /mnt/efi vfat
/mnt/efi/debian /boot bind
/mnt/efi /boot/efi bind

it sort of worked, but the kernel install/upgrade package scripts expect to be able to do hardlinks and softlinks, which you cant do on vfat.
i did report it as a bug, and got the reply that vfat /boot is not supported; and not planned to be.

However bar having to manually rename some /boot files before installing a kernel package it worked fine.

[baryluk]

5.10-rc6 is already in Debian experimental.

Once 5.10 is released, we will see it in unstable, at least if there are no build issues on all architectures. I am pretty sure Debian freeze will be with 5.10, it has quite a bit of important new hardware support for GPUs, x86 and arm CPUs, and many more, it would be silly to deprive users from that, etc.

[baryluk]

larger /boot is needed because users will often have have multiple kernel eventually installed in /boot. 128M will fit only 1 kernel+initrd. 256M would only fit 2, 3 if you are lucky. The range in partman, takes into account the size of the area dedicated to partitioning, so if you have small disk, it will use less for /boot (i.e. 512M), if you have a very big disk, it will use more (i.e. 768M). I personally almost always use 1G or 2G, depending if I plan to build kernel with all the extra debug symbols or not. 512M is a good default for small systems, and will safely fit 6 kernel+initrds, giving user fallback and time to clean things up.

Also, this really only applies for setup with separate /boot. The default is to not have separate /boot, but instead use / for root and boot, so there is more margin of free space for kernels. The separate /boot is really only needed for full disk encryption, or if you use some esoteric file system for the root (but grub really supports a lot of file systems, but i.e. it doesn't support all ZFS raid modes at the moment for example).

[baryluk]

I wish they could use the EFI partition for the kernel and initrd, instead of a separate /boot.

I once did something like:
/dev/sda1 /mnt/efi vfat
/mnt/efi/debian /boot bind
/mnt/efi /boot/efi bind

it sort of worked, but the kernel install/upgrade package scripts expect to be able to do hardlinks and softlinks, which you cant do on vfat.
i did report it as a bug, and got the reply that vfat /boot is not supported; and not planned to be.

However bar having to manually rename some /boot files before installing a kernel package it worked fine.

That would be great, but they would probably need to put /boot on fat32, as no BIOS/UEFI implementation that I know of supports ext4. Maybe there is some (probably on some arm or what's not), but all I have seen are just fat32 and iso9660.

As you said, /boot often requires to support symlinks, etc. so fat32 is kind of meh. But in reality, most distros don't put symlinks in /boot anymore, at least not for kernel. Not sure what grub does, but the symlink situation could be fixed there too. Most distros put symlinks to latest kernel directly in /, most tools don't use it anyway, and I don't know why distros bother putting these symlinks there anymore, but my guess is some ancient architectures bootloaders are not very smart, and use that. Things like LILO (which is dead and not maintained for a decade; in fact lilo is going to be removed from Debian in few weeks), or MILO (for alpha), amiboot (for m68k), etc.