Programmer Humor

Wonderful day!

It's apparently the third day (in a week!) I see people share their negative view on the booting being damaged by Windows...
Frankly, it's quite odd to see so many people having the issue when Windows or any other OS rewrites the bootloader...
It's sure possible to have it safe, so that even Windows won't rewrite during its update.

Though, I've been into Linux for more than 20 years now, I do have a machine that has Windows 10 installed alongside Linux, even if it's more frequent to boot Windows in a virtual machine nowadays.

The idea is to not share the location for the EFI files (in UEFI mode), but let the systems have their own keeping them fairly isolated, where Grub v2+ or another bootloader you prefer, load them all respectively, being located on a safer partition.

For example:

0. We have two storages (e.g., SSD): /dev/sda and /dev/sdb.

1. Install Windows on /dev/sdb (so it creates its own ESP);

2. Install Linux on /dev/sda (so it creates its own ESP), with a normal/manual partitioning:
   - /boot/ (for Kernels I have 4 GiB+);
   - /boot/efi/ (commonly, from 128 to 512 MiB is enough);
   - Here I normally also have a swap partition, and separate: /home/, /var/;
   - Select Grub to be installed on the /dev/sda;

3. Boot the Grub in /dev/sda;

4. Update Grub within Linux, so it finds the Windows EFI on another drive via its os-prober.

Here, I believe efibootmgr should show the existing EFI, or you could check it manually in /boot/efi after.

Windows should operate on its own ESP it created on its own storage, and don't overwrite the Grub.

At voila!

To additionally clarify, in my personal experience for many years on Linux, I usually tend to see (and are fond of, personally) having separate mounts for contextually different data, where one of the most adequate in frequent circles and duties is to separate the responsibility as, for example:

1. Main system (root) - /;
2. Kernel (~4GiB) - /boot/;
3. EFI (~128-512MiB) - /boot/efi/;
4. User personal - /home/;
5. Variable - /var/;
6. Swap;
7. (Optional) System configuration - /etc/;
8. (Optional) Temporary - /tmp/;

It's also frequent to see the Logical Volume Manager (LVM) active, that may support a more fluent organization of hardware and logical devices. In this case, we might have all the above mounts, except 2 and 3, practically encrypted, too.

One of my current main machines have the following partitions (though no dual-boot on it):

sda                                             8:16   0 953.9G  0 disk
├─sda1                                          8:17   0   512M  0 part  /boot/efi
├─sda2                                          8:18   0     4G  0 part  /boot
├─sda3                                          8:19   0    32G  0 part  [SWAP]
└─sda4                                          8:20   0 917.4G  0 part
  └─luks-12341234-1234-1234-1234-123412341234 252:0    0 917.4G  0 crypt
    ├─vg_system-lv_var                        252:1    0   400G  0 lvm   /var
    ├─vg_system-lv_home                       252:2    0   400G  0 lvm   /home
    └─vg_system-lv_root                       252:3    0 117.4G  0 lvm   /

If interested, please check the following:
- file-hierarchy (File system hierarchy overview... - Linux manual page...)
- Encrypting an entire system;

On Windows, if I am not mistaken (please correct me if wrong), the most frequent is to have at least two explicit partitions, in addition to the implicit primary 4 ones:

1. EFI Boot Partition we mentioned above;
2. Recovery Partition;
3. Microsoft Reserved;
4. Primary Windows.

For example:

- C:\ - System and automatically organized User personal files (desktop, documents, variable as AppData/ProgramData);
- D:\ - Manually installed programs and manually organized User personal files;

You can include a separate data partition to enable easier maintenance for situations where either the primary operating system is likely to be replaced, or when multiple operating systems exist on the same device, such as Windows 10 and Windows 7. When a device has multiple hard drives, a data partition may be stored on another drive.

For typical single-drive configurations, it's best that you not use a separate data partition. There are two main reasons:

- The partition may not automatically protect data that is stored outside the user profile folders. For example, a guest user might have access to files in an unprotected data partition.
- If you change the default location of the user profile folders to any volume other than the system volume, you cannot service your image, and the computer may not apply updates or fixes to the installation.

Source (Hard drives and partitions - Windows Documentation...)

Oh! I would recommend KDE Partition Manger if you prefer GUI for partitioning.

It's likely worth to mention that KDE Partition Manger (project source) is likely one of the best out there I found (tried at least 11 a few years ago) for convenient GUI Luks2 and LVM support, if required.

Even if compared to some of the popular, where Gnome's, GParted, and QtParted resulted in either unsupported logic for Luks2 and LVM or did not complete the task successfully. These tools are still awesome for other tasks, I believe!

Though, perhaps likely as you I do prefer shell or TUI, being dived mostly in terminals/servers, and a script is always an option, of course. Not to mention that even with the GUI above, manual commands are normally eminent/imminent.

Related: https://wiki.t2linux.org/guides/windows#separate-the-efi-partition-after-linux-is-installed