Artikel top billede

(Foto: Computerworld)

Linux og Windows i smuk harmoni: Den nyvundne kærlighed er godt nyt for alle

Gammelt nag er glemt, og tidligere grænser er opblødt. Vi går tæt på den relativt nyvundne harmoni mellem Microsoft og Linux – og ser på, hvad rutinerede Linux-tilbøjelige kan udnytte den til.

Af Torben Okholm, Alt om Data

Denne artikel er oprindeligt bragt på Alt om Data. Computerworld overtog i november 2022 Alt om Data. Du kan læse mere om overtagelsen her.

I 2015 besluttede Microsoft, at firmaet elskede Linux så meget, at man oprettede et helt Windows Subsystem for Linux (WSL), der gjorde det muligt for Linux-programmer og udviklingsstakke at køre uden videre. Den officielle meddelelse omfattede endda en hjerte-emoji.

Hjerte eller ej – nogle så med skepsis på Microsofts hensigter, fordi de stadig havde mantraet “Embrace, Extend, Extinguish” (omfavn, udvid, tilintetgør) og Halloween-dokumenterne fra 1995 i frisk erindring. Men det lader til, at Microsoft snarere ønsker at imødekomme Linux-brugerne (måske især udviklerne) end at fremtvinge en masseflugt.

En afløser, WSL 2.0, blev annonceret i 2019. Den byggede på en ægte Linux-kerne i stedet for på et Wine-lignende lag, som oversætter mellem Linux og Windows. Den indebar hurtigere ydelse, kvikkere filsystemer og større applikationskompatibilitet.

I april 2021 annoncerede man en ny funktion ved navn WSLg, der gjorde det muligt for grafikprogrammer at køre ubesværet på WSL. Man behøver hverken at vride en X-server på Windows eller at omdirigere PulseAudio – det fungerer endda med Wayland. Man kan ikke blot køre Bash på Ubuntu på Windows, men også Blender, Gimp og Krita.

Vi skal vise, hvordan man arrangerer det på Windows, hvordan det er en strålende måde at lære Linux på, og hvordan man kan lave skøre og vidunderlige sager. Endelig skal vi se på det, Linux har gjort for at slå bro til sit proprietære modstykke. Har du før knust filsystemer, netværk eller bootloadere, fungerer alt nu fint med mindre justeringer.

Troværdige Platforme og Windows 11

Windows’ hardwarekrav har altid udløst forvirring, og det gør de altså stadigvæk ...

Da Windows 8 blev annonceret, var nogle bekymrede for, at Microsoft ville bruge Secure Boot, der var en valgfri funktion i det dengang nye UEFI (Universal Extensible Firmware Interface), til at begrænse installation af andre operativsystemer.

Secure Boot tillader kun boot af EFI-afbildninger, som er signeret af en nøgle, der er omfattet af UEFI. Eftersom næsten al hardware bliver leveret med en offentlig signaturnøgle fra Microsoft, er det nemt at se, hvor denne bekymring stammede fra.

Men for at hjælpe Linux-distroer (eller enhver anden software, der krævede sin egen bootloader) med at håndtere Secure Boot, brugte Microsoft sin magiske nøgle til at signere et lille program (de ville formentlig ikke signere noget stort og kompliceret) ved navn Shim.

Shim er en førstetrins-bootloader, der bliver brugt af mange Linux-distributioner (herunder Debian og Ubuntu) til at starte deres egne (andettrins) bootloadere. Secure Boot virker sådan, at hvert trin tjekker det forriges signatur, før den bliver eksekveret. Dermed danner den en kæde af troværdighed tilbage til den oprindelige signaturnøgle. Derfor kan distributioner indlejre deres egne nøgler i Shim og få denne distro-specifikke Shim-pakke signeret af Microsoft.

Shim kan derefter tjekke GRUB EFI-afbildningen, der er signeret af distronøglen, og boot-processen kan fortsætte. Det er også muligt at signere kerneafbildninger såvel som senere indlæste moduler og firmware. Hvis man har tillid til kryptografi og Microsoft Signing Authority, kan Secure Boot gøre det virkelig svært for malware at blive indlæst under den tidlige bootproces.

Et spørgsmål om tillid

Det er naturligvis ikke alle, der stoler på Microsoft eller på Secure Boot. Det er i orden: Da Microsoft i 2013 stipulerede, at “Windows 8 Ready” hardware skulle leveres med Secure Boot aktiveret, indførte man også en mulighed for, at brugerne installerer deres egne MOK’er (Machine Owner Keys) og bruger dem til at signere den bootloader, de ønskede. Dermed lå den ultimative tillid, men også det ultimative ansvar, hos brugeren.

Flise-startmenuer og Windows’ desktop gør dig måske ikke glad, men se blot: Ubuntu kan

“Windows 10 Ready” hardware var underlagt tilsvarende betingelser bortset fra, at kravet om, at Secure Boot er muterbart, blev reduceret til et forslag. Vi har imidlertid aldrig mødt en eneste Windows 10-maskine, hvor Secure Boot ikke kunne frakobles. Og hvis man bygger sine egne systemer, har man intet at bekymre sig over.

“Ready”-betingelserne gælder for OEM’er, der leverer maskiner, hvor operativsystemet allerede er installeret. Nu, da Windows 11 er over os, studerer man ikke længere Secure Boot-paragraffer, men dem, der vedrører TPM-chips.

Trusted Platform Module-chips (TPM) er bittesmå processorer med en lille privilegeret hukommelse. Her kan applikationer lagre nøgler, verifikationsdata eller andet, som de ikke ønsker, at andre applikationer skal blande sig i. Bortset fra minimums-hardwarespecifika-tionerne skal en pc for officielt at understøtte Windows 11 også understøtte TPM 2.0.

I øjeblikket er det stadig muligt at installere Windows 11 via det officielle ISO, selvom maskinen ikke lever op til TPM-kravene (eller andre krav). Men Microsoft siger, at sådanne installationer er uden support og vil måske ikke modtage sikkerhedsopdateringer i fremtiden. Vi har faktisk set Windows 11, der kørte på en Pi 400, og på en Nokia Lumia 950XL, der var en af de sidste enheder, som kørte Windows Phone.

Giv mig al din TPM

TPM-chips har eksisteret i hovedparten af det seneste årti. TPM 2.0 blev introduceret i 2014, og de fleste bundkort fra 2016 og fremefter har sådan en. Man kan også implementere TPM i firmware (såkaldt fTPM). Det indebærer en lille svækkelse af sikkerheden, fordi et nyt Spectre/Meltdown-lignende angreb “i teorien” skulle kunne ramme denne firmware. Imidlertid er fTPM god nok til Windows 11’s krav.

Man kan få brug for at aktivere TPM via UEFI (klassisk BIOS er heller ikke understøttet), hvor det findes under så mange navne, at Microsoft har lavet en venlig hjælpeside (se https://bit.ly/lxf282-mshelp-tpm2) TPM er fuldt understøttet på Linux og kan bruges til at sikre SSH-nøgler (se http://blog.habets.se/2013/11/TPM-chip-protecting-SSH-keys---properly), åbne LUKS-krypterede enheder (via systemd-cryptenroll eller Clevis) eller sågar gøre Secure Boot endnu mere sikker (https://threat.tevora.com/secure-boot-tpm-2).

Der findes separate softwarestakke til TPM 1.2 (TSS, også kaldet TrouSerS) og TPM 2.0 (tpm2-tools), og der er en god beskrivelse af dem begge på Arch Wiki-siden på https://wiki.archlinux.org/title/Trusted_Platform_Module.

Linux i Windows

Er du Linux-fan? Så glem Windows 11. Den seneste version af Windows Subsystem for Linux er sagen i øjeblikket

Er du en del af Windows Insiders Program (det lyder lidt urovækkende)? Og har du installeret en endnu mere urovækkende Preview Build af Windows 10 (i hvert fald build nr. 20262)? Så er det nemt at køre Linux som del af WSL 2.0: Åbn blot en Windows-kommandoprompt med administratorprivilegier, og kør wsl --install . Det virker også med Preview Builds af Windows 11. Efter et par klik og en genstart er du oppe at køre.

Faktisk er en GUI App Support-download temmelig stor, og tiden er derfor nok inde til at lave en kop kaffe. Når du har gjort det, burde WSL, Microsofts Virtual Machine Platform, Linux Kernel og Ubuntu alle være blevet downloadet.

Tiden er inde til at opgradere Windows 11 ved at tilføje en Linux-kerne og noget Microsoft-magi.

Der er andre distroer til rådighed, og man kan for eksempel specificere wsl --install -d Fedora for at installere Fedora i stedet – eller oveni, hvis du allerede har WSL Ubuntu installeret. Brugere af ikke-Preview Builds kan enten tilslutte sig Insiders Program og opgradere til en, eller de kan følge de manuelle installa-tionstrin herunder.

Begynd med at starte en administrator-styret Power-Shell. Eftersom kommandolinjen også kan være grim ved Windows, skriver du denne besværgelse:

dism.exe /online /enable-feature /featurename:Microsoft-Windows-Subsystem-Linux/all /norestart

Dette installerer WSL 1, og nu vil du måske genstarte og lege med det. Du kan også fortsætte for at få den seneste udgave. Hvis du ikke kører Build 18362 (find ud af det ved at køre winver.exe) eller højere (eller 19041 eller højere for ARM64), skal du overtale Windows Update Assistant til at få dig derhen. For at aktivere WSL 2 skal vi først aktivere Virtual Machine Platform, og det kræver, at man skriver denne linje ved en administrator-PowerShell:

dism.exe /online /enable-feature /featurename:
VirtualMachinePlatform /all /norestart

Efter endnu en genstart er du i gang med subsystemets efterfølger. Du skal anskaffe Microsofts seneste frankenkernel ved at downloade og køre pakken hos https://wslstorestorage.blob.core.windows.net/wslblob/wsl_update_x64.msi. Der er en separat pakke til ARM-enheder, og hvis det vedrører dig, skal du skifte x64 ud med arm64 i det forrige link. Før vi begynder at installere Linux, skal vi sætte WSL 2 som standardversionen fra PowerShell, og det er nemt nok:

wsl --set-default-version 2

Tag derefter over til Microsoft Store (https://aka.ms/wslstore), og installer en distribution. De genkendelige versioner er alle gratis, men hvis du føler dig stor i slaget, vil du måske prøve Microsoft Researchs WSL-tilpassede Pengwin-distro, der i øjeblikket bliver solgt til omkring halvdelen af dens faste pris på 20 dollar.

Nu kan du nærlæse log-data og prøve at se, hvad der gik galt med RDP.

Opret en enkeltstående konto

Uanset hvad du vælger, og hvordan du er nået frem, er det første skridt efter installation at følge anvisningerne og oprette et brugernavn og et kodeord. Det er fuldstændig ubeslægtet med andre konti, man måtte have oprettet i Windows, og det er også adskilt fra WSL-konti, der er oprettet af andre Windows-brugere på den samme maskine. Med andre ord er WSL-maskiner i realiteten enkeltbruger-enheder, eftersom de kun vedrører en enkelt Windows-bruger.

Derfor skal man – ligesom med en rigtig Linux-maskine – lave en systemopdatering:

$ sudo apt update
$ sudo apt upgrade

Det er op til dig, hvor du vil gå hen herfra. Du kunne blot installere Vim og build-essentials-pakken og klø på med dit seneste C-projekt. Eller du vil måske hellere installere Nvidia Container Toolkit, der arrangerer alt det, du har brug for til at køre gpu-accelererede Docker-afbildninger, således at du kan bruge CUDA, PyTorch og TensorFlow til at maskinlære din adgang til friheden.

Det kan også være, at du har lyst til at prøve noget andet. En af de bedste egenskaber ved WSL 2.0 er, at det understøtter gui-redskaber uden nogen yderligere konfiguration. Det har endda sin egen Wayland-compositor. I de tidligere versioner kunne man bruge grafiske værktøjer, men det krævede en X-server (GWSL, VcXsrv eller X410), for at man kunne køre på Windows-siden.

Vores foretrukne gui-værktøj er Microsoft Edge, og vores foretrukne form for humor er sarkasme. Hvis man skulle få lyst til at køre Linux-udgaven af Microsofts browser i en Microsoft-venlig version af Linux, kunne man sagtens kaste sig ud i det:

$ sudo apt install software-properties-common
apt-transport-https wget
$ wget -q https://packages.microsoft.com/keys/
microsoft.asc -O- | sudo apt-key add -
$ sudo add-apt-repository “deb [arch=amd64] https://
packages.microsoft.com/repos/edge stable main”
$ sudo apt install microsoft-edge-dev

Nu bør Edge komme frem i startmenuen, men man kan også blot starte browseren med microsoft-edge .

På denne måde ville man også kunne installere Microsoft-specialiteter som Microsoft Teams og Skype. Eller måske noget, der ikke er helt så Windows-centreret. Det gælder populære open source-programmer, og derfor har for eksempel Gimp, Blender, VLC og så videre alle officielle Windows-ækvivalenter.

Hvis de af den ene eller anden grund ikke fungerer godt, er der nu andre muligheder. Transmission BitTorrent-klienten er måske en undtagelse – den har en Windows-port, men den bliver karakteriseret som en tidlig preview-udgave. Du har måske din egen foretrukne Windows-torrentklient (uTorrent er populær), men ellers kan du udnytte Linux-versionens solide driftssikkerhed. Du skal blot skrive:

$ sudo apt install transmission

Visual Studio Code (eller VSCodium-forgreningen) bliver stadig mere populær på Linux. Og den er hurtigt ved at blive den foretrukne kode-editor til Raspberry Pi-brugere. Vi kan installere Linux-versionen på stort set samme måde, som vi installerede Edge ovenfor, men vi kan også gøre noget andet.
Nyere VS Code-versioner understøtter WSL-remote-udvidelsen, således at man kan installere Windows-versionen (fra https://code.visualstudio.com) og dermed få nem adgang til sine WSL-filer.

En hel markedsplads inden i en kode-editor er ikke alles kop te, men en WSL-udvidelse er både styrkende og forfriskende.

Først skal du sikre dig, at “Add to PATH” er markeret i dialogboksen Select Additional Tasks ved installationens begyndelse. Dernæst søger du fra Extensions Marketplace efter Remote Development og installerer udvidelsespakken (der muliggør fjernadgang til WSL, containere eller over SSH). Ifølge dokumenterne på https://docs.microsoft.com/en-us/windows/wsl/tutorials/wsl-vscode burde du nu kunne start VS Code fra WSL ved at åbne Ubuntu-kommandolinjen og køre code.

Det fungerede ikke for os, men vi var i stand til at bruge F1 til at fremkalde kommandopaletten i VS Code og lede efter Remote-WSL. Det viser mange af dens funktioner, herunder muligheden for at åbne en mappe i WSL med dens egen Terminal.

Hvis du kører kommandoen top i en nystartet WSL 2.0-omgang, kan du se, at der ikke er ret meget, der kører – et par init-processer, Bash og selve Top. Det er stort set alt. Men ikke helt, for der foregår en masse magi i en usynlig virtuel maskine. Den kører en container-distro, som bygger på Microsofts CBL Mariner Linux (udviklet til Azure cloud), som håndterer Wayland, X, PulseAudio og sender det tilbage til Windows via FreeRDP. Læs mere om WSLg på https://github.com/microsoft/wslg.

fremmede Filsystemer

Set fra Linux-siden er ens Windows C:-drev og alting i det tilgængeligt fra /mnt/c, og fra Windows-siden kan man se sine Linux-filsystemer fra Stifinder ved at følge Linux-genvejen (den har et pingvin-ikon) under OneDrive, Denne pc og alt muligt andet.

Det er praktisk, men uklogt at lade Linux-programmer foretage I/O-tunge opgaver på /mnt/c. Hvorfor? Det skal vi sige dig: Hvis man kører kommandoen mount, vil man bemærke, at /mnt/c bruger en form for eksotisk Plan 9 (9p)-filsystem til at åbne et drvfs-volume. Man vil også se, at Linux’ rod-filsystem lever på sin egen blok-enhed (/dev/sdc eller lignende), og at der er startpunkter til WSLg (den hjælpedistro, der gør, at værktøjer kan køre problemfrit med grafik og audio).

I WSL 1 bliver drvfs brugt direkte, og det betyder, at ydelsen mellem Windows’ og Linux’ filsystemer var en lille smule bedre. WSL 2’s brug af en 9p-server til at håndtere disse overførsler sænker hastigheden, men tillader også mere fleksibilitet og sikkerhed. Det er grunden til, at WSL 1 yder bedre end WSL 2 ved overførsler “på tværs af grænsen”.

Hvis man forestiller sig, at man for eksempel har brug for at køre en database i WSL, men at filerne af en eller anden årsag skal være synlige i Windows, bør man nedgradere til WSL 1. Det er bedst at prøve at holde tunge overførsler inden for WSL-boblen.

Det er endda muligt at føje yderligere drivere til maskinen og formatere dem som Ext4 (eller hvad der nu er ens foretrukne Linux-filsystem) fra WSL. Man vil ikke kunne se dem fra Windows-siden (i det mindste ikke uden ekstra redskaber), men overførsel af store filer eller håndtering af mange vilkårlige I/O-opgaver burde gå meget hurtigere.

Linux-desktoppens år (på Windows)

Det er imponerende at køre grafiske applikationer, og det næste skridt bliver at køre en komplet desktop. Hvad venter du på?

Det viste sig at være lidt tricky at få en Linux desktop til at køre på WSL 2.0 på Windows 11. Det skal siges, at WSL er lavet til at afvikle applikationer, ikke til at fungere som en konventionel virtuel maskine. Det er ikke ret overraskende, at Gnome og KDE ikke virkede. De kræver, at alle mulige daemons og tjenester kører i baggrunden og holder alle komponenterne sammen.

Tapre sjæle har formået at få Xfce-desktoppen til at arbejde fint på Windows 10 med Ubuntu 18.04, men det duede ikke hos os på Windows 11 med Ubuntu 20.04. Hvis du kører Windows 10, kan det anbefales at prøve at køre Xfce via X410-serveren. Det er kun et spørgsmål om at tilføje:

$ sudo apt install xfce4

Nu skal du indstille miljøet DISPLAY korrekt. En markant ændring i WSL 2 er, at 127.0.0.1 i WSL ikke refererer til det rigtige loopback-interface i Windows (hvor X410-serveren ville høre efter). Derfor skal vi finde frem til WSL-adressen og opdatere DISPLAY i overensstemmelse hermed.

X410 er en velrenommeret, men af og til overset X-Server til Windows 10.
Vi skal dog bruge en X411.

Ifølge anvisningerne på https://x410.dev/cookbook/wsl/using-x410-with-wsl2 kan man udlede den af /etc/resolv.conf på WSL, og så mangler der kun at bede X410 om at tillade “Public”-forbindelser. Du vil formentlig gerne bruge Windows Defender Firewall til at begrænse det (hvis din maskine ikke på anden vis er beskyttet af firewall). Kør så xfce4-session inden i WSL.

Anlæg en anden synsvinkel

Selvom det går uden for WSL’s domæne, er det stadig rart at have en Linux-desktop på Windows 11 – om ikke andet så for at vise, hvordan den nymodens desktop klarer sig i forhold til noget, der er velprøvet. Da det ikke duede at bruge en X-server på Windows, ville vi prøve med en anden tilgang: Vi ville bruge Windows’ egen Remote Desktop Protocol (RDP) til at få forbindelse til en desktop, der kører i WSL2.

For at kunne gøre det installerede vi Xfce i Ubuntu med den ovenstående kommando (bemærk, at i nogle situationer er man nødt til også at installere xfce-terminal eksplicit), og derefter installerede og startede vi Xrdp:

$ sudo apt install xrdp
$ sudo /etc/init.d/xrdp start

Bemærk det gamle Sys-V-agtige init-script. WSL bruger ikke Systemd, og det vil afgjort glæde nogle mennesker, men det er også en del af forklaringen på, at man ikke kan bruge Gnome her lige nu. Men det var en sidebemærkning. Start Remote Desktop Connection i Windows, og opret forbindelse til localhost:3389.

Til sidst bar vores anstrengelser frugt, og vi blev budt velkommen af den minimale, men prægtige Xfce-desktop.

Du får en advarsel om, at fjerncomputerens identitet ikke kan verificeres, men eftersom fjerncomputeren her faktisk er lokal, er der ikke noget at bekymre sig om. Nu bør der komme et login-skærmbillede, og her skal man vælge Xorg-sessionen og bruge sine WSL-informationer til at logge ind. Første gang virkede det ikke for os, og det gjorde os nervøse, fordi tiden var ved at løbe ud.

Vi oplevede en lettere nedslående tom skærm. Så forsvandt den, og det gjorde vores håb også. Vi kom i tanker om, at X-sessioner er komplicerede sager, og vi nærede ikke de store forventninger til, at det følgende hack ville fungere. Men det gjorde det! Og det gør det forhåbentlig også for dig. Lav en trivial sessionsfil i din hjemmemappe således:

$ echo xfce4-session > ~/.xsession

Prøv at logge ind igen. Hvis det ikke virker, kan du altid logge ud af WSL, lukke det og genstarte det ved at skrive:

$ logout

wsl –shutdown

ubuntu

Vores session syntes at dø, hver gang Windows’ screensaver blev aktiveret, hvilket nødvendiggjorde dette skridt i en række tilfælde. Så snart du får det til at fungere, vil du bemærke, at billedkvaliteten ikke er fuldstændig perfekt, men det kan man justere ved at give serveren mere båndbredde. Gå ud af Xrdp, og rediger configfilen med:

$ sudo nano /etc/xrdp/xrdp.ini

Dernæst finder du værdien max_bpp og ændrer den fra 32 til 128. Herunder tilføjer du linjen

xserverbpp=128

Nu genstarter du Xrdp med:

$ sudo /etc/init.d/xrdp restart

Så burde du have en skarpere og lidt mere lydhør computer.

Hardware-accelereret WSL

WSL understøtter arbejde med en virtuel gpu, således at Linux-programmer kan drage nytte af højtydende grafikkort og køre beregninger (ikke spil på dette niveau) ved en hastighed, der er tæt på den oprindelige. Der findes også en DirectML-backend til TensorFlow (se https://github.com/microsoft/DirectML), som muliggør hurtige maskinlærings-eksperimenter på Direct3D 12-understøttet hardware.

Hertil kommer, at d3d12-driveren i foråret 2021 blev en officiel del af open source-stakken Mesa 21.0. Hvis man vil gøre brug af den og sætte fut i sine Blender-renderinger eller noget andet, skal man måske opdatere sin Windows gpu-driver til en, der understøtter WDDM 3.0. Nvidias WSL CUDA-drivere bliver betragtet som offentlig preview-software og skal leveres til Windows Insiders via den normale Windows Update-kanal.

Man kan også hente dem fra https://developer.nvidia.com/cuda/wsl. Ejere af AMD-grafikhardware kan få preview-driverne hos www.amd.com/en/support/kb/release-notes/rn-rad-win-wsl-support. Intels kan man finde hos https://bit.ly/lxf282-intel-drivers. Det er kun Ubuntu LTS’er, der er tilgængelige på WSL, de er ikke med i alle disse udviklingstrin. Derfor kan man overveje at installere Arch eller en anden distro.

Man kunne også overveje Canonicals Ubuntu på Windows Community Preview. Læs mere, og følg downloadlinkene på https://ubuntu.com/blog/announcing-ubuntu-on-windows-community-preview-wsl-2.

Til ikke-linux-eksperter

Hvis du er noget af en Windows-ekspert, men ikke har megen erfaring med Linux, kan denne fjern-desktop være et glimrende undervisningsmateriale. Den er et fikst alternativ til en virtuel maskine.

Man kan ikke køre Gnome, og man kan åbenbart heller ikke køre Gnome Software, Gvim virker dog udmærket.

Og ligesom med en virtuel maskine kan man eksportere installationen og køre den på en anden maskine eller på den samme, hvis man ønsker en praktisk backup, før man afprøver nogle dristige øvelser på kommandolinjen. Man eksporterer en WSL-afbildning som en tarball ved at skrive dette ved en kommandoprompt:

wsl.exe --export Ubuntu c:\ubuntu.tar

idet man erstatter Ubuntu med en eventuel anden distro. Man kan overskue, hvilke distroer man har installeret, med

wsl.exe --list --all

Hvis man får brug for at genimportere en tarball, kan man give distroen et andet navn:

wsl.exe --import UbuntuTweak c:\mywsl c:\ubuntu.tar

Man erstatter c:\mywsl med den mappe, man vil lagre distroen i. Så kan man boote den med:

wsl.exe --distribution UbuntuTweak

Efter nogle dages arbejde kan WSL-distroer blive store (se størrelsen med kommandoen df i WSL) eller ubrugelige. Man kan rense en distro med denne besværgelse:

wsl.exe --unregister UbuntuTweak

Styresystemer i Duel

Linux har altid prøvet at håndtere Windows’ særheder, og på trods af uenigheder er det gået ganske udmærket.

Ejere af et moderne UEFI-system bør kunne annullere alle uønskede ændringer, der skyldes installation af et nyt operativsystem, forudsat at man kan komme ind i UEFI-indstillingerne. UEFI booter en afbildning fra EFI-partitionen eller live-mediet, og userspace-værktøjer (både på Windows og efimgr på Linux) kan ændre bootrækkefølgen og i nogle tilfælde lave ulykker.

Man forventer som regel (selvom det ikke nødvendigvis er at foretrække), at et nyligt installeret styresystem lægger sig selv øverst i bootrækkefølgen. Det betyder ofte, at Windows booter straks, og man kan kun komme til UEFI-indstillingerne og ændre rækkefølgen ved at holde Shift-tasten nede, mens man lukker ned fra startmenuen. Det bør fremkalde en mulighed for at genstarte til indstillinger.

Vores erfaringer var dog heldigvis smertefri. Vi opgraderede Windows 10 på en tiende-generations-Dell XPS, der var indstillet til at boote i Ubuntu, og sandelig om ikke det oprindelige bootvalg var intakt.

Ikke blot bootede Ubuntu korrekt, den gamle Grub-test til kædeindlæsning af Windows fungerede også. Vi var vist heldige her, men selvom vi ikke var det, er boot af Windows blot et spørgsmål om at definere UEFI-indstillingerne eller fremkalde en bootmenu ved start. Hvis UEFI ikke giver os dette valg, kan vi genstarte til firmware-opsætningen med

$ systemctl reboot --firmware-setup

Situationen er anderledes for ældre BIOS-maskiner. Hvert harddiskdrev kan have sin egen Master Boot Record (MBR), og installerede styresystemer kan lægge deres bootloadere her. I hvert fald den første af deres bootloadere, idet MBR kun udgør omkring 440 bytes, og moderne bootloadere såsom Grub er komplicerede, og derfor indeholder MBR et basisprogram, der fortæller maskinen, hvor på harddrevet resten af bootloader kan findes.

Moderne UEFI gør det svært for Windows at forhindre Linux i at boote.

Grub version 1 havde også en Stage 1.5, der fyldte omkring 30 kB, umiddelbart efter MBR. Den indeholdt filsystem-drivere til den partition, som indeholdt Stage 2. Grub v2 behøver ikke Stage 1.5, fordi Stage 1 peger direkte til den logisk blok-adresse, som indeholder Stage 2 (uden hensyn til filsystemer), og Stage 2 indlæser også den centrale configfil /boot/grub/grub.cfg.

Vi har længe anbefalet at holde separate styresystemer på separate drev, og en af de vigtigste grunde er at undgå, at et styresystems bootloader træder et andets over tæerne. Det er lige så meget et problem mellem forskellige Linux-distroer, som det er det mellem Linux og Windows. Linux-distroer er normalt gode nok til at give brugeren en bootmenu, men anvisninger til sekundære distroer respekterer ikke nogen af instillingerne i /etc/default/grub, og det kan udløse problemer.

Hvis en af disse distroer er Arch Linux, bliver den ofte ikke genkendt af grub-install -scripts. Installation af pakken lsb-release på Arch-siden burde løse dette problem. Windows har ingen anfægtelser over at ignorere enhver anden bootloader på sit drev. Det er nemt nok at få Grub tilbage, når dette sker, men det er bedre at undgå, at problemer opstår, ved at give Windows sit eget drev.

Grove Windows-opdateringer

Dette kan imidlertid være utilstrækkeligt. Vi har ofte læst opslag, der meddeler, at Windows-opdateringer frejdigt har færdedes, hvor de ikke havde noget at bestille, og vi har været i branchen længe nok til at se denne adfærd med egne øjne.

Det kan dreje sig om at plante gendannelses-partitioner på andre drev, ødelægge LVM- og RAID-volumes og alle mulige former for anden uortodoks opførsel. Windows har intet at vinde ved dette, men at leve ved siden af et andet styresystem har aldrig været dets kop te, og det er derfor ikke overraskende.

Bortset fra kampen om bootloaders og (måske) tvivlsomme .docx-filer er et af de vigtigste stridspunkter mellem Windows og andre operativsystemer NTFS-filesystemet. Det er ikke kun et problem for Linux – det har også altid været tricky at få macOS og Android til at skrive til disse volumes uden proprietære redskaber. På Linux havde vi i det mindste NTFS-3G-driveren, men den gjorde ikke megen nytte. Heldigvis er hjælpen nær i form af en ny kernedriver (se boksen overfor).

Vi bør heller ikke glemme NTFS-3G. Den officielle WSL-dokumentation advarer om, at den omvendte situation, nemlig overførsler fra inden i WSL til uden for, heller ikke vil foregå med raketfart. Det er et mindre tilbageskridt i forhold til WSL 1, som, fordi det ikke havde en ægte Linux-kerne, kunne strømline overførsler på tværs af filsystemer. Visse I/O-tunge belastninger på Linux-filsystemer, der var hæmmet under WSL 1, burde nu fungere langt bedre.

Windows’ diskhåndteringsredskab erkender modstræbende, at vores Linux-parti-tion findes, men tilbyder ingen information.

Foruden NTFS (se til højre) har Paragon Software en aftale med Microsoft, der tillader firmaet at markedsføre og licensere sine egne exFAT-implementationer. Det kunne være blevet en gevinst for Paragon, men Microsoft open-sourcede i realiteten exFAT i 2019.

Eller mere nøjagtigt: Man offentliggjorde filesystemets specifikationer og tilbød fri licensering til ethvert andet medlem af Open Invention Network (OIN), der ejer en defensiv patentpulje, hvortil Microsoft og andre har bidraget med deres IP. Det betød, at arbejdet med at skrive en driver blev overladt til miljøet, og takket være Samsung blev den føjet til Kernel 5.7.

Der fandtes tidligere en exFAT-kernedriver, som først dukkede op i 5.4. Den byggede på en gammel driver til en af Samsungs Android-tablets, men koden endte på GitHub i 2013 og blev senere open-sourcet af Samsung. Den kode havnede i kernel-stagingtræet, hvor den blev forbedret, før den blev afløst af Samsungs nyere code-drop.

Netværksfilsystemer er også blevet forbedret af Samsung. Kernel 5.15 omfatter en ny driver, KSMBD, til delinger over den seneste version af Windows’ SMB3-protokol (Server Message Block). Det burde i første omgang medføre hurtigere overførsler, men på længere sigt er målet at opnå et slankere produkt, som man nemt kan tilføje nye funktioner i takt med, at protokollen bliver udviklet.

Det står i kontrast til et userspace ved navn Samba – et stort projekt, som ikke blot omfatter håndtering af filer over SMB, men også klientværktøjer, autentificering, Active Directory og meget andet. Således er KSMBD udviklet til at virke i harmoni med Samba, ikke til at afløse det.

Højt oppe på KSMBD’s huskeliste finder man implementering af RDMA-support (Remote Direct Memory Access), også kendt som SMB Direct, der muliggør overførsler, som springer protokolkrav over – de udgør i øjeblikket en flaskehals for mobile og indlejrede systemer.

Samba er vigtig for enhver, der vil bruge en Linux-maskine på et Windows-netværk, og i de fleste tilfælde virker det uden videre. Der er dog nogle grænsetilfælde. Mange er kommet ud for, at den gamle “LANman”-autentificering ikke længere er understøttet, og derfor er det ikke umiddelbart muligt at få forbindelse til SMB-delinger på Windows XP-maskiner (eller ældre).

Disse maskiner bruger også som standard en ældre version af protokollen, og hvis Samba skal lege med, er den udbredte løsning at føje de følgende linjer til /etc/samba/smb.conf:

server min protocol = NT1
lanman auth = yes
ntlm auth =yes

Det svækker naturligvis sikkerheden, men hvis man stadig bruger Windows XP på sin netværksserver, har man næppe grund til at bekymre sig om sikkerhed. Der findes et registreringsdatabase-hack, der udløser NTLMv2-autentificering, på https://kb.iu.edu/d/atcm.

Med den kan man nyde den luksus at vælge lanman auth = ntlmv2-only i stedet for den ovennævnte linje. Men SMBv1 som protokol er sårbar over for WannaCry-lignende angreb, og derfor bør man nok holde fingrene væk. Og med denne hilsen til gamle stridigheder slutter vi vores rejse ind i den fagre nye verden af Linux på Windows og Windows’ kærlighed til Linux.

Paragon NTFS3-driver – en nyttig sag

Efter at vi i årevis har skullet nøjes med NTFS-3g FUSE-driveren (Filesystem in USErspace) til at læse og skrive til Windows NTFS-volumes i Linux, er der omsider kommet en driver til kernen. Der har faktisk længe eksisteret en kernedriver (siden 2001), men den gav kun read-only-support og blev overset af de fleste.

NTFS-3g var en nyttig krykke til folk, som arbejdede på dualboot-systemer, men sammenlignet med oprindelig NTFS var dens ydelse svag. Navnlig på ældre systemer brugte den en masse cpu-cyklusser på at skrive ganske få bits. Den nye kernedriver, der hedder NTFS3, kommer fra Paragon Software, der er en kommerciel leverandør af redskaber til filsystemer, partitionering og netværkshåndtering.

NTFS har eksisteret siden 1993 og er af langt mindre kommerciel interesse, end den tidligere har været. Microsoft har overhalet den med nye versioner af Windows, og derfor besluttede Paragon at open-source den forrige år. Det var en stenet vej, der førte dertil: Paragons første forsøg på at smide 27 kB spaghettikode på kernen blev mødt med øjeblikkelig afvisning. Men efter 22 forsøg og gode råd fra miljøet er koden imidlertid landet i Kernel 5.15, som formentlig er blevet frigivet, når du læser denne tekst.