Duelling OSes
Linux has always tried to co-operate with Windows oddities, and despite common gripes, it does an amazing job.
Owners of a modern UEFI system should (as long as you can get into the UEFI settings) be able to revert any unwanted changes caused by installing a new operating system. The UEFI boots an image from the EFI partition or live media, and userspace tools (both on Windows and through efimgr on Linux) can change the boot order and in some cases break things. It’s generally expected (but not necessarily desired) that a newly installed OS will put itself at the top of the boot ordering. Often this results in Windows booting immediately and the only way to get to the UEFI settings to revert this is to hold the Shift key while shutting down from the start menu. An option to reboot to settings should appear.
Our experience was, mercifully pain-free though. We upgraded Windows 10 on a 10th generation Dell XPS set up to boot Ubuntu, and lo and behold the default boot choice (GRUB) was left intact. Not only did Ubuntu boot correctly, but the old GRUB entry for chainloading Windows also worked. We think we got lucky here, but even if we didn’t, booting Windows would just be a matter of entering the UEFI settings or summoning a boot menu at startup. If UEFI didn’t give us these options, then we can reboot to the firmware setup with $ systemctl reboot --firmware-setup
For older BIOS machines the situation is different. Each hard drive can have its own Master Boot Record (MBR), and any OSes installed can put their bootloaders here. Well, the first part of their bootloaders, the MBR is only about 440 bytes long, and modern bootloaders like GRUB are complicated, so the MBR contains a skeleton program that tells the machine where on the hard drive the rest of the bootloader can be found.
Grub version 1 also had a Stage 1.5, which filled about 30KB directly after the MBR and contained the appropriate filesystem driver for the partition containing Stage 2. Grub v2 doesn’t need Stage 1.5, as Stage 1 points directly to the logical block address containing Stage 2 (without worrying about filesystems), and then the Stage 2 will load the main config file /boot/grub/grub.cfg as well.
We’ve long recommended keeping separate OSes on separate drives, and one reason for this is to mitigate against one OS’s bootloader treading on the toes of another. This is as much a problem between different Linux distros as it is between Linux and Windows. Linux distros are generally good enough to give you a boot menu, but entries for secondary distros won’t respect any of their settings in /etc/default/grub, which may cause issues. Also, if one of these distros is Arch Linux, it often doesn’t get detected by the grub-install scripts. Installing the lsb-release package on the Arch side should solve this. Naturally Windows has no qualms about obliterating any other bootloaders on its drive. It’s easy enough to get GRUB back when this happens, but better to avoid it happening by giving Windows its own drive.
Rogue Windows updates
But this might not be enough. We’ve read plenty of posts online saying that Windows updates have boldly gone where they’re not supposed to go, and we’ve been around long enough to have seen this behaviour first hand. Planting recovery partitions on other drives, corrupting LVM and RAID volumes, and all kinds of other unorthodox behaviour. Windows has nothing to gain from this, but living alongside another OS was never in its remit, so in a sense this is to be expected.
Besides battling bootloaders and (maybe) dodgy .docx files, one of the major points of friction between Windows and other OSes is the NTFS filesystem. It’s not just a concern for Linux – getting macOS or Android to write to these volumes was always tricky too, at least without proprietary tools. On Linux we at least had the userspace NTFS-3G driver, but this was not the most performant. Mercifully, help is at hand in the form of a new kernel driver (see the box, right). Also, we shouldn’t bash NTFS-3G. The official WSL documentation warns that the converse situation, viz.
DANCING WITH THE STARS “Samba is vital for anyone who wants to use a Linux machine on a Windows network.”