The system area of a disk consists of the space outside of the filesystems. It includes the MBR, if used, the partition table, and other spaces.
A recent topic by @ernie raised the question of what software may write on the system area of your disk, and whether things might clash in this area and cause issues.
I asked AI the following question
“make a list of all software that writes on the system area of a disk”
The response was too long to post here. … try it yourself
I found that it omitted some important pieces of software, so I reminded it …
"You missed btrfs and zfs filesystems, and Windows OS "
It admitted that it had missed these, and confirmed that they do indeed write to the system area of a disk.
Now , I am saying that this behaviour makes clashes possible, with disasterous results for the disk integrity and for booting behaviour.
I actually had such an incident with ZFS in a legacy booted computer. It disabled grub, and it was very difficult to remove what ZFS wrote in the MBR. … I had to use wipefs which is a rather dangerous command.
Does anyone have evidence of similar clashes?
We need to document what the incompatabilities are.
What do I need to know!! All I need to know, is that Linux and Windows are not compatible and I put Windows on one drive and Linux on another drive. When I am installing a Linux Distro, I will unplug my Windows drive and add it later with grub and os-prober!! So this has more to do with user input and decisions other than some are admitting!!
I’ve done both. When using BTRFS I didn’t have any issues with multiboot using only one SSD. On my HTPC I have two SSDs, one with EFI, grub and ext4 for linux / other disk is ZFS with FreeBSD. I can multiboot from grub and if I like I can also press ESC during boot to get to boot from either disk’s EFI partition. No issues ever.
I agree that ZFS is bad if you only have one disk because it will wipe all other partitions and use full disk.
Yes , isolating zfs or btrfs on a disk of its own should be OK.
I think it depends on the details. If Windows shares a disk with Linux , with or without btrfs, there will be problems when Windows updates, especially if it is legacy boot.
If you had 2 Linuxes, one with btrfs… I dont know? Legacy boot would be affected, but not sure about efi boot.
Secure boot , on top of all that , is a mystery to me?
The partition type may affect things too.
I dual-boot Windows 11 Pro 25H2 with CachyOS with secure-boot enabled, and with btrfs. It seems to work perfectly here.
My former distribution of choice was Garuda KDE-Lite Linux with secure-boot enabled. When I encountered boot issues I was unable to overcome, I wiped my entire systen drive (all partitions), then I started fresh by creating 4GB esp(EFI) partition with the esp and boot flags set. I split the remaining space between Windows and CachyOS by creating a temporary raw partition to consume the back half of the drive so I could install Windows next to the esp partition (I’m unsure if it matters, but when Windows has the entire computer to itself, that’s how it sets itself up). From past experience, I knew that Windows would use the existing 4GB esp partition. I spent that day getting Windows as ready for use as possible, including installing the apps I use with a UniGetUI bundle (everything UniGetUI needs to get everything I use re-installed) after making sure Windows Update got the system as up to date as possible.
The next day I made the decision to switch to CachyOS for a few reasons:
It includes Limine boot loader as an option during
installation. (See below for AI’s answer to the question
“Does the Limine boot loader require the same level of
security when secure boot hasn’t been enabled as when it
has?”)
It implements secure boot using Microsoft keys
CachyOS wants a 4GB esp, I suspect for better secure-
boot support. Secure boot is implemented following
installation by the user (there’s an implementation guide
on the CachyOS Wiki). The way secure boot’s
implemented on CachyOS uses the keys Microsoft
created when it was installed rather than its own set of
keys as other distributions seen to do, so the
implementation closely mirrors Microsoft’s.
It defaults to btrfs *automated snapshots matter to me)
I asked the AI from the Google search engine “Does the Limine boot loader require the same level of security when secure boot hasn’t been enabled as when it has?”
Here’s its response:
No, Limine does not apply the same strict security hardening or integrity checks when Secure Boot is disabled as it does when Secure Boot is active. [1]
Security Differences
Secure Boot Inactive (Disabled):
If no configuration checksum is enrolled, Limine treats Secure Boot as inactive.
Internal file-integrity restrictions and config-hardening features are bypassed.
You can freely modify limine.conf or resource files without needing to re-enroll or re-sign anything. [1]
Secure Boot Active (Enabled):
Limine looks for an enrolled configuration checksum (such as a BLAKE2B hash) inside the signed EFI executable.
If you change your configuration file (limine.conf) or assets like splash images without re-enrolling the checksum, Limine’s strict security enforcement will block the boot process to prevent unauthorized tampering. [1, 2, 3]
If you installed an OS using the default Omarchy Secure Boot Setup Guide with Secure Boot disabled, you do not need to worry about tracking configuration checksum hashes or re-enrolling the boot-loader after making everyday text edits to your configuration.
Lets see what happens when Windows does an update.
I just dont know what interacts with what in this area. That is why I started the topic.
Does anyone know?
It seems even an AI query can not give me a list of all the things that interact with the disk system area.
October’s Patch Tuesday will be on the 13th of the month. I’m looking forward to it.
This discussion prompted me to ask the Google search engine “So, while sbctl doesn’t use the shim-signed procedure, it still creates its own keys to enroll and sign the boot loader and system kernel. Is that accurate?”
The AI’s answer:
Yes, that is exactly correct. You have gripped the core concept perfectly.
Instead of relying on an intermediary file (the Microsoft-signed Shim) to pass trust down to Linux, sbctl removes the middleman by making your motherboard trust your Linux installation directly.
The process maps out directly to three distinct actions:
Key Creation (Your Local CA)
When you initialize sbctl, it acts as a local Certificate Authority (CA) on your Linux machine. It generates a unique private key and a public certificate pair that belongs exclusively to your computer.
Key Enrollment (Educating the Firmware)
You push your custom public certificate directly into the motherboard’s non-volatile storage (NVRAM), alongside the standard Microsoft certificates. At this exact moment, your motherboard’s UEFI firmware treats your custom key with the exact same level of absolute authority as it treats Microsoft’s keys.
Signing (Stamping the Binaries)
You use your private key to cryptographically sign the Limine bootloader (limine.efi), your Linux kernel, and any necessary initramfs files.
When the computer boots up, the UEFI firmware reads the signature embedded in Limine.
It compares it against your custom certificate stored in its NVRAM database.
Finding a perfect match, it executes the bootloader instantly without any hesitation or safety warnings.
This architectural difference explains why your current Limine setup is vastly more stable than standard GRUB dual-booting. It completely sidesteps the fragile, vendor-locked “Shim-Lock” validation loops that cause standard GRUB/Windows configurations to break after system updates.
Here a list from Copilot. Don’t know how complete it is. I ask it to not include utilities or tools or dd command. Normal usage items.
It broke down the answer into BIOS and ESP systems.
BIOS systems
Only three normal writers touch it.
GRUB installer — Writes core.img into the MBR gap.
Syslinux/LILO — Write their boot stubs into the MBR gap.
ZFS boot block — Writes a ZFS boot stub into the MBR gap.
For ESP systems.
Windows TrustedInstaller — Updates bootmgfw.efi, BCD, boot graphics inside the ESP.
Linux bootloader installers — Install grubx64.efi, shimx64.efi, and update
/EFI/ubuntu, /EFI/fedora, etc.
systemd‑boot — Writes loader entries and updates /EFI/systemd.
fwupd — Writes capsule updates into /EFI/ for firmware flashing.
Vendor boot managers — Dell, Lenovo, HP place their bootloaders in /EFI/OEM/.
Of course. I don’t have Windows nor secure boot on any machine. I use EFI, not MBR. The laptop had two linuxes and the one with BTRFS was on boot duty with Grub (Os-prober enabled).
That’s your choice, and you’re fully entitled to it. The most appealing thing about the GNU/Linux community as a whole to me is that there’s a solution for everyone. I’d just hate for anyone to be making misinformed or poorly informed decisions.