Typiske fejl ved opdatering af mellemliggende versioner af Ubuntu

Hvis du lige har installeret en mellemliggende version af Ubuntu og har fået at vide, at "Opdateringer kan ødelægge systemet"Det er normalt at være lidt bekymret. Ikke-LTS-versioner lover nyere software, men de fungerer også som testområder, og det rejser rimelige spørgsmål: Skal jeg opdatere med ro i sindet, eller er det bedre at geninstallere hver gang en ny version kommer ud?

I denne artikel vil vi trin for trin gennemgå Typiske fejl ved opdatering af mellemliggende versioner af Ubuntu (og generelt ved opdatering af Ubuntu), hvad der forårsager dem, hvordan man undgår dem, og hvad man skal gøre, når det er for sent, og noget er gået i stykker. Vi vil også se på det specifikke tilfælde af... "Oxidation" af systemet med rustHvor Ubuntu 25.10 ikke lykkedes, og hvorfor, på trods af skræmmepunkterne, mellemliggende versioner er nøglen til at gøre LTS-udgivelser klippefaste. Lad os dykke ned i det med en guide om Typiske fejl ved opdatering af mellemliggende versioner af Ubuntu. 

LTS-versioner vs. mellemversioner: hvilken risiko tager du egentlig?

I Ubuntu-økosystemet eksisterer der to meget forskellige udgivelsesplaner side om side, og det er vigtigt at forstå dem for at vide... Hvilke problemer kan du støde på, når du opdaterer?:

• LTS-versioner (langtidssupport)hvert 2. år, med 5 års standardunderstøttelse (og mere med Ubuntu Pro).
• Mellemliggende versionerDe udgives hver 6. måned og har kun 9 måneders support.

LTS-versionerne er designet til dem, der leder efter maksimal langsigtet stabilitetServere, seriøse arbejdsmiljøer, produktionsteams eller brugere, der ikke ønsker overraskelser. De opretholder en mere konservativ kerne og desktopversioner og biblioteker, der er grundigt testet.

Mellemliggende versioner er derimod det terræn, hvor Canonical tør introducere dybtgående ændringer i systemetNye kerner, nyere versioner af GNOME, biblioteker og, som vi har set for nylig, endda omskrivninger af kritiske Rust-værktøjer. De er ideelle for alle, der ønsker nyeste software, afprøve nye funktioner eller samarbejde ved at rapportere fejl ... men det indebærer at acceptere, at noget kan gå galt.

Hvis du bruger en mellemliggende version som dit daglige operativsystem, er det vigtigt at forstå, at:

• Du skal opdatere hver 9. måned (ca.) ved hjælp af do-release-upgradeeller geninstallere fra bunden
• Radikale forandringer kan komme først her, og chancer for at finde alvorlige fejl De er større end i LTS.
• Det anbefales kraftigt at have regelmæssige sikkerhedskopier og en vis tolerance for at pille ved systemet, hvis noget går i stykker.

For en computer, der bruges dagligt til spil, virtuelle maskiner og let udviklingsarbejde, kan en mellemversion bruges uden problemer, men med et køligt hoved: Din pc kommer ikke til at eksplodereMen du vil heller ikke have den samme ro i sindet som med en LTS.

Rust-sagen i Ubuntu 25.10: når "testområdet" bliver mærkbart

I en af ​​de seneste mellemversioner tog Ubuntu et særligt vigtigt skridt: begynder at "ruste" systemetDet vil sige, at erstatte nøglekomponenter skrevet i C med Rust-reimplementeringer med henblik på større sikkerhed og modernisering af systemkonstruktionsprocessen.

Denne bevægelse omfattede to meget betydelige ændringer: indførelsen af værktøjer coreutils (genimplementering i Rust af GNU coreutils) og sved-rs (også en omskrevet sudo i Rust). Og lige dér dukkede der adskillige fejl op, der perfekt illustrerer risiciene ved mellemliggende versioner.

Hvad er uutils og coreutils, og hvorfor afbrød en fejl i "date -r" opdateringer?

Coreutils er hjertet i kommandolinjen i ethvert Unix-lignende system: kommandoer som ls, cp, rm, mv, date o cat De bruges konstant, selvom du ikke er klar over det. Uden dem er skallen praktisk talt hjælpeløs.

Traditionelt er disse værktøjer skrevet i C under GNU coreutils-paraplyen. værktøjer coreutils genimplementerer dem i Rust med det mål at tilbyde versioner multiplatform (Linux, macOS, Windows) og udnytte sprogets sikkerhed i hukommelsen. Canonical besluttede at integrere denne variant i en mellemversion til test i stor skala.

Det store problem kom med kommandoen dateSpecifikt med muligheden -rDenne indstilling bruges til at hente den seneste ændringsdato for en fil, for eksempel:

date -r /etc/fstab

I Rust-implementeringen, der kom til Ubuntu 25.10, argumentet -r Den var buggetI stedet for at returnere den faktiske dato, hvor filen blev ændret, returnerede den altid det aktuelle systemtidspunkt.

Det kan virke trivielt, men den lille fejl forårsagede to meget alvorlige konsekvenser:

• Backup-scriptsMange backup-scripts kontrollerer datoen for backup-filerne for at afgøre, om der skal oprettes en ny. date -r Der står, at de altid er fra "i dag", scriptet antager, at kopien allerede er lavet, og Den kører ikke backup'en.
• Automatiske opdateringer "uovervågede opgraderinger"Ubuntu bruger den samme logik til at bestemme, hvornår den sidste opdateringskontrol blev udført. date -r Den returnerer altid "nu", systemet tror, ​​at kontrollen lige er udført, og Stop med at søge efter og installere automatiske opdateringer.

Det mærkelige er, at for den gennemsnitlige bruger så alt ud til at gå godt: Du kunne opdatere manuelt uden problemer med sudo apt update && sudo apt upgradeSystemet til lydløse opdateringer var dog i stykker uden at der blev udløst nogen åbenlyse advarsler. Et perfekt eksempel på, hvordan en logisk fejl i et simpelt værktøj kan have kaskaderende konsekvenser.

Denne fejl blev hurtigt opdaget, fordi den også påvirkede systemets egen testning. Canonical udgav en pakkeopdatering. rust-coreutils (for eksempel til en typeversion) 0.2.2-0ubuntu2.1 eller senere) der korrigerede adfærden hos date -r og gendannede normal drift af uovervågede opdateringer.

sudo-rs: sikkerhedssårbarheder i privilegieeskalering

Det andet sæt problemer kom med sved-rs, genimplementeringen af sudo i Rust. Sudo er sandsynligvis den mest følsomme kommando i systemetfordi det giver dig mulighed for at udføre handlinger som root på en kontrolleret og sikker måde.

I visse specifikke sudo-rs-konfigurationer blev der opdaget to betydelige sårbarheder, som gennemgik en formel proces Koordineret sårbarhedsafsløring (CVD) før de blev offentlige:

• Delvis adgangskodeeksponering ved timeoutNår du kører en kommando med `sudo`, har du en begrænset tid til at skrive adgangskoden. Hvis du begynder at skrive, men ikke trykker på Enter, før timeren udløber, burde `sudo` lukke inputfeltet lydløst. Med den fejl, der blev fundet i visse konfigurationer, hvis timeouten udløb, mens du skrev, Den del af adgangskoden, du havde indtastet, kunne vises på konsollenForestil dig at løbe sudo apt updateBegynd at skrive "mitadgangskode" og bliv distraheret; når tiden udløb, dukkede din adgangskode, eller en del af den, op i almindelig tekst på terminalen.
• Forkert genbrug af legitimationsoplysningerDen anden sårbarhed tillod en lokal angriber, under visse konfigurationsbetingelser, at Undgå gengodkendelse ved at udnytte allerede gyldige sudo-legitimationsoplysninger længere end forventet.

Disse fejl blev rettet i senere versioner af sudo-rs (f.eks. 0.2.8-1ubuntu5.2 eller lignende) og Canonical udgav en Ubuntu Sikkerhedsmeddelelse (USN) til hurtigt at udrulle programrettelser til alle berørte brugere.

Den vigtigste lektie her er, at Rust er ikke en tryllestavDet tilbyder høj beskyttelse mod hukommelsesfejl, men det forhindrer ikke fejl i logik, validering eller design. Omskrivning af kritiske værktøjer involverer uundgåeligt en afprøvningsperiode, der er bedre at overlade til mellemversioner, ikke i en LTS-udgivelse.

Hvorfor disse fejl forstærker værdien af ​​mellemliggende versioner

Det lyder måske kontraintuitivt, men at se den slags fejl i en version som Ubuntu 25.10 er ikke så meget en katastrofe som demonstrationen af, at testmodellen virkerDer er flere positive punkter, der er værd at fremhæve.

På den ene side er mellemversioner en kontrolleret testfeltCanonical kan introducere betydelige ændringer (såsom implementeringen af ​​uutils og sudo-rs), vel vidende at effekten vil være begrænset til en 9-måneders livscyklus og allerede vil have en højere risikotolerance blandt brugerne. Hvis noget går galt, bliver det hurtigt rettet, og den næste LTS-udgivelse lanceres med teknologien allerede moden.

På den anden side demonstrerer det frie software-fællesskab endnu engang sit lydhørhed og gennemsigtighedFejlen af date -r En bruger rapporterede det; Ubuntu-teamet og uutils-udviklerne prioriterede det og løste det inden for få timer. Sudo-rs-sårbarhederne fulgte den formelle CVD-proces, blev rettet i det oprindelige projekt og nåede Ubuntu med en offentlig sikkerhedsadvarsel.

Desuden tvang disse hændelser til at tilføje nye regressionstests I uutils, i nogle tilfælde endda mere omfattende end dem i GNU coreutils. Med andre ord, hele økosystemet drager fordel: ikke blot er den specifikke fejl rettet, men fremtidssikringen styrkes.

Det er normalt at støde på problemer undervejs. Det vigtige er, at de opdages, hvor de skal være (i mellemliggende versioner), løses hurtigt og bruges til at levere et mere robust, moderne og i sidste ende mere sikkert system til den næste LTS-udgivelse.

Almindelige fejl ved opdatering af pakker i Ubuntu (og hvordan man undgår dem)

Ud over det specifikke tilfælde med Rust, støder de fleste brugere på mange flere "almindelige" opdateringsfejlØdelagte afhængigheder, beskadigede pakkedatabaser, APT-blokke, pladsmangel, problemer med arkivet… Alt dette påvirker både LTS og mellemliggende versioner.

Det er værd at gennemgå de mest almindelige årsager og deres løsninger, fordi et "defekt" system efter en opdatering ofte ikke er Canonicals skyld, men snarere en kombination af faktorer. Usædvanlige arkiver, gamle PPA'er, begrænset diskplads og tidsbegrænsninger.

De hyppigste årsager til fejl ved opdatering af Ubuntu

Når en sudo apt update eller en sudo apt upgrade De begynder at begå fejl; der er næsten altid en eller flere personer ansvarlige for denne liste:

• Beskadigede eller forældede pakkelister: oplysningerne i /var/lib/apt/lists er blevet beskadiget eller er fuldstændig forældet.
• Uopfyldte behovpakker, der kræver andre, som mangler eller ikke passer til den aktuelle version.
• Pakkehåndtering låsten anden proces bruger APT eller dpkg (for eksempel Softwarecenteret).
• Utilstrækkelig plads i rodpartitionen (/)Der er intet sted at downloade eller udpakke opdateringerne.
• Ødelagte lagre eller PPA'er: servere nede, manglende PPA'er, GPG-signaturfejl eller 404-URL'er.

De kan rettes med et par velbrugte kommandoer. Den dårlige nyhed er, at hvis du begynder at slette eller rode med ting på en tilfældig måde, kan du gøre alting værre. Så det er bedst at tage det et skridt ad gangen.

Opdatering af lister og pakker: det første obligatoriske trin

Før man går amok, er det altid en god idé at udføre de grundlæggende kommandoer opdater pakkeoplysninger og anvend ventende opdateringer som normalt:

sudo apt-get update
sudo apt-get upgrade

Dette giver APT mulighed for at downloade pakkelisterne igen og opdatere alle installerede pakker, der kan opgraderes, uden at fjerne noget vigtigt. Hvis alt går godt, kan du afslutte med:

sudo apt-get dist-upgrade

Denne sidste kommando er mere aggressiv: Den løser nye afhængigheder og kan fjerne forældede pakker. når det er nødvendigt, hvilket ofte låser op for tidligere modståede opdateringer.

Ødelagte afhængigheder: når "ikke alle opdateringer kan installeres"

En klassisk besked, når man forsøger at opdatere fra den grafiske brugerflade eller fra terminalen, er, at "Ikke alle opdateringer kan installeres"at tilbyde en "delvis opdatering", som det næsten aldrig er en god idé at acceptere uden videre.

I de fleste tilfælde er problemet ødelagte eller uopfyldte afhængighederFor at tvinge APT til at rette op på situationen, brug:

sudo apt-get install -f

Denne kommando fortæller systemet, at Prøv at løse afhængighedsproblemetInstallerer det, der mangler, eller fjerner det, der blokerer det. Når det er udført, er det normalt en god idé at køre det igen.

sudo apt-get upgrade

og tjek om alt nu kan opdateres uden at advarslen om delvis opdatering vises.

Ryd op i gamle pakker og caches, der roder op i dit system

Over tid akkumuleres systemet afhængigheder, du ikke længere bruger, og downloadede .deb-filer som bare optager plads. Dette gør ikke kun tingene langsommere, men kan også bidrage til nogle opdateringsproblemer.

Til grundlæggende rengøring anvendes følgende:

sudo apt-get autoremove
sudo apt-get clean

Den første fjerner pakker, der ikke længere er afhængige af, og den anden sletter cachelagrede .deb-pakker. Derefter anbefales det at opdatere igen. I mellemversioner, hvor ting installeres og afinstalleres oftere, Det er næsten obligatorisk at køre disse kommandoer fra tid til anden.

APT-pakke- og blokdatabase

Et andet klassisk eksempel er fejl relateret til dpkg eller med låsefiler som forhindrer APT i at udføre sit arbejde. Dette sker normalt, hvis en installation er blevet afbrudt, hvis en proces hænger, eller hvis Software Center er blevet pludselig lukket.

Hvis du ser meddelelser som "blokken kunne ikke hentes" /var/cache/apt/archives/lockentendpkg "Han har travlt." Du kan prøve det først. med:

sudo killall apt apt-get

Dette forsøger at lukke alle resterende APT-processer. Hvis fejlen fortsætter, kan du manuelt slette låsefilerne (forsigtigt):

sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock
sudo rm /var/cache/apt/archives/lock

Dernæst er det tilrådeligt at omkonfigurere alle pakker, der ikke blev færdige, med:

sudo dpkg --configure -a

og opdater lister og pakker igen med sudo apt-get update y sudo apt-get upgrade. Slet ikke ting fra /var/lib/dpkg uden videreEller du kan slå systemet ud.

Fejl i arkivet: BADSIG, Hash Sum, 404 og lignende

Mellemliggende versioner har en tendens til at tiltrække PPA'er, tredjepartsrepositorier og diverse eksperimenter. Dette øger sandsynligheden for at støde på fejl som f.eks. BADSIG, Hash Sum-mismatch, GPG og 404-fejl ved opdatering.

Nogle af de mest typiske tilfælde og hvordan man løser dem er:

• BADSIG-fejl eller problemer med GPG-signaturerDette indikerer, at en lagersignatur er ugyldig, eller at oplysningerne er blevet beskadiget. En måde at fremtvinge listegenerering på er:

  cd /var/lib/apt && 
  sudo mv lists oldlist && 
  sudo mkdir -p lists/partial && 
  sudo apt-get clean && 
  sudo apt-get update
  

• GPG-fejl: Følgende signaturer kunne ikke verificeresDette sker normalt med PPA'er, der ikke har installeret deres offentlige nøgle korrekt. Løsningen involverer tilføj den korrekte GPG-nøgle til systemet ved hjælp af det id, der vises i fejlmeddelelsen.
• Hash Sum-fejl eller Hash Sum-uoverensstemmelseKontrolsummen for pakkerne eller listerne stemmer ikke overens, enten på grund af lokal korruption eller en uoverensstemmelse med serveren. Dette rettes normalt med:

  sudo rm -rf /var/lib/apt/lists/*
  sudo apt update
  

• Fejl 404 eller "Kunne ikke hente"Lageret eller PPA'en findes ikke længere, er blevet flyttet eller er nede. I disse tilfælde skal du... fjern det problematiske arkiv fra "Software og opdateringer" eller ved at redigere /etc/apt/sources.list og filerne i /etc/apt/sources.list.d/og foretrækker altid den "primære server".

Generelt set, jo flere ikke-Ubuntu-repositories du tilføjer, desto større er chancen for, at... en opgradering af en mellemversion bliver kompliceretDet er næsten lige så vigtigt at vedligeholde en ren kildeliste som at opdatere selve systemet.

Mangel på diskplads: den stille fjende

En anden ofte undervurderet årsag til opdateringsfejl, især på bærbare computere med begrænsede SSD'er, er simpelthen ikke nok ledig plads i rodpartitionenSystemet skal bruge plads til at downloade, udpakke og konfigurere de nye pakker.

For tjek diskforbrug Det bruges:

df -h

Hvis du ser det / Den er næsten 100% fuld, nu er det tid til at frigøre plads: slet store personlige filer, ryd op i gamle pakker med sudo apt-get autoremove y sudo apt-get clean, slet gamle kerner, hvis de har ophobet sig osv. At forsøge en større opgradering uden ledig plads er en opskrift på katastrofe..

Opdater version med do-release-upgrade (og ikke tilfældigt)

Når det er tid til at hoppe fra én version til en anden (for eksempel fra en mellemversion til den næste eller fra en ældre LTS-version til en nyere), er den anbefalede fremgangsmåde Brug altid det officielle værktøj i stedet for at ændre arkiver manuelt.

Den grundlæggende procedure fra terminalen ville være:

sudo apt update && sudo apt upgrade && sudo apt dist-upgrade
sudo do-release-upgrade

Kommandoen do-release-upgrade Den kontrollerer kompatibilitet, administrerer softwarekilder, spørger, hvad der skal gøres med ændrede konfigurationsfiler, og generelt minimerer sandsynligheden for at efterlade systemet i limboDu skal dog være opmærksom under processen, da den ofte stiller vigtige spørgsmål (overskrivning af konfigurationer, genstart af tjenester osv.).

Teknisk set er det muligt at "nedgradere" ved at ændre /etc/apt/sources.list, ændring af navne på arkiver (for eksempel fra cosmic a bionic) og tvinger en apt dist-upgrade I den modsatte retning, men det er en delikat manøvre, fuld af advarsler og med en høj sandsynlighed for, at systemet bliver ustabilt. Hvis du virkelig har brug for at vende tilbage til en tidligere version, er den bedste fremgangsmåde at geninstallere fra bunden. med din ISO og gendan dine sikkerhedskopier.

LivePatch, Ubuntu Pro og LTS' rolle i stabilitet

For mange brugere er den største frygt omkring systemopdateringer at skulle genstarte på et ubelejligt tidspunkt. I servermiljøer er dette et alvorligt problem. Det er her, [løsningen/værktøjet] kommer ind i billedet. Ubuntu Livepatch, tilgængelig i LTS-versionerne.

Livepatch giver dig mulighed for at anvende "hotte" kernel-patchesDette indlæser den nye kode i hukommelsen og omdirigerer kald til de korrigerede funktioner uden at kræve en genstart. Funktionen er en del af tilbuddet fra Ubuntu Advantage / Ubuntu Pro, en Canonical-tjeneste, der forlænger support i op til 10 år, tilføjer sikkerhedsrettelser til titusindvis af pakker og tilbyder professionel support.

For en hjemmebruger er det mest interessante ved dette at forstå, at LTS-versioner er meget gearet til at tilbyde et niveau af stabilitet og forretningsstøtteDu kan aktivere Livepatch med:

sudo snap install canonical-livepatch
sudo canonical-livepatch enable [TOKEN]

ved hjælp af et gratis token (op til 3 enheder) knyttet til din Canonical-konto. Hvis du nogensinde beslutter dig for, at du ikke ønsker det, kan du deaktivere det fra fanen "Livepatch" i værktøjet Yderligere drivere eller fra kommandolinjen.

Denne klare adskillelse mellem LTS-verdenen (med Livepatch, Pro, lange cyklusser) og verdenen af ​​mellemversioner (med aggressive ændringer og 9 måneders support) forstærker ideen om, at For at spille aggressivt med nye funktioner giver det mening at gøre det i mellemversionerne.og efterlader LTS til de tidspunkter, hvor du har brug for absolut ro i sindet.

Hold Ubuntu opdateret: terminal, softwarecenter og opdateringer uden internet

at beholde din UbuntuUanset om det er mellemliggende eller langtidsholdbar, er det ideelle at kombinere regelmæssige opdateringer med gode sikkerhedskopieringsrutiner og en vis orden i arkiverne.

Fra terminalen ville det typiske vedligeholdelsesflow være:

sudo apt update
sudo apt upgrade

for at uploade pakkerne til deres seneste versioner, efterfulgt af:

sudo reboot

når opdateringen inkluderer kernen eller kritiske komponenter. Hvis du foretrækker ikke at bruge konsollen, kan du bruge værktøjet "Softwareopdatering" (svarende til "Windows Update" i Ubuntu), som søger efter, downloader og installerer sikkerhedsrettelser, systemopdateringer og opdateringer til installerede programmer.

Selv uden internetforbindelse kan den opdateres ved hjælp af værktøjer som f.eks. apt-offline o apt-mirrorgenerere en pakkeanmodning på offline-maskinen, downloade disse pakker fra et andet Ubuntu-system og derefter anvende dem ved hjælp af:

sudo apt-offline install actualizaciones.zip

Det er en mere besværlig proces, men den demonstrerer, at Ubuntus pakkesystem er fleksibelt nok til at tilpasse sig meget forskellige miljøer.

Kernen og drivere: hvornår skal man opdatere, og hvornår skal man lade det være?

En anden kilde til problemer ved opdatering, især på gaming-pc'er med AMD- eller NVIDIA-grafikkort, er kerne- og proprietære drivereI Linux er de fleste drivere integreret i selve kernen og opdateres sammen med den, uden at vi behøver at gøre noget.

Hvis du dog installerer proprietære drivere (f.eks. proprietære NVIDIA-drivere) eller særlige moduler til Wi-Fi eller andre enheder, kan du muligvis en kerneopdatering i en mellemversion Det kan resultere i ulykker, problemer med affjedringen eller sorte skærme, hvis føreren endnu ikke er vænnet til det.

For dem, der altid har brug for at bruge den nyeste kerne (af hensyn til ydeevne, hardwarekompatibilitet eller simpel nysgerrighed), findes der værktøjer som:

• HovedlinjeEn gratis fork af Ukuu, der giver dig mulighed for at installere og administrere mainline-kerner fra en grafisk brugerflade.

  sudo add-apt-repository ppa:cappelikan/ppa && 
  sudo apt update && 
  sudo apt install mainline
  

• UkuuBetalt version (omkring €16) med en mere poleret brugerflade og avancerede funktioner til håndtering af kerner i forskellige Ubuntu-baserede distributioner.
• UKVærktøjerGratis konsolværktøj til at downloade og installere kerner fra hovedarkivet via GitHub.

  sudo apt install git make wget
  
  git clone https://github.com/usbkey9/uktools && cd uktools
  make
  

At eksperimentere med kerner i en allerede eksperimentel mellemversion tilføjer dog flere variabler til ligningen. Det fornuftige at gøre er Skift ikke blindt kerner Medmindre du har en klar grund (for eksempel for at rette en specifik hardwarefejl) og altid har en tidligere kerne installeret, i tilfælde af at du får brug for at boote fra den ved hjælp af GRUB.

Med hensyn til drivere, hvis du ikke har meget specifikke behov, er den bedste mulighed i Ubuntu at stole på kontrolpanelet. "Flere kontrollører"Dette giver dig mulighed for at skifte mellem open source- og proprietære drivere, der er godkendt af Canonical. Manuel opdatering fra producentens websteder giver kun mening, når den officielle support er virkelig utilstrækkelig.

Hvad skal man kontrollere efter en større opdatering

Efter en versionsopdatering (især hvis du opgraderer fra en mellemversion til en anden, eller fra én LTS-version til den næste), virker alt normalt det samme, men det skader aldrig at bruge et par minutter... tjek at alt stadig er på plads:

• Bekræft at din personlige filer og dokumenterne er, hvor de skal være.
• Tjek det nøgleprogrammer De er stadig installeret og fungerer.
• Gå igennem det igen sudo apt update && sudo apt upgrade i tilfælde af at der er blevet udgivet programrettelser efter generering af billedet af den nye version.
• Test følsomme funktioner såsom dvaletilstand, genoptagelse, lyd, Wi-Fi-netværk og GPU-drivere.
• Sådan tjekker du, hvilken version af Ubuntu du har, og om den stadig understøttes

Hvis noget går galt, er din backup dit sikkerhedsnet: du kan forsøge at rette det (for eksempel ved at geninstallere en pakke eller ændre drivere), velvidende at du i værste fald altid kan gendanne. geninstaller fra bunden og gendan dine data.

I sidste ende er det fuldt ud muligt at bruge en mellemliggende version af Ubuntu som dit daglige operativsystem, hvis du accepterer, at det fungerer som et testområde: du vil være blandt de første til at nyde godt af nye kerner, den nyeste GNOME, teknologier som system-"oxidation" med Rust og forbedringer af ydeevnen, men til gengæld accepterer du en højere sandsynlighed for at støde på fejl som den i date -r eller hændelser med kritiske værktøjer som sudo-rs. Så længe du opretholder gode sikkerhedskopier, skal du kontrollere de arkiver, du tilføjer, overvåge diskplads og bruge officielle opdateringsværktøjer (APT og do-release-upgrade), vil typiske opdateringsfejl være mindre ulemper, der kan løses med et par kommandoer og lidt tålmodighed, uden at det er nødvendigt at geninstallere systemet ved hver versionsopgradering.