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

Som et alternativ til å installere en separat distribusjon på din maskinen, du kanskje ønsker å 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 det 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 krysskompilerings teknikker 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 i et "chroot" miljø og bruker de tidligere bygde verktøyene til å bygge tilleggsverktøyene som trengs for å bygge og teste det endelige systemet.

Denne innsatsen for å isolere det nye systemet fra vertsdistribusjonen kan virke overdreven. En fullstendig teknisk forklaring på hvorfor dette gjøres er gitt inn Toolchain Technical Notes.

I Chapter 8, Det fulle LFS system blir 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 er satt opp 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.

I denne versjonen av LFS har det skjedd en større omorganisering av boken ved å bruke teknikker som unngår å endre vertssystemet og gir en mer rett frem byggeprosess.

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

Dette er versjon 11.1 av Linux From Scratch-boken, datert 1. Mars 2022. Hvis denne boken er mer enn seks måneder gammel, en nyere og bedre versjonen er 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 vanlige spørsmål, 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 selv, lager et filsystem på den og monter den.

Vertssystemet ditt bør ha følgende programvare med minimumsversjoner angitt. Dette burde ikke være et problem for de fleste moderne Linux-distribusjoner. Vær også oppmerksom på at mange distribusjoner vil plassere programvaredeklarasjoner i separate pakker, ofte i form av “<package-name>-devel” eller “<package-name>-dev”. Pass på å installere disse hvis distribusjonen din gir dem.

Tidligere versjoner av de oppførte programvarepakkene kan fungere, men har ikke blitt testet.

For å se om vertssystemet ditt har alle de riktige versjonene, og muligheten til å kompilere programmer, kjør følgende:

cat > version-check.sh << "EOF"
#!/bin/bash
# Simple script to list version numbers of critical development tools
export LC_ALL=C
bash --version | head -n1 | cut -d" " -f2-4
MYSH=$(readlink -f /bin/sh)
echo "/bin/sh -> $MYSH"
echo $MYSH | grep -q bash || echo "ERROR: /bin/sh does not point to bash"
unset MYSH

echo -n "Binutils: "; ld --version | head -n1 | cut -d" " -f3-
bison --version | head -n1

if [ -h /usr/bin/yacc ]; then
  echo "/usr/bin/yacc -> `readlink -f /usr/bin/yacc`";
elif [ -x /usr/bin/yacc ]; then
  echo yacc is `/usr/bin/yacc --version | head -n1`
else
  echo "yacc not found"
fi

echo -n "Coreutils: "; chown --version | head -n1 | cut -d")" -f2
diff --version | head -n1
find --version | head -n1
gawk --version | head -n1

if [ -h /usr/bin/awk ]; then
  echo "/usr/bin/awk -> `readlink -f /usr/bin/awk`";
elif [ -x /usr/bin/awk ]; then
  echo awk is `/usr/bin/awk --version | head -n1`
else
  echo "awk not found"
fi

gcc --version | head -n1
g++ --version | head -n1
grep --version | head -n1
gzip --version | head -n1
cat /proc/version
m4 --version | head -n1
make --version | head -n1
patch --version | head -n1
echo Perl `perl -V:version`
python3 --version
sed --version | head -n1
tar --version | head -n1
makeinfo --version | head -n1  # texinfo version
xz --version | head -n1

echo 'int main(){}' > dummy.c && g++ -o dummy dummy.c
if [ -x dummy ]
  then echo "g++ compilation OK";
  else echo "g++ compilation failed"; fi
rm -f dummy.c dummy
EOF

bash version-check.sh

LFS er designet for å bygges i én økt. Det er det instruksjonene forutsetter, at systemet ikke vil bli slått av under prosessen. Det betyr ikke at 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 idé å bruke en liten diskpartisjon som swap plass. 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å—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 vet 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.

Nå som en tom partisjon er satt opp, kan filsystemet bli opprettet. LFS kan bruke et hvilket som helst filsystem som gjenkjennes av Linux kjernen, men de vanligste typene er ext3 og ext4. Valget av filsystem kan være kompleks og 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 finner du på http://en.wikipedia.org/wiki/Comparison_of_file_systems.

LFS antar at rotfilsystemet (/) er av typen ext4. Å lage et ext4 filsystemet på LFS partisjonen, kjør følgende:

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, miljøvariabelen LFS vil brukes flere ganger. Du bør sørge for at denne variabelen alltid er definert gjennom hele LFS byggeprosessen. Det bør settes til navnet på mappen hvor du skal bygge LFS systemet ditt - vi vil bruke /mnt/lfs som et eksempel, men mappevalg er opp til deg. 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 dette variabelsettet er fordelaktig ved at kommandoer som f.eks mkdir -v $LFS/tools kan skrives bokstavelig. Skallet vil automatisk erstatte “$LFS” med “/mnt/lfs” (eller hva variabelen ble satt til) når den behandler kommandolinjen.

echo $LFS

Nå som et filsystem er opprettet, må partisjonen gjøres tilgjengelig. For å gjøre dette, må partisjonen være montert på et valgt monteringspunkt. For formålet med denne boken er det antatt at filsystemet er montert under mappen spesifisert av LFS miljøvariabel som beskrevet i forrige avsnitt.

Opprett monteringspunktet og monter LFS filsystemet ved å kjøre:

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

Erstatt <xxx> med betegnelsen for LFS partisjon.

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

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, partisjonene må 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 det er etablert et sted å jobbe, 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 én 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 nedlastings plasseringen har endret seg siden denne boken ble publisert, Google (http://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 arbeids mappe. 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 nedlastingens økten:

mkdir -v $LFS/sources

Gjør denne mappen skrivbar og låst (sticky). “Låst” 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 å bygge LFS:

For å laste ned alle pakkene og oppdateringene ved å bruke wget-liste som inndata til wget kommanden, bruk:

wget --input-file=wget-list --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.

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

Total størrelse på disse pakkene: ca 446 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 196.1 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 anskaff eventuelle tilleggs oppdateringer 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 for installasjon av midlertidige verktøy, legg til en uprivilegert bruker for å redusere risikoen, og skape et passende byggemiljø for den brukeren. Det vil også bli forklart tidsenheten vi bruker for å måle hvor lang tid LFS pakker tar å bygge, som er “SBU”, og gi litt informasjon om pakkenes testpakker.

Den første oppgaven som utføres i LFS partisjonen er å lage et begrenset mappehierarki slik at programmer kompilert i Kapittel 6 (i tillegg til glibc og libstdc++ i Kapittel 5) kan installeres i deres endelige plassering. Dette er nødvendig for at de midlertidige programmene skal overskrives når du bygger dem igjen i Chapter 8.

Opprett det nødvendige mappeoppsettet ved å kjøre følgende som 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 i avsnitt Toolchain Technical Notes). For å skille denne krysskompilatoren fra de andre programmene, vil den bli installert i en spesiell mappe. Opprett denne mappen med:

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 en ren arbeidsmiljø, opprett en ny bruker kalt lfs som medlem av en ny gruppe (også kalt lfs) og bruk denne brukeren under installasjonsprosessen. Som root, utfør følgende kommandoer for å legge til den nye brukeren:

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

For å logge inn som lfs (i motsetning til å bytte til bruker lfs når logget i som root, som ikke krever at lfs bruker å ha et passord), gi lfs et passord:

passwd lfs

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

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

Hvis en egen arbeidsmappe ble opprettet som foreslått, gi bruker lfs eierskap til denne mappen:

chown -v lfs $LFS/sources

Deretter logger du på som bruker lfs. Dette kan gjøres via en virtuell konsoll, gjennom en skjermbehandler eller med følgende erstatt/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 å 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 logget på som bruker lfs, det første skallet er vanligvis et login skall som leser filen /etc/profile fra 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 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. Teknikken som brukes her oppnår målet om å sikre et rent miljø.

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

Til slutt, å ha miljøet fullt forberedt for å bygge midlertidige verktøy, hente den nettopp opprettede 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 20 minutter på de raskeste systemene, men kan ta opptil tre 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. Den tiden det tar å kompilere denne pakken er det som vil bli referert til som Standard byggenhet eller SBU. Alle andre kompileringstider vil bli uttrykt relative til denne tiden.

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 den for binutils.

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.

export MAKEFLAGS='-j4'

make -j4

De fleste pakkene gir en testpakke. Å kjøre testpakken for en nybygd pakke er en god idé fordi den kan gi en “tilregnelighets sjekk” som indikerer at alt er kompilert riktig. En testpakke som består sitt sett med kontroller, 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 pakkers testpakker 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/11.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 det 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.

Før Section 7.4, “Gå inn i Chroot miljøet”, kommandoene må kjøres som root, med LFS variabelsett. 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årlig utformede 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

Ulike filsystemer eksportert av kjernen brukes til å kommunisere til og fra selve kjernen. Disse filsystemene er virtuelle ved at ingen disk plass brukes til dem. Innholdet i filsystemene ligger i minnet.

Begynn med å lage mapper som filsystemene vil bli montert på:

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

mknod -m 600 $LFS/dev/console c 5 1
mknod -m 666 $LFS/dev/null c 1 3

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

mount -v --bind /dev/pts $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
  mkdir -pv $LFS/$(readlink $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     \
    /bin/bash --login

-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 vil sette TERM variabelen inne i chroot til samme verdi som utenfor chroot. Denne variabelen er nødvendig for programmer som vim og less å fungere skikkelig. Hvis andre variabler ønskes, som f.eks CFLAGS eller CXXFLAGS, dette er et bra sted å sette dem igjen.

Fra dette tidspunktet er det ikke nødvendig å bruke LFS variabelen lenger fordi alt arbeid vil være begrenset til LFS filsystemet. Dette er fordi Bash skallet blir fortalt at for $LFS er roten nå (/) mappen.

Legg merke til at /tools/bin ikke er i PATH. Dette betyr at kryssverktøykjeden ikke lenger vil være det som brukes i chroot miljøet.

Merk at ledeteksten til bash 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 root brukerens hjemmemappe, og en annen til mappene for midlertidige filer.

Den første modusendringen sikrer at ikke hvem som helst kan komme inn /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 mapper, men kan ikke fjernes 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 tilstedeværelse av /etc/mtab, opprett følgende symbolske lenke:

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

Lag en grunnleggende /etc/hosts fil som blr 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
uuidd:x:80:80:UUID Generation Daemon User:/dev/null:/usr/bin/false
nobody:x:99:99:Unprivileged User:/dev/null:/usr/bin/false
EOF

Selve passordet for root velges 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:
usb:x:14:
cdrom:x:15:
adm:x:16:
messagebus:x:18:
input:x:24:
mail:x:34:
kvm:x:61:
uuidd:x:80:
wheel:x:97:
nogroup:x:99:
users:x:999:
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å http://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. Alle andre gruppenavn og GID-er kan velges fritt av systemadministratoren siden velskrevne programmer ikke er avhengige av GID-nummer, men bruk heller gruppens navn.

Noen tester i Chapter 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 logg filer 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 logger ut. /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 et 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 kompilerings vanskeligheter 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 de komplekse interaksjonene 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. Det påfølgende systemet vil fortsatt kjøre veldig raskt og være stabilt 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 kreves under denne byggeprosessen. Etter installasjoneninstruksene , 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. I tillegg til binær- og biblioteksfilene, en pakkebehandler vil håndtere installasjonen av konfigurasjonsfiler. Før du begynner å lure på, 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