LFS systemet vil bli bygget ved å bruke en allerede installert Linuxdistribusjon (som Debian, OpenMandriva, Fedora eller openSUSE). Denne eksisterende Linuxsystemet (verten) vil bli brukt som utgangspunkt for å gi nødvendige programmer, inkludert en kompilator, linker og skall, for å bygge det nye systemet. Velg “development” alternativet under distribusjonsinstallasjonen for å kunne få tilgang til disse verktøyene.

Som et alternativ til å installere en separat distribusjon på din maskin, kan det være lurt å bruke en LiveCD fra en kommersiell distribusjon.

Kapittel 2 i denne boken beskriver hvordan lage en ny Linuxpartisjon og et nytt filsystem. Dette er stedet hvor det nye LFS systemet skal kompileres og installeres. Kapittel 3 forklarer hvilke pakker og oppdateringer som må lastes ned for å bygge et LFS system og hvordan lagre dem på det nye filsystemet. Kapittel 4 diskuterer oppsettet av et hensiktsmessig arbeidsmiljø Vennligst les Kapittel 4 nøye som forklarer flere viktige problemer du må være klar over før du begynner å jobbe deg gjennom Kapittel 5 og utover.

Kapittel 5 forklarer installasjonen av den første verktøykjeden (binutils, gcc og glibc) ved bruk av krysskompileringsteknikker for å isolere de nye verktøyene fra vertssystemet.

Kapittel 6 viser hvordan du krysskompiler grunnleggende verktøy ved å bruke den nettopp bygde kryssverktøykjeden.

Kapittel 7 går deretter inn et "chroot" miljø, der vi bruker de nye verktøyene til å bygge resten av verktøyene som trengs for å lage LFS systemet.

Denne innsatsen for å isolere det nye systemet fra vertsdistribusjonen kan virke overdreven. En fullstendig teknisk forklaring på hvorfor dette gjøres er gitt i Verktøykjedens tekniske merknader.

I Kapittel 8 blir det fulle LFS system bygget. En annen fordel gitt av chroot miljøet er at det lar deg fortsette å bruke vertssystemet mens LFS bygges. Mens du venter på at pakkesammenstillinger blir fullført, kan du fortsette å bruke datamaskinen som normalt.

For å fullføre installasjonen er den grunnleggende systemkonfigurasjonen satt opp i Kapittel 9, og kjernen og oppstartslasteren blir opprettet i Kapittel 10. Kapittel 11 inneholder informasjon om å fortsette LFS opplevelsen utover denne boken. Etter at trinnene i denne boken er implementert, vil datamaskinen være klar til å starte på nytt i det nye LFS systemet.

Dette er prosessen i et nøtteskall. Detaljert informasjon om hvert trinn er diskutert i de følgende kapitlene og pakkebeskrivelsene. Punkter som kan virke kompliserte vil bli avklart, og alt vil falle på plass når du legger ut på LFS eventyret.

Her er en liste over pakkene som er oppdatert siden forrige utgivelse av LFS.

Dette er versjon 12.1-systemd av Linux From Scratch-boken, datert 1. Mars 2024. Hvis denne boken er mer enn seks måneder gammel, er en nyere og bedre versjonen sannsynligvis allerede tilgjengelig. For å finne ut, vennligst sjekk et av speilene via https://www.linuxfromscratch.org/mirrors.html.

Nedenfor er en liste over endringer som er gjort siden forrige utgivelse av boken.

Hvis det oppstår et problem eller et spørsmål mens du arbeider gjennom denne boken, vennligst sjekk siden FAQ på https://www.linuxfromscratch.org/faq/#generalfaq. Spørsmål er ofte allerede besvart der. Hvis spørsmålet ditt ikke er svart på denne siden, prøv å finne kilden til problemet. De følgende tips vil gi deg veiledning for feilsøking: https://www.linuxfromscratch.org/hints/downloads/files/errors.txt.

Hvis du ikke finner problemet oppført i FAQ, søk i E-post listene på https://www.linuxfromscratch.org/search.html.

Vi har også et fantastisk LFS fellesskap som er villig til å tilby hjelp gjennom E-postlistene og IRC (se Section 1.4, “Ressurser” delen av denne boken). Imidlertid får vi flere brukerspørsmål hver dag, og mange av dem kan være besvart gjennom FAQ og gjennom E-postlistene, søk der først. Så for at vi skal kunne tilby best mulig hjelp, må du gjøre noe forskning på egen hånd først. Det lar oss fokusere på de mere uvanlige brukerstøtte. Hvis søkene dine ikke gir en løsning, vennligst ta med all relevant informasjon (nevnt nedenfor) i din forespørsel om hjelp.

gcc -DALIASPATH=\"/mnt/lfs/usr/share/locale:.\"
-DLOCALEDIR=\"/mnt/lfs/usr/share/locale\"
-DLIBDIR=\"/mnt/lfs/usr/lib\"
-DINCLUDEDIR=\"/mnt/lfs/usr/include\" -DHAVE_CONFIG_H -I. -I.
-g -O2 -c getopt1.c
gcc -g -O2 -static -o make ar.o arscan.o commands.o dir.o
expand.o file.o function.o getopt.o implicit.o job.o main.o
misc.o read.o remake.o rule.o signame.o variable.o vpath.o
default.o remote-stub.o version.o opt1.o
-lutil job.o: In function `load_too_high':
/lfs/tmp/make-3.79.1/job.c:1565: undefined reference
to `getloadavg'
collect2: ld returned 1 exit status
make[2]: *** [make] Error 1
make[2]: Leaving directory `/lfs/tmp/make-3.79.1'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/lfs/tmp/make-3.79.1'
make: *** [all-recursive-am] Error 2

make [2]: *** [make] Error 1

I dette kapittelet, vertsverktøyene som trengs for å bygge LFS kontrolleres og om nødvendig installeres. Deretter vil en partisjon klargjøres som vert for LFS systemet. Vi lager partisjonen, lager et filsystem på den og monter den.

LFS er designet for å bygges i en økt. Det er det instruksjonene forutsetter, at systemet ikke vil bli slått av under prosessen. Det betyr ikke at byggingen av systemet må gjøres i en økt. Problemet er at visse prosedyrer må gjenopprettes etter en omstart hvis LFS gjenopptas på forskjellige punkter.

Som de fleste andre operativsystemer er LFS vanligvis installert på en dedikert partisjon. Den anbefalte tilnærmingen til å bygge et LFS system er å bruke en tilgjengelig tom partisjon eller, hvis du har nok upartisjonert plass, å lage en.

Et minimalt system krever en partisjon på rundt 10 gigabyte (GB). Dette er nok til å lagre alle kildetarballene og kompilere pakkene. Men hvis LFS systemet er ment å være det primære Linux systemet, vil tilleggsprogramvare sannsynligvis bli installert som vil kreve ekstra plass. En 30 GB partisjon er en rimelig størrelse for å sørge for nok plass. LFS systemet i seg selv vil ikke ta så mye plass. En stor del av dette kravet er å sørge for tilstrekkelig ledig midlertidig lagring samt for å legge til flere funksjoner etter at LFS er fullført. I tillegg kompilering av pakker kan kreve mye diskplass som vil bli gjenvunnet etter at pakken er installert.

Fordi det ikke alltid er nok minne (RAM) tilgjengelig for kompileringsprosesser er det en god ide å bruke en liten diskpartisjon som swap. Dette brukes av kjernen for å lagre sjelden brukte data og la mer minne være tilgjengelig for aktive prosesser. swap partisjon for et LFS system kan være det samme som det som brukes av vertssystemet, i det tilfellet er det ikke er nødvendig å opprette en annen.

Start et diskpartisjoneringsprogram som f.eks cfdisk eller fdisk med et kommandolinjealternativ som navngir harddisken som den nye partisjonen vil bli opprettet påmdash;for eksempel /dev/sda for den primære diskstasjonen. Lag en innebygd Linux partisjon og en swap partisjon, hvis nødvendig. Vennligst referere til cfdisk(8) eller fdisk(8) hvis du ennå ikke vet hvordan du bruker programmene.

Husk betegnelsen på den nye partisjonen (f.eks., sda5). Denne boken vil referere til dette som LFS partisjonen. Husk også betegnelsen på swap partisjonen. Disse navnene vil være nødvendig senere for /etc/fstab filen.

En partisjon er bare en rekke sektorer på en diskstasjon, avgrenset med grenser satt i en partisjonstabell. Før operativsystemet kan bruke en partisjon for å lagre alle filer, må partisjonen formateres til å inneholde et filsystem , vanligvis bestående av en etikett, katalogblokker, datablokker og et indekseringsskjema for å finne en bestemt fil på forespørsel. Filsystemet hjelper også OS med å holde styr på ledig plass på partisjonen, reservere nødvendige sektorer når en ny fil opprettes eller en eksisterende fil utvides, og resirkuler de ledige datasegmentene som opprettes når filer slettes. Det kan også gi støtte for dataredundans og for feilgjenoppretting.

LFS kan bruke et hvilket som helst filsystem som gjenkjennes av Linuxkjernen, men de vanligste typene er ext3 og ext4. Valget av riktig filsystem kan være kompleks; det avhenger av egenskapene til filene og størrelsen på partisjonen. For eksempel:

Andre filsystemer, inkludert FAT32, NTFS, ReiserFS, JFS og XFS er nyttig for spesialiserte formål. Mer informasjon om disse filsystemene. og mange andre finner du på https://en.wikipedia.org/wiki/Comparison_of_file_systems.

LFS antar at rotfilsystemet (/) er av typen ext4. å lage et ext4 filsystemet på LFS partisjonen, utsted fælgende kommando:

mkfs -v -t ext4 /dev/<xxx>

Erstatt <xxx> med navnet på LFS partisjonen.

Hvis du bruker en eksisterende swap partisjon, er det ikke nødvendig å formatere den. Hvis en ny swap partisjonen ble opprettet, må den initialiseres med denne kommandoen:

mkswap /dev/<yyy>

Erstatt <yyy> med navnet på swap partisjonen.

Gjennom hele denne boken, vil miljøvariabelen LFS brukes flere ganger. Du bør sørge for at denne variabelen alltid er definert gjennom hele LFS byggeprosessen. Den bør settes til navnet på mappen hvor du skal bygge LFS systemet ditt - vi vil bruke /mnt/lfs som et eksempel, men du kan velg et hvilket som helst mappenavn du ønsker. Hvis du bygger LFS på en separat partisjon, vil denne mappen være monteringspunktet for partisjonen. Velg en mappeplassering og sett variabelen med følgende kommando:

export LFS=/mnt/lfs

Å ha denne variabelen satt er fordelaktig ved at kommandoer som f.eks mkdir -v $LFS/tools kan skrives bokstavelig. Skallet vil automatisk erstatte “$LFS” med “/mnt/lfs” (eller hvilken verdi variabelen ble satt til) når den behandler kommandolinjen.

echo $LFS

Nå som et filsystem er opprettet, må partisjonen monteres slik at vertssystemet kan få tilgang til det. Denne boken forutsetter at filsystemet er montert i katalogen spesifisert av LFS miljøvariabel beskrevet i forrige avsnitt.

Strengt tatt kan man ikke “montere en partisjon”. Man monterer filsystemet innebygd i den partisjonen. Men siden en enkelt partisjon ikke kan inneholde mer enn ett filsystem, folk snakker ofte om partisjonen og tilhørende filsystem som om de var ett og samme.

Opprett monteringspunktet og monter LFS filsystemet med disse kommandoene:

mkdir -pv $LFS
mount -v -t ext4 /dev/<xxx> $LFS

Erstatt <xxx> med navnet for LFS partisjon.

Hvis du bruker flere partisjoner for LFS (f.eks. en for / og en annen for /home), monter dem som dette:

mkdir -pv $LFS
mount -v -t ext4 /dev/<xxx> $LFS
mkdir -v $LFS/home
mount -v -t ext4 /dev/<yyy> $LFS/home

Erstatt <xxx> og <yyy> med riktige partisjons navn.

Sørg for at de nye partisjonene ikke er montert med tillatelser som er for restriktiv (som f.eks nosuid eller nodev alternativer). Kjør mount kommandoen uten noen parametere for å se hvilke alternativer som er satt for den monterte LFS partisjonen. Hvis nosuid og/eller nodev er satt, må partisjonene monteres på nytt.

/dev/<xxx>  /mnt/lfs ext4   defaults      1     1

Hvis du bruker en swap partisjon, sørg for at den er aktivert, bruk swapon kommandoen:

/sbin/swapon -v /dev/<zzz>

Erstatt <zzz> med navnet på swap partisjonen.

Nå som den nye LFS partisjonen er klar til bruk, er det på tide å laste ned pakkene.

Dette kapittelet inneholder en liste over pakker som må lastes ned for å bygge et grunnleggende Linux system. De oppførte versjonsnumrene tilsvarer versjoner av programvaren som er kjent for å fungere, og denne boken er basert på deres bruk. Vi anbefaler på det sterkeste å ikke bruke forskjellige versjoner fordi konstruksjonens kommandoer for en versjon kanskje ikke fungerer med en annen versjon, med mindre annen versjon er spesifisert av en LFS errata eller sikkerhetsrådgivning. De nyeste pakkeversjonene kan også ha problemer som krever læsninger. Disse læsningene vil bli utviklet og stabilisert i utviklingsversjon av boken.

For noen pakker, utgivelsens tarball og (Git eller SVN) æyeblikksbilde fra depotets tarball for denne utgivelsen kan publiseres med lignende filnavn. En utgivelses tarball inneholder genererte filer (for eksempel, configure skript generert av autoconf), i tillegg til innholdet i tilsvarende øyeblikksbilde av depot. Boken bruker utgivelses tarballer når det er mulig. Bruke et øyeblikksbilde av depot i stedet for en utgivelses tarball spesifisert av boken vil forårsake problemer.

Nedlastingsplasseringer er kanskje ikke alltid tilgjengelige. Hvis en nedlastingsplasseringen har endret seg siden denne boken ble publisert, Google (https://www.google.com/) gir en nyttig søkemotor for de fleste pakkene. Hvis dette søket ikke lykkes, prøv en alternativ måte å laste ned på https://www.linuxfromscratch.org/lfs/mirrors.html#files.

Nedlastede pakker og oppdateringer må oppbevares et sted som er praktisk tilgjengelig gjennom hele bygget. En fungerende mappe er også nødvendig for å pakke ut kildene og bygge dem. $LFS/sources kan brukes både som et sted å oppbevare tarballene og oppdateringene og som en arbeidsmappe. Ved å bruke denne mappen vil de nødvendige elementene være plassert på LFS partisjonen og vil være tilgjengelig under alle stadier av byggeprosessen.

For å opprette denne mappen, utfør følgende kommando, som bruker root, før du starter nedlastingsøkten :

mkdir -v $LFS/sources

Gjør denne mappen skrivbar og låst (sticky). “Sticky” betyr at selv om flere brukere har skrivetillatelse på en mappe, er det bare eieren av en fil som kan slette filen i en låst mappe. Følgende kommando vil aktivere skrive og låste moduser:

chmod -v a+wt $LFS/sources

Det er flere måter å få tak i alle nødvendige pakker og oppdateringer for å bygge LFS:

For å laste ned alle pakkene og oppdateringene ved å bruke wget-list-systemd som en inngang til kommandoen wget ,bruk:

wget --input-file=wget-list-systemd --continue --directory-prefix=$LFS/sources

I tillegg, fra og med LFS 7.0, er det en egen fil, md5sums, som kan brukes til å bekrefte at alle de riktige pakkene er tilgjengelige før du fortsetter. Legg inn denne filen i $LFS/sources og kjør:

pushd $LFS/sources
  md5sum -c md5sums
popd

Denne sjekken kan brukes etter å ha hentet de nødvendige filene med en av de metodene oppført ovenfor.

Hvis pakkene og oppdateringene er lastet ned som ikke-root bruker, vil disse filene eies av brukeren. Filsystemet registrerer eier ved hjelp av UID, og UID til en vanlig bruker i vertsdistroen er ikke tildelt i LFS. Så filene vil bli eid av en ikke navngitt UID i det endelige LFS systemet. Hvis du ikke vil tilordne samme UID for brukeren din i LFS systemet, endre eierne av disse filene til root nå for å unngå dette problemet:

chown root:root $LFS/sources/*

Last ned eller på annen måte skaff deg følgende pakker:

Total størrelse på disse pakkene: ca 505 MB

I tillegg til pakkene kreves det også flere oppdateringer. Disse oppdateringene retter eventuelle feil i pakkene som skal være fikset av vedlikeholderen. Oppdateringene gjør også små modifikasjoner som gjør pakkene lettere å jobbe med. Følgende oppdateringene vil være nødvendig for å bygge et LFS system:

Total størrelse på disse oppdateringene: ca 208.5 KB

I tillegg til de ovennevnte nødvendige oppdateringene, finnes det en rekke valgfrie oppdateringer laget av LFS fellesskapet. Disse valgfrie oppdateringene løser mindre problemer eller aktiverer funksjonalitet som ikke er aktivert som standard. Les gjerne oppdateringsdatabasen som ligger på https://www.linuxfromscratch.org/patches/downloads/ og anskaffe eventuelle tilleggoppdateringer som passer dine systembehov.

I dette kapittelet vil vi utføre noen tilleggsoppgaver for å forberede byggingen av det midlertidige systemet. Vi vil lage et sett med mapper i $LFS (hvor vi vil installere midlertidige verktøy, legg til en uprivilegert brukerå bli forklare tidsenhetene (“SBU”) som vi bruker til å måle hvor lang tid det tar å bygge LFS pakker, og gi litt informasjon om testpakkene til pakkene.

I denne delen begynner vi å fylle LFS filsystemet med deler som vil utgjøre det endelige Linuxsystemet. Det første trinnet er å opprette et begrenset kataloghierarki, slik at programmene som kompileres i Kapittel 6 (i tillegg til glibc og libstdc++ i Kapittel 5) kan installeres i deres endelige plassering. Vi gjør dette slik at de midlertidige programmene vil bli overskrevet når de endelige versjonene bygges i Kapittel 8.

Create the required directory layout by issuing the following commands as root:

mkdir -pv $LFS/{etc,var} $LFS/usr/{bin,lib,sbin}

for i in bin lib sbin; do
  ln -sv usr/$i $LFS/$i
done

case $(uname -m) in
  x86_64) mkdir -pv $LFS/lib64 ;;
esac

Programmer i Kapittel 6 vil bli kompilert med en krysskompilator (mer detaljer kan bli funnet i avsnitt Verktøykjedens tekniske merknader). Denne krysskompilatoren vil bli installert i en spesiell katalog for å skille den fra de andre programmene. Fortsatt som root, lag den mappen med denne kommandoen:

mkdir -pv $LFS/tools

Når du er logget inn som bruker root, kan det å gjøre en enkelt feil skade eller ødelegge et system. Derfor, pakkene i de neste to kapitlene er bygget som en uprivilegert bruker. Du kan bruke ditt eget brukernavn, men for å gjøre det enklere å sette opp et rent arbeidsmiljø, opprett en ny bruker kalt lfs som medlem av en ny gruppe (også kalt lfs) og kjøre kommandoer som lfs under installasjonsprosessen. Som root, utflr fllgende kommandoer for å legge til den nye brukeren:

groupadd lfs
useradd -s /bin/bash -g lfs -m -k /dev/null lfs

Hvis du vil logge inn som lfs eller bytte til lfs fra en ikke-root bruker (i motsetning til å bytte til bruker lfs når du er logget inn som root, som ikke krever at lfs brukeren har et passord), må du angi et passord for lfs. Utsted følgende kommando som root bruker for å angi passordet:

passwd lfs

Bevilg lfs full tilgang til alle mapper under $LFS ved å gjøre lfs eieren:

chown -v lfs $LFS/{usr{,/*},lib,var,etc,bin,sbin,tools}
case $(uname -m) in
  x86_64) chown -v lfs $LFS/lib64 ;;
esac

Deretter starter du et skall som kjører som bruker lfs. Dette kan gjøres ved å logge inn som lfs på en virtuell konsoll, eller med følgende bytt ut/bytt brukerkommando:

su - lfs

“-” instruerer su å starte et påloggingsskall i motsetning til et ikke-påloggingsskall. Forskjellen mellom disse to skjelltypene finner du i detalj i bash(1) og info bash.

Sett opp et godt arbeidsmiljø ved å lage to nye oppstartsfiler for bash skallet. Mens du er logget inn som bruker lfs, utsted følgende kommando for å lage en ny .bash_profile:

cat > ~/.bash_profile << "EOF"
exec env -i HOME=$HOME TERM=$TERM PS1='\u:\w\$ ' /bin/bash
EOF

Når du er pålogget som bruker lfs, eller når du bytter til lfs bruker med en su kommando med “-” alternativet, det første skallet er et login skall som leser /etc/profile til verten (som sannsynligvis inneholder noen innstillinger og miljøvariabler) og deretter .bash_profile. exec env -i.../bin/bash kommandoen i .bash_profile filen erstatter det kjørende skallet med et nytt et med et helt tomt miljø bortsett fra HOME, TERM, og PS1 variabler. Dette sikrer at ingen uønskede og potensielt farlige miljøvariabler fra vertssystemet lekker inn i byggemiljøet.

Den nye instansen av skallet er et non-login skall, som ikke leser, og utfører, innholdet i /etc/profile eller .bash_profile filer, men heller leser og kjører .bashrc filen istedet. Opprett .bashrc filen nå

cat > ~/.bashrc << "EOF"
set +h
umask 022
LFS=/mnt/lfs
LC_ALL=POSIX
LFS_TGT=$(uname -m)-lfs-linux-gnu
PATH=/usr/bin
if [ ! -L /bin ]; then PATH=/bin:$PATH; fi
PATH=$LFS/tools/bin:$PATH
CONFIG_SITE=$LFS/usr/share/config.site
export LFS LC_ALL LFS_TGT PATH CONFIG_SITE
EOF

[ ! -e /etc/bash.bashrc ] || mv -v /etc/bash.bashrc /etc/bash.bashrc.NOUSE

For mange moderne systemer med flere prosessorer (eller kjerner) kan kompileringstiden for en pakke reduseres ved å utføre en "parallell make" ved å fortelle make programmet hvor mange prosessorer som er tilgjengelige via et kommandolinjealternativ eller en miljøvariabel. For eksempel en Intel Core i9-13900K-prosessor har 8 P (ytelse) kjerner og 16 E (effektivitet) kjerner, og en P-kjerne kan kjøre to tråder samtidig så hver P-kjerne er modellert som to logiske kjerner av Linuxkjernen. Som et resultat er det totalt 32 logiske kjerner. En åpenbar måte å bruke alle disse logiske kjernene er å tillate make å gjøre opptil 32 byggejobber. Dette kan gjøres ved å sende -j32 alternativet til make:

make -j32

Eller angi MAKEFLAGS miljøvariabel og dens innhold vil automatisk bli brukt av make som kommandolinjealternativer:

export MAKEFLAGS=-j32

For å bruke alle logiske kjerner som er tilgjengelige for å bygge pakker i Kapittel 5 og Kapittel 6, sett MAKEFLAGS nå i .bashrc:

cat >> ~/.bashrc << "EOF"
export MAKEFLAGS=-j$(nproc)
EOF

Erstatt $(nproc) med antallet logiske kjerner du vil bruke hvis du ikke vil bruke alle de logiske kjernene.

Til slutt, å ha miljøet fullt forberedt for å bygge midlertidige verktøy, tving bash skallet å lese den nye brukerprofilen:

source ~/.bash_profile

Mange vil gjerne vite på forhånd hvor lenge det tar å kompilere og installere hver pakke. Fordi Linux Fra Scratch kan bygges på mange forskjellige systemer, er det umulig å gi nøyaktige tidsanslag. Den største pakken (Glibc) vil ta omtrent 5 minutter på de raskeste systemene, men kan ta flere dager på tregere systemer! I stedet for å oppgi faktiske tider, vil Standard byggenhet (SBU) brukes i stedet.

SBU fungerer som følgende. Den første pakken som skal kompileres fra denne boken er binutils i Kapittel 5. Tiden det tar å kompilere med en kjerne er det vi vil referere til som standard byggenhet eller SBU. Alle andre kompileringstider vil bli uttrykt i forhold til denne tidsenheten.

Tenk for eksempel på en pakke hvis kompileringstid er 4,5 SBU. Dette betyr at hvis et system tok 10 minutter å kompilere og installer det første passet med binutils, vil det ta omtrent 45 minutter å bygge denne eksempelpakken. Heldigvis er de fleste byggetidene kortere enn en SBU.

Generelt er ikke SBU helt nøyaktige fordi de er avhengige av mange faktorer, inkludert vertssystemets versjon av GCC. De er gitt her for å gi et estimat på hvor lang tid det kan ta å installere en pakke, men tall kan variere med så mye som dusinvis av minutter i noen tilfeller.

De fleste pakkene gir en testpakke. å kjøre testpakken for en nybygd pakke er en god ide fordi den kan gi en “tilregnelighetssjekk ” som indikerer at alt er kompilert riktig. En testpakke som består kontrollene sine, beviser vanligvis at pakken fungerer slik utvikleren har tenkt. Det gir imidlertid ingen garanti at pakken er helt feilfri.

Noen testpakker er viktigere enn andre. For eksempel, testpakkene for kjerneverktøykjedepakkene—GCC, binutils, og glibc—er av største betydning på grunn av deres sentrale rolle i et riktig fungerende system. Testpakkene for GCC og glibc kan ta veldig lang tid å fullføre, spesielt på tregere maskinvare, men anbefales på det sterkeste.

Et vanlig problem med å kjøre testpakkene for binutils og GCC er å gå tom for pseudoterminaler (PTY). Dette kan resultere i et høyt antall feilende prøver. Dette kan skje av flere grunner, men den mest sannsynlig årsaken er at vertssystemet ikke har devpts filsystemet satt opp riktig. Dette spørsmålet diskuteres mer detaljert på https://www.linuxfromscratch.org/lfs/faq.html#no-ptys.

Noen ganger vil testpakker til en pakke mislykkes, men av årsaker som utviklere er klar over og har ansett som ikke kritiske. Se loggene som finnes på https://www.linuxfromscratch.org/lfs/build-logs/12.1/ for å bekrefte om disse feilene er forventet eller ikke. Denne siden er gyldig for alle tester i denne boken.

Dette kapittelet viser hvordan du bygger en krysskompilator og dens tilhørende verktøy. Selv om krysskompilering her er forfalsket, er prinsippene det det samme som for en ekte kryssverktøykjede.

Programmene som er kompilert i dette kapittelet vil bli installert under $LFS/tools mappe for å beholde dem atskilt fra filene som er installert i de følgende kapitlene. Bibliotekene, på den annen side, er installert på sin endelige plass, siden de er knyttet til systemet vi ønsker å bygge.

Dette kapittelet viser hvordan du krysskompilerer grunnleggende verktøy ved å bruke den nettopp bygde kryssverktøykjeden. Disse verktøyene er installert i deres endelige plassering, men kan ikke brukes ennå Grunnleggende oppgaver er fortsatt avhengige av vertens verktøy. Likevel brukes de installerte bibliotekene ved koblinger.

Bruk av verktøyene vil være mulig i neste kapittel etter å ha gått inn i “chroot” miljøet. Men alle pakkene som bygges i nåværende kapittel må bygges før vi gjør det. Derfor kan vi ikke være uavhengig av vertssystemet ennå.

Nok en gang, la oss huske den feilaktige innstillingen av LFS sammen med å bygge som root, kan gjøre datamaskinen din ubrukelig. Hele dette kapittelet må gjøres som bruker lfs, med miljøet som beskrevet i Section 4.4, “Sette opp miljøet”.

Dette kapittelet viser hvordan du bygger de siste manglende delene av det midlertidige systemet: verktøyene som trengs for å bygge maskineriet av forskjellige pakker. Nå som alle sirkulære avhengigheter er løst, et “chroot” miljø fullstendig isolert fra vertsoperativsystemet (bortsett fra den kjørende kjernen), kan brukes til byggingen.

For riktig drift av det isolerte miljøet, noe kommunikasjon med den kjørende kjernen må være etablert. Dette gjøres gjennom de såkalte Virtuelle kjernefilsystemer (Virtual Kernel File Systems), som må være montert når du går inn i chroot miljøet. Det kan være lurt å sjekke at de er montert ved å kjøre findmnt kommandoen.

Inntil Section 7.4, “Gå inn i Chroot miljøet”, må kommandoene kjøres som root, med LFS variabelen satt. Etter å ha gått inn i inn chroot, alle kommandoer kjøres som root, heldigvis uten tilgang til operativsystemet til datamaskinen du bygde LFS på. Vær forsiktig uansett, da det er lett å ødelegge hele LFS system med dårlige kommandoer.

For øyeblikket er hele mappehierarkiet i $LFS eid av brukeren lfs, en bruker som bare eksisterer på vertssystemet. Hvis mappene og filene under $LFS blir holdt som de er, vil de være eid av en bruker-ID uten en tilsvarende konto. Dette er farlig pga en brukerkonto opprettet senere kan få samme bruker-ID og eie alle filene under $LFS, dermed eksponere disse filene til mulig ondsinnet manipulasjon.

For å løse dette problemet, endre eierskap til $LFS/* mapper til bruker root ved å kjøre følgende kommando:

chown -R root:root $LFS/{usr,lib,var,etc,bin,sbin,tools}
case $(uname -m) in
  x86_64) chown -R root:root $LFS/lib64 ;;
esac

Applikasjoner som kjører i brukerområdet bruker forskjellige filsystemer opprettet av kjernen for å kommunisere med selve kjernen. Disse filsystemene er virtuelle: ingen diskplass brukes til dem. Innholdet i disse filsystemene ligger i minnet. Disse filsystemene må monteres i $LFS katalogtreet slik at applikasjonene kan finne dem i chroot miljøet.

Begynn med å lage mappene som disse virtuelle filsystemene vil være montert på:

mkdir -pv $LFS/{dev,proc,sys,run}

mount -v --bind /dev $LFS/dev

mount -vt devpts devpts -o gid=5,mode=0620 $LFS/dev/pts
mount -vt proc proc $LFS/proc
mount -vt sysfs sysfs $LFS/sys
mount -vt tmpfs tmpfs $LFS/run

if [ -h $LFS/dev/shm ]; then
  install -v -d -m 1777 $LFS$(realpath /dev/shm)
else
  mount -vt tmpfs -o nosuid,nodev tmpfs $LFS/dev/shm
fi

Nå som alle pakkene som kreves for å bygge resten av nødvendige verktøy er på systemet, er det på tide å gå inn i chroot miljøet for å fullføre installasjonen av de gjenværende midlertidige verktøyene. Dette miljøet vil også brukes for å installere det endelige systemet. Som bruker root, kjør følgende kommando for å gå inn i miljøet som for øyeblikket er befolket med bare midlertidige verktøy:

chroot "$LFS" /usr/bin/env -i   \
    HOME=/root                  \
    TERM="$TERM"                \
    PS1='(lfs chroot) \u:\w\$ ' \
    PATH=/usr/bin:/usr/sbin     \
        MAKEFLAGS="-j$(nproc)"      \
    TESTSUITEFLAGS="-j$(nproc)" \
    /bin/bash --login

Hvis du ikke vil bruke alle tilgjengelige logiske kjerner, bytt ut $(nproc) med antall logiske kjerner du ønsker å bruke til å bygge pakker i dette kapittelet og de følgende kapitler. Testpakkene til noen pakker (spesielt Autoconf, Libtool, og Tar) i Kapittel 8 er ikke berørt av MAKEFLAGS, de bruker en TESTSUITEFLAGS miljøvariabel i stedet. Vi setter det her også for å kjøre disse testpakkene med flere kjerner.

-i alternativet gitt til env kommandoen vil slette alle variabler i chroot miljøet. Etter det, bare HOME, TERM, PS1, og PATH variablene settes på nytt. TERM=$TERM konstruksjonen setter TERM variabelen inne i chroot til samme verdi som utenfor chroot. Denne variabelen er nødvendig for at programmer som vim og less kan fungere skikkelig. Hvis andre variabler ønskes, som f.eks CFLAGS eller CXXFLAGS, er dette et bra sted å sette dem.

Fra dette tidspunktet er det ikke nødvendig å bruke LFS variabelen lenger fordi alt arbeid vil være begrenset til LFS filsystemet. chroot kommandoen kjører Bash skallet med rot (/) mappen satt til $LFS.

Merk at /tools/bin ikke er i PATH. Dette betyr at kryssverktøykjeden ikke lenger vil bli brukt.

Merk at bash ledeteksten vil si I have no name! Dette er normalt fordi /etc/passwd filen ikke er opprettet ennå

Det er på tide å lage hele strukturen i LFS filsystemet.

Lag noen mapper på rotnivå som ikke er i det begrensede settet som kreves i de foregående kapitlene ved å gi følgende kommando:

mkdir -pv /{boot,home,mnt,opt,srv}

Lag det nødvendige settet med undermapper under rotnivået ved å utstede følgende kommandoer:

mkdir -pv /etc/{opt,sysconfig}
mkdir -pv /lib/firmware
mkdir -pv /media/{floppy,cdrom}
mkdir -pv /usr/{,local/}{include,src}
mkdir -pv /usr/local/{bin,lib,sbin}
mkdir -pv /usr/{,local/}share/{color,dict,doc,info,locale,man}
mkdir -pv /usr/{,local/}share/{misc,terminfo,zoneinfo}
mkdir -pv /usr/{,local/}share/man/man{1..8}
mkdir -pv /var/{cache,local,log,mail,opt,spool}
mkdir -pv /var/lib/{color,misc,locate}

ln -sfv /run /var/run
ln -sfv /run/lock /var/lock

install -dv -m 0750 /root
install -dv -m 1777 /tmp /var/tmp

Mapper er som standard opprettet med tillatelsesmodus 755, men dette er ikke ønskelig for alle mapper. I kommandoene ovenfor, to endringer gjøres—en til hjemmemappen for brukeren root, og en annen til mappene for midlertidige filer.

Den første modusendringen sikrer at ikke hvem som helst kan komme inn i /root mappen—det samme som en vanlig bruker ville gjort med sin hjemmemappe. De andre modusendring sørger for at enhver bruker kan skrive til /tmp og /var/tmp mappene, men kan ikke fjerne en annen brukers filer fra dem. Sistnevnte er forbudt av den såkalte “låst bit (sticky bit)” den høyeste biten (1) i 1777 bitmasken.

Historisk sett har Linux en liste over de monterte filsystemene i filen /etc/mtab. Moderne kjerner opprettholder denne listen internt og eksponerer det for brukeren via /proc filsystemet. For å tilfredsstille verktøy som forventer å finne /etc/mtab, opprett følgende symbolske lenke:

ln -sv /proc/self/mounts /etc/mtab

Lag en grunnleggende /etc/hosts fil som blir referert til i noen testsuiter, og også i en av Perls konfigurasjonsfiler :

cat > /etc/hosts << EOF
127.0.0.1  localhost $(hostname)
::1        localhost
EOF

For at bruker root skal kunne logge inn og for navnet “root” å bli gjenkjent, det må være relevante oppføringer i /etc/passwd og /etc/group filene.

Opprett /etc/passwd filen ved å kjøre følgende kommando:

cat > /etc/passwd << "EOF"
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/dev/null:/usr/bin/false
daemon:x:6:6:Daemon User:/dev/null:/usr/bin/false
messagebus:x:18:18:D-Bus Message Daemon User:/run/dbus:/usr/bin/false
systemd-journal-gateway:x:73:73:systemd Journal Gateway:/:/usr/bin/false
systemd-journal-remote:x:74:74:systemd Journal Remote:/:/usr/bin/false
systemd-journal-upload:x:75:75:systemd Journal Upload:/:/usr/bin/false
systemd-network:x:76:76:systemd Network Management:/:/usr/bin/false
systemd-resolve:x:77:77:systemd Resolver:/:/usr/bin/false
systemd-timesync:x:78:78:systemd Time Synchronization:/:/usr/bin/false
systemd-coredump:x:79:79:systemd Core Dumper:/:/usr/bin/false
uuidd:x:80:80:UUID Generation Daemon User:/dev/null:/usr/bin/false
systemd-oom:x:81:81:systemd Out Of Memory Daemon:/:/usr/bin/false
nobody:x:65534:65534:Unprivileged User:/dev/null:/usr/bin/false
EOF

Selve passordet for root settes senere.

Opprett /etc/group filen ved å kjøre følgende kommando:

cat > /etc/group << "EOF"
root:x:0:
bin:x:1:daemon
sys:x:2:
kmem:x:3:
tape:x:4:
tty:x:5:
daemon:x:6:
floppy:x:7:
disk:x:8:
lp:x:9:
dialout:x:10:
audio:x:11:
video:x:12:
utmp:x:13:
cdrom:x:15:
adm:x:16:
messagebus:x:18:
systemd-journal:x:23:
input:x:24:
mail:x:34:
kvm:x:61:
systemd-journal-gateway:x:73:
systemd-journal-remote:x:74:
systemd-journal-upload:x:75:
systemd-network:x:76:
systemd-resolve:x:77:
systemd-timesync:x:78:
systemd-coredump:x:79:
uuidd:x:80:
systemd-oom:x:81:
wheel:x:97:
users:x:999:
nogroup:x:65534:
EOF

De opprettede gruppene er ikke en del av noen standard—de er grupper delvis bestemt av kravene til Udev konfigurasjonen i kapittel 9, og delvis etter felles konvensjon brukt av en rekke eksisterende Linux distribusjoner. I tillegg er noen testsuiter avhengige av spesifikke brukere eller grupper. Linux Standard Base (LSB, tilgjengelig på https://refspecs.linuxfoundation.org/lsb.shtml) anbefaler bare at, foruten gruppen root med en Gruppe ID (GID) på 0, en gruppe bin med en GID på 1 å være tilstede. GID på 5 er mye brukt for tty gruppen, og tallet 5 er også brukt i systemd for devpts filsystemet. Alle andre gruppenavn og GID-er kan velges fritt av systemets administrator siden velskrevne programmer ikke er avhengige av GID-nummer, men bruk heller gruppens navn.

ID 65534 brukes av kjernen for NFS og separat brukernavneområder for ikke-tilordnede brukere (de finnes på NFS serveren eller den overordnede brukernavneområde, men “finnes ikke” på den lokale maskinen eller i det separate navnerommet). Vi tildeler nobody og nogroup for å unngå en ikke navngitt ID. Men andre distroer kan behandle denne IDen annerledes, så alle flyttbare programmer bør ikke være avhengig av denne tildelingen.

Noen tester i Kapittel 8 trenger en vanlig bruker. Vi legger til denne brukeren her og sletter denne kontoen på slutten av det kapittelet.

echo "tester:x:101:101::/home/tester:/bin/bash" >> /etc/passwd
echo "tester:x:101:" >> /etc/group
install -o tester -d /home/tester

For å fjerne “I have no name!” ledetekst, start et nytt skall. Siden /etc/passwd og /etc/group filer har blitt opprettet, vil brukernavn og gruppenavnoppløsning nå virke:

exec /usr/bin/bash --login

login, agetty, og init programmene (og andre) bruker en rekke loggfiler for å registrere informasjon som hvem som var logget inn på systemet og når. Disse programmene vil imidlertid ikke skrive til loggfilene hvis de ikke allerede eksisterer. Initialiser loggfilene og gi dem riktige tillatelser:

touch /var/log/{btmp,lastlog,faillog,wtmp}
chgrp -v utmp /var/log/lastlog
chmod -v 664  /var/log/lastlog
chmod -v 600  /var/log/btmp

/var/log/wtmp filen registrerer alle pålogginger og utlogginger. /var/log/lastlog filen registrerer når hver bruker sist logget på /var/log/faillog filen registrerer mislykkede påloggingsforsøk. /var/log/btmp filen registrerer de dårlige påloggingsforsøkene.

I dette kapittelet begynner vi for alvor å bygge LFS systemet.

Installasjonen av denne programvaren er enkel. Skjønt i mange tilfeller kan installasjonsinstruksjonene gjøres kortere og mer generelle, vi har valgt å gi de fullstendige instruksjonene for hver pakke for å minimere mulighetene for feil. Nøkkelen til å lære hva som gjør at et Linux system virker er å vite hva hver pakke brukes til og hvorfor du (eller systemet) kan trenge det.

Vi anbefaler ikke å bruke optimaliseringer. De kan gjøre at et program kjører litt raskere, men de kan også forårsake kompileringsvanskeligheter og problemer når du kjører programmet. Hvis en pakke nekter å kompilere når du bruker optimalisering, prøv å kompilere den uten optimalisering og se om det løser problemet. Selv om pakken kompileres ved bruk av optimalisering, er det risiko for at det kan ha blitt kompilert feil fordi det er komplekse interaksjoner mellom koden og byggeverktøyene. Legg også merke til at -march og -mtune alternativene som ikke er spesifisert i boken er ikke testet. Dette kan skape problemer med verktøykjedepakkene (Binutils, GCC og Glibc). De små potensielle gevinstene oppnådd ved bruk av kompilatoroptimaliseringer oppveies ofte av risikoen. Førstegangsbyggere av LFS oppfordres til å bygge uten tilpassete optimaliseringer.

På den annen side holder vi optimaliseringene aktivert som standard konfigurasjon av pakkene. I tillegg aktiverer vi noen ganger eksplisitt en optimalisert konfigurasjon levert av en pakke, men ikke aktivert som standard. Pakkevedlikeholderne har allerede testet disse konfigurasjonene og anser dem som trygge, så det er ikke sannsynlig at de vil bryte byggingen. Vanligvis aktiverer standardkonfigurasjonen allerede -O2 eller -O3, så det resulterende systemet vil fortsatt kjøre veldig raskt uten noen tilpasset optimalisering, og være stabil samtidig.

Før installasjonsinstruksjonene gir hver installasjonsside informasjon om pakken, inkludert en kortfattet beskrivelse av hva den inneholder, omtrent hvor lang tid det vil ta å bygge, og hvor mye diskplass som kreves under denne byggeprosessen. Etter installasjonsinstruksene , er det en liste over programmer og biblioteker (sammen med korte beskrivelser) som pakken installerer.

Pakkebehandling er et ofte etterspurt tillegg til LFS-boken. En pakkebehandler lar deg spore installasjonen av filer som gjør det enkelt å fjerne og oppgradere pakker. En god pakkebehandler vil også håndtere konfigurasjonsfiler spesielt for å beholde brukerkonfigurasjonen når pakken installeres på nytt eller oppgraderes. Før du begynner å lure, NEI—denne delen vil ikke snakke om eller anbefale noen spesiell pakkebehandler. Det den gir er en oppsummering av de fleste populære teknikker og hvordan de fungerer. Den perfekte pakkebehandleren for deg vil kanskje være blant disse teknikkene eller kan være en kombinasjon av to eller flere av disse teknikker. Denne delen nevner kort problemer som kan oppstå ved oppgradering av pakker.

Noen grunner til at ingen pakkebehandler er nevnt i LFS eller BLFS inkludere:

Det er skrevet noen tips om emnet pakkehåndtering. Besøk Hints Project og se om en av dem passer ditt behov.

./configure --prefix=/usr/pkg/libfoo/1.1
make
make install

./configure --prefix=/usr
make
make DESTDIR=/usr/pkg/libfoo/1.1 install