Greetings.

Didier Kryn - 20.11.25, 14:22:52 CET:
> Le 20/11/2025 à 13:42, g4sra via Dng a écrit :
> > * snip -
> >>
> >> I don't recomend making /boot a mountpoint though.
> >
> > Why not ?
>

>      Solutions to problems always cause other problems; therefore I'm
> against solutions to non-existing problems. So, to begin with,  what is
> the problem with not having /boot a partition per se?

In general I agree to this. Splitting out a system into to many different
filesystems can easily be a recipe for trouble.

Especially I would not separate out /usr or even /usr/local anymore and on
a desktop system also not /var or /var/log. And even on a server I did not
separate /var and /var/log anymore. Before I stopped doing so, I did such
kind of separation for variable data including logs on LVM, so it was
flexible, but as long as I make sure regular users cannot fill up the
server… I meanwhile take the risk of filling up /.

I still separate out /home or on a server maybe /srv for data. Main reason
is to have multiple failure domains. If / filesystem fails, /home or /srv
could still be accessible. Also for a cleaner separation between OS and
user data. If I ever where to switch away from Devuan to some other
distribution it is also easier to install that other distribution without
accidentally deleting user data.

>      If your /boot is a partition, then you will need to check carefully
> its available size before you upgrade linux-image. Failing to do so may
> cause failure to install the kernel or the initrd and then to update
> grub, and you might not notice the message within the flow of messages
> caused by updating many other packages in the same time. Then next boot
> will fail.

Re: In general I agree to this…

However, this is two-sided. Cause it eventually also reduces complexity to
separate out /boot.

I can use a simple Ext4 / XFS¹ for /boot and have the Linux kernel access
a BTRFS filesystem within LUKS encrypted LVM for booting the operating
system.

This is not a complete guarantee for being fail-safe, cause I have seen
GRUB refusing to boot from a new version of XFS and from a new version of
Ext4 already, solving this by formatting /boot with another filesystem.
Maybe this can only happen when following Debian Sid / Devuan Ceres,
however both of that happened to me already, resulting in a temporarily
not boot-able system.

Now add LUKS encrypted LVM and BTRFS on top. I see the potential for
failure only raising.

So with / and /boot on the same filesystem GRUB has to replicate that much
of an operating system to actually being able to access / filesystem. With
/boot separate you can reduce the complexity needed within GRUB or any
other boot loader.

However it also has an advantage to keep / and /boot unified. I think
meanwhile GRUB can handle LUKS based LVM with BTRFS on top just nicely.
And using that kind of setup together with password protected BIOS,
password protected GRUB, Secure Boot / TPM measured boot may make it more
difficult to tamper with a device. However… as long you can still open a
device to make changes directly to the storage devices or to the device… I
would consider a lost device as compromised.

Also the complexity of such a setup is insane. It is even ridiculous.

Actually I'd prefer to have much simpler booting.

I see some point of doing that with a so called smartphone, but for a
laptop that can a lot more easily be tampered with?

On regular Linux systems I'd basically love to have a very simple,
optionally strongly encrypted filesystem just for the stuff you require to
boot. Then make that an extra space on the disk and let the Linux kernel
handle all the rest instead implementing an operating system inside the
boot loader. On top of the operating system in the firmware. Like on Intel
based systems with Intel Management Engine – is it still Minix based? – or
on AMD and ARM with their "security" technologies. Or inside UEFI. As far
as I understand you could have up to three TCP/IP stacks running at the
same time on a modern system: One in Intel Management Engine, one in UEFI
and one in the OS.

Booting modern systems is outright ridiculous if you ask me. It is a
wonder that it actually works.

But we still have no really good completely open and free software based
hardware platforms.

>      In general spreading your OS over many partitions causes the same
> kind of problems for all of them, there is always too much space
> allocated to one and not enough to another, and, anyway, the loss of any
> of them makes your system hardly recoverable. Therefore just have one,
> except for /home, of course, and for the temporary directories.

That is a non issue since I just use 1 GiB for /boot. Given current sizes
of storage devices I do not care about a certain amount of waste. Also on
flash free storage is not wasted… it increases longevity of a flash device
if discarding is used.

Also I just use 50 GiB for / on a desktop in case I separate out /home and
maybe some other data filesystems. And even with tons of Flatpaks
installed… that space does not run out. And I still put that stuff on LVM
so I can increase size in case it is needed.

For a virtual machine that you control the hypervisor for I'd do one disk
for the operating system and then separate out every kind of different
data. For a file server would use another disk for the files being shared,
for a database server for the database. I'd just „mkfs“ the complete data
disk directly: no partitions, no LVM, no nothing. Then to increase size
you just increase size of disk in the hypervisor and then enlarge the
filesystem. But I have seen that with recent enough Linux kernel system
you can even enlarge a partition, if space behind it is available, without
rebooting the system. However why such complexity for data filesystems
that do not need to be booted from?

I am aware that ten people answering to this may have fifteen different
opinions or convictions on what is best. :) I am looking forward to learn
about them.

[1] One could argue about simple with XFS and maybe even Ext4 – but still.

Best,
--
Martin