> 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,