Maximum PC - USA (2022-01)

Linux has always tried to co-operate with Windows oddities

and, despite common gripes, it does a pretty good job

DUELING OSes

OWNERS OF A MODERN UEFI system should be able to

revert any unwanted changes caused by installing a new

operating system, as long as you can get into the UEFI

settings. 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 chain loading

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

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 the Stage 2 will load

the main config file /boot/grub/grub.cfg as well.

We have long

recommended

k e e p i n g

separate OSes

on separate

drives, and one of

the main reasons

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. 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 behavior first-

hand. Planting recovery partitions on other drives,

corrupting LVM and RAID volumes, and all kinds of

other unorthodox behavior. 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 box, right).

Also, we shouldn’t bash NTFS-3G. The official WSL

documentation warns that the converse situation, viz.

transfers from within WSL to without won’t be blazing

fast either. This is a slight regression from WSL 1, which

thanks to not having a real Linux Kernel was able to

streamline transfers across filesystems. Still, certain

I/O-heavy workloads to Linux filesystems that were

hobbled under WSL 1, should now do much better.

Besides NTFS (see below), Paragon Software has

an agreement with Microsoft that enables it to market

and license its own exFAT implementation(s). This

would have been something of a boon for Paragon, but

Modern UEFI

makes it difficult

for Windows

to prevent Linux

from booting

Linux loves Windows

40 MAXIMUMPC JAN 2022

mobilism.org