Handbook:Parts/Installation/Base/hu

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:Parts/Installation/Base and the translation is 76% complete.


Warning
Az olvasóknak nem szabad megpróbálniuk közvetlenül a Handbook:Parts névtérből követni az utasításokat (ami EZ az oldal!). Az alábbiakban bemutatott szakaszok csupán információs csontvázdarabkák formájában vannak áthivatkozva (transzklúzió). Tehát ezek a oldalak mint ez is, csak darabkák formájában vannak belehivatkozva a számítógép-architektúra-specifikus kézikönyvekbe és ezért hiányoznak innen a kritikus információk belőlük. Ezek az oldalak mint ez is, csak az egész olvasnivaló oldalnak a részdarabkái.

Kérjük, hogy a normális végigolvasás megkezdésének az érdekében látogasson el a Kézikönyv lista weblapra, és onnan kezdve olvassa el az Önnek releváns számítógépes architektúra útmutatásait. Azon az oldalon már a részek egy egésszé vannak összefűzve. Tehát, ne erről az oldalról olvassa a dokumentációt!
Parts kézikönyv
A Gentoo Linux telepítése
A telepítésről
Telepítőképfájl kiválasztása
Hálózat beállítása
Adathordozók előkészítése
Fokozat (stage) fájl
Alaprendszer telepítése
Kernel beállítása
Rendszer beállítása
Eszközök telepítése
Bootloader beállítása
Telepítés véglegesítése
Munka a Gentoo rendszerrel
Portage bemutatása
USE jelölőzászlók
Portage tulajdonságai
Init-szkript rendszer
Környezeti változók
Munka a Portage szoftvercsomag-kezelővel
Fájlok és könyvtárak
Változók
Szoftverágak keverése
További eszközök
Egyéni szoftvercsomag-tárolóhely
Fejlett funkciók
Hálózat beállítása OpenRC init-rendszeren
Munka elkezdése
Fejlett beállítások
Moduláris hálózat
Vezeték nélküli (Wi-Fi)
Funkcionalitás hozzáadása
Dinamikus menedzsment


Chrooting

DNS információ másolása

Még egy dolog van hátra, mielőtt belépnénk az új környezetbe, és ez a DNS információk átmásolása az /etc/resolv.conf fájlba. Ezt azért kell megtenni, hogy a hálózat továbbra is működjön az új környezetbe való belépés után is. Az /etc/resolv.conf fájl tartalmazza a hálózati névszervereket.

Az információ átmásolásakor ajánlott a cp parancshoz hozzáadni a --dereference opciót. Ez biztosítja, hogy ha az /etc/resolv.conf fájl egy szimbolikus link, akkor a link célfájlja legyen másolva a szimbolikus link helyett. Ellenkező esetben az új környezetben a szimbolikus link egy nem létező fájlra mutatna (mivel a link célja valószínűleg nem elérhető az új környezetben).

root #cp --dereference /etc/resolv.conf /mnt/gentoo/etc/

A szükséges fájlrendszerek felcsatolása

Pár pillanat múlva a Linux gyökér könyvtára az új helyre kerül áthelyezésre.

A következő fájlrendszereket kell elérhetővé tenni:

  • /proc/ egy ál-fájlrendszer. Úgy néz ki, mint a szokásos fájlok, de a Linux kernel generálja őket menet közben.
  • /sys/ egy ál-fájlrendszer, hasonló a /proc/ fájlrendszerhez, amelyet egykor a /proc/ helyettesítésére szántak, és sokkal strukturáltabb, mint a /proc/.
  • /dev/ egy normál fájlrendszer, amely tartalmazza az összes eszközt. Részben a Linux eszközkezelő (általában az udev) kezeli.
  • /run/ egy ideiglenes fájlrendszer, amelyet a futásidőben generált fájlok, például PID fájlok vagy zárolások tárolására használnak.

A /proc/ hely a /mnt/gentoo/proc/ helyre lesz felcsatolva, míg a többi fájlrendszer kötött csatolással (bind-mounted) lesz elérhető. Ez utóbbi azt jelenti, hogy például a /mnt/gentoo/sys/ valójában a /sys/ lesz (ez csak egy második bejegyzési pont ugyanahhoz a fájlrendszerhez), míg a /mnt/gentoo/proc/ egy új csatolás (úgymond egy új példány) a fájlrendszerből.

Tip
Ha az eredeti Gentoo telepítési ISO képfájlt használjuk a telepítéskor, akkor ezt a lépést egyszerűen az alábbi paranccsal helyettesíthetjük: arch-chroot /mnt/gentoo.
root #mount --types proc /proc /mnt/gentoo/proc
root #mount --rbind /sys /mnt/gentoo/sys
root #mount --make-rslave /mnt/gentoo/sys
root #mount --rbind /dev /mnt/gentoo/dev
root #mount --make-rslave /mnt/gentoo/dev
root #mount --bind /run /mnt/gentoo/run
root #mount --make-slave /mnt/gentoo/run
Note
A --make-rslave műveletek szükségesek a systemd támogatásához a telepítés későbbi szakaszában.
Warning
Ha nem Gentoo telepítési ISO képfájlt használunk a telepítéskor, akkor ez nem biztos, hogy elegendő. Néhány disztribúció a /dev/shm helyet szimbolikus linkként hozza létre a /run/shm/ helyre, amely a chroot után érvénytelenné válik. Ennek orvoslására a /dev/shm/ helyet helyesen beállított tmpfs csatolással lehet előre megoldani:
root #test -L /dev/shm && rm /dev/shm && mkdir /dev/shm
root #mount --types tmpfs --options nosuid,nodev,noexec shm /dev/shm

Kérjük, biztosítsa azt is, hogy a 1777 mód be legyen állítva:

root #chmod 1777 /dev/shm /run/shm

Belépés az új környezetbe

Most, hogy az összes partíció inicializálva lett és az alap környezet telepítve van, itt az ideje belépni az új telepítési környezetbe a chroot használatával. Ez azt jelenti, hogy a munkamenet megváltoztatja a gyökérhelyét (a legfelső szintű helyet, amely elérhető) a jelenlegi telepítési környezetből (telepítési USB pendrive, DVD vagy más telepítési médium) a telepítési rendszerre (nevezetesen az inicializált partíciókra). Innen származik a név, change root (gyökér megváltoztatása) vagyis chroot.

Ez a chrootolás három lépésben történik:

  1. A gyökérhely módosítása / (a telepítési médiumon) /mnt/gentoo/ (a partíciókon) helyre chroot vagy arch-chroot használatával, ha elérhető.
  2. Néhány beállítás (amelyek az /etc/profile fájlban találhatók) betöltése a memóriába a source parancs segítségével.
  3. Az elsődleges prompt módosítása, hogy emlékeztessen bennünket arra, hogy ez a munkamenet egy chroot környezetben zajlik.
root #chroot /mnt/gentoo /bin/bash
root #source /etc/profile
root #export PS1="(chroot) ${PS1}"

Ettől a ponttól kezdve minden végrehajtott művelet közvetlenül az új Gentoo Linux környezetben történik.

Tip
Ha a Gentoo telepítése ezen a ponton bárhol megszakad, akkor ettől a lépéstől lehetséges a telepítés folytatása. Nincs szükség a lemezek újraparticionálására! Egyszerűen csatolja fel a gyökérpartíciót, és hajtsa végre a fentiekben leírt lépéseket, kezdve a DNS információ másolásával, hogy újra belépjen a munkakörnyezetbe. Ez hasznos lehet a bootloader problémák javításához is. További információk a chroot cikkben találhatók.

Felkészülés a bootloaderre

Most, hogy beléptünk az új környezetbe, szükséges előkészíteni az új környezetet a bootloader számára. Fontos lesz, hogy a megfelelő partíció fel legyen csatolva, amikor eljön az ideje a bootloader telepítésének.

UEFI rendszerek

UEFI rendszerek esetén a /dev/sda1 partíció FAT32 fájlrendszerrel van formázva, és EFI rendszerpartícióként (ESP) lesz felhasználva. Hozzon létre egy új /efi könyvtárat (ha még nem lett létrehozva), majd csatolja oda fel az ESP partíciót:

root #mkdir /efi
root #mount /dev/sda1 /efi

DOS/Örökölt BIOS rendszerek

DOS/Örökölt BIOS rendszerek esetén a bootloader a /boot könyvtárba lesz telepítve, ezért a következőképpen kell felcsatolni:

root #mount /dev/sda1 /boot

Portage szoftvercsomag-kezelő beállítása

Gentoo ebuild szoftvertároló pillanatkép telepítése a weben keresztül

A következő lépés a Gentoo ebuild szoftvertároló pillanatképének a telepítése. Ez a pillanatkép fájlok gyűjteményét tartalmazza, amelyek tájékoztatják a Portage szoftvercsomag-kezelőt a telepíthető szoftverek neveiről, amelyeket a rendszergazda kiválaszthat, szoftvercsomag- vagy profil-specifikus hírelemekről stb.

Az emerge-webrsync parancs használata ajánlott azok számára, akik korlátozó tűzfalak mögött vannak (ez a parancs HTTP/FTP protokollokat használ a pillanatkép letöltéséhez), és ezáltal hálózati sávszélességet takarít meg. Azok az olvasók, akiknek nincs hálózati vagy sávszélesség-korlátozásuk, nyugodtan átugorhatják a következő szakaszt.

Ez a parancs letölti a legfrissebb pillanatképet (amelyet naponta adnak ki) a Gentoo egyik tükörszerveréről és telepíti azt a rendszerünkre:

root #emerge-webrsync
Note
A művelet során az emerge-webrsync panaszkodhat egy hiányzó /var/db/repos/gentoo/ könyvtárra. Ez várható, és nincs miért aggódni, a parancs létrehozza önmagától a hiányzó könyvtárat.

Ettől a ponttól kezdve a Portage szoftvercsomag-kezelő jelezheti, hogy ajánlott bizonyos frissítéseket végrehajtani. Ennek oka, hogy a stage fájlon keresztül telepített rendszer-szoftvercsomagokhoz újabb verziók állhatnak rendelkezésre, és a Portage szoftvercsomag-kezelő most már tisztában van az új szoftvercsomagokkal a szoftvertároló letöltött pillanatképének köszönhetően. A szoftvercsomag-frissítések most biztonságosan figyelmen kívül hagyhatóak, a frissítések elhalaszthatók a Gentoo telepítésének befejezése utánra.


Opcionális: Tükörszerverek kiválasztása

A forráskód gyors letöltése érdekében ajánlott egy gyors, földrajzilag közeli tükörszervert választani. A Portage szoftvercsomag-kezelő a make.conf fájlban keresi a GENTOO_MIRRORS változót, és a benne felsorolt tükörszervereket használja. Lehetséges a Gentoo tükörszerverlista böngészése, és a rendszer fizikai helyéhez közeli tükörszerver (vagy több tükörszerver) keresése (mivel ezek általában a leggyorsabbak).

Az úgynevezett mirrorselect parancs egy szép szöveges felületet biztosít, amely segítségével gyorsabban kereshetőek és választhatóak ki a megfelelő tükörszerverek. Csak navigáljon a választott tükörszerverekre, és nyomja meg a Szóköz billentyűgombot egy vagy több tükörszerver kiválasztásához.

root #emerge --ask --verbose --oneshot app-portage/mirrorselect
root #mirrorselect -i -o >> /etc/portage/make.conf

Alternatív megoldásként egy aktív tükörszerverek listája elérhető online.

Opcionális: A Gentoo ebuild szoftvertároló frissítése

A Gentoo ebuild szoftvertárolót lehetséges a legújabb verzióra frissíteni. Az előző emerge-webrsync parancs egy nagyon friss pillanatképet telepített (általában legfeljebb 24 órás), így ez a lépés mindenképpen opcionális.

Tegyük fel, hogy szükség van a legfrissebb (mondjuk az 1 órán belüli) szoftvercsomag-frissítésekre, akkor használjuk az emerge --sync parancsot. Ez a parancs az rsync protokollt használja a Gentoo ebuild szoftvertároló (amelyet korábban az emerge-webrsync segítségével töltöttek le) frissítéséhez a legújabb állapotra.

root #emerge --sync

Lassú parancssorokon, például bizonyos keretpuffereken vagy soros parancssorokon, ajánlott a --quiet opció használata a folyamat felgyorsítása érdekében:

root #emerge --sync --quiet

Hírelemek olvasása

Amikor a Gentoo ebuild szoftvertároló szinkronizálva van, akkor a Portage hasonló információs üzeneteket jeleníthet meg:

* FONTOS: A 'gentoo' szoftvertárolóban szükséges 2 hírelem elolvasása.
* Használja az eselect news parancsot a hírelemek olvasásához.

A hírelemeket azért hozták létre, hogy kommunikációs eszközként szolgáljanak a kritikus üzenetek felhasználókhoz való eljuttatására a Gentoo ebuild szoftvertárolón keresztül. Ezek kezeléséhez használja az eselect news parancsot. Az eselect alkalmazás egy Gentoo-specifikus eszköz, amely egy közös kezelőfelületet biztosít a rendszeradminisztrációhoz. Ebben az esetben az eselect azzal van megbízva, hogy használja a news modulját.

A news modul esetében három műveletet használnak leggyakrabban:

  • A list paranccsal megjelenik az elérhető hírelemek áttekintése.
  • A read paranccsal elolvashatók a hírelemek.
  • A purge paranccsal a hírelemek eltávolíthatók, miután elolvasták őket, és többé nem lesznek újraolvasva.
root #eselect news list
root #eselect news read

További információ a hírolvasóról elérhető a kézikönyv oldalán:

root #man news.eselect

Megfelelő profil kiválasztása

Tip
A desktop profilok nem kizárólag az asztali környezetekhez vannak. Alkalmasak nagyon kis erőforrást igénylő ablakkezelőkhöz is, mint például az i3 vagy az sway.

Egy profile egy építőelem bármely Gentoo rendszerhez. Nemcsak az alapértelmezett értékeket határozza meg a USE, CFLAGS és más fontos változók számára, hanem az operációs rendszer egy bizonyos szoftvercsomagverzió-tartományhoz is rögzül. Ezeket a beállításokat a Gentoo Portage fejlesztői tartják karban.

Annak érdekében, hogy megnézze, milyen profilt használ jelenleg a rendszer, futtassa az profile parancsot a profile modullal:

root #eselect profile list
Available profile symlink targets:
  [1]   default/linux/amd64/23.0 *
  [2]   default/linux/amd64/23.0/desktop
  [3]   default/linux/amd64/23.0/desktop/gnome
  [4]   default/linux/amd64/23.0/desktop/kde
Note
A parancs kimenete csak egy példa, és idővel változik.
Note
Ha a systemd init-rendszert szeretné használni, akkor válasszon egy olyan profilt, amelynek nevében szerepel a "systemd".

Bizonyos architektúrákhoz elérhetők olyan desktop alprofilok is, amelyek tartalmazzák a gyakran szükséges szoftvercsomagokat az asztali élmény érdekében.

Warning
A profilfrissítéseket nem szabad félvállról venni. Az induló profil kiválasztásakor használja azt a profilt, amely ugyanahhoz a verzióhoz tartozik, mint amit eredetileg a fokozat (stage) fájl használt (pl. 23.0). Minden új profilverziót egy hírelemben jelentenek be, amely tartalmazza az átállási útmutatásokat. Legyen biztos benne, hogy alaposan követi az átállási útmutatásokat, mielőtt egy újabb profilra váltana.

Az amd64 architektúra elérhető profiljainak a megtekintése után a felhasználók kiválaszthatnak egy másik profilt a rendszerhez:

root #eselect profile set 2

Handbook:Parts/Blocks/ProfileChoice/hu

Note
A developer alprofil kifejezetten a Gentoo Linux fejlesztésére szolgál, és nem hétköznapi felhasználók számára készült.

Opcionális: Egy bináris szoftvercsomag-hoszt hozzáadása

2023 decembere óta a Release Engineering csapata egy hivatalos bináris szoftvercsomag-hosztot (köznyelvben rövidítve egyszerűen "binhost") kínál a közösség számára bináris szoftvercsomagok (binpkgs) letöltésére és telepítésére.[1]

Egy bináris szoftvercsomag-hoszt hozzáadása lehetővé teszi a Portage szoftvercsomag-kezelő számára a kriptográfiai aláírással ellátott, forráskódból binárisra lefordított szoftvercsomagok telepítését. Sok esetben a bináris szoftvercsomag-hoszt hozzáadása jelentősen csökkenti a szoftvercsomagok telepítéséhez szükséges átlagos időt, és nagy előnyt jelent, amikor Gentoo operációs rendszert futtatunk régebbi, lassabb vagy alacsony teljesítményű számítógépeken.

Szoftvercsomag-tároló beállítása

A binhost tároló konfigurációja a Portage /etc/portage/binrepos.conf/ könyvtárában található, amely hasonlóan működik a Gentoo ebuild tároló szakaszában említett beállításhoz.

Bináris hoszt meghatározásakor két fontos szempontot kell figyelembe venni:

  1. A sync-uri értékében szereplő architektúra és profil célpontok valóban számítanak, és igazodniuk kell a megfelelő számítógép architektúrához (ebben az esetben amd64) és a Megfelelő profil kiválasztása szakaszban kiválasztott rendszerprofilhoz.
  2. Egy gyors, földrajzilag közeli tükörszerver kiválasztása általában lerövidíti a letöltési időt. Tekintse át a mirrorselect eszközt, amely az Opcionális: Tükrök kiválasztása szakaszban található, vagy tekintse át az online tükörszerverek listáját, ahol URL értékeket találhat.

FILE /etc/portage/binrepos.conf/gentoobinhost.confCDN alapú bináris szoftvercsomag-hoszt példája
[binhost]
priority = 9999
sync-uri = https://distfiles.gentoo.org/releases/<arch>/binpackages/<profile>/x86-64/

Bináris szoftvercsomagok telepítése

A Portage szoftvercsomag-kezelő alapértelmezés szerint a szoftvercsomagokat forráskódból szokta lefordítani. Az alábbi módokon utasíthatja a bináris csomagok használatára:

  1. A --getbinpkg opció megadható az emerge parancs meghívásakor. Ez a bináris szoftvercsomag telepítésének módszere hasznos, ha csak egy adott bináris szoftvercsomagot szeretne telepíteni.
  2. A rendszer alapértelmezett beállításának megváltoztatása a Portage FEATURES változóján keresztül, amely a /etc/portage/make.conf fájlon keresztül érhető el. Ennek a konfigurációs módosításnak az alkalmazása miatt a Portage a bináris szoftvercsomag hosztot fogja lekérdezni a kért csomag(ok)ért, és helyben fog lefordítani, ha nem talál eredményeket.

Például, hogy a Portage mindig telepítse az elérhető bináris csomagokat:

FILE /etc/portage/make.confKonfigurálja a Portage szoftvercsomag-kezelőt úgy, hogy alapértelmezés szerint bináris szoftvercsomagokat használjon
# Appending getbinpkg to the list of values within the FEATURES variable
FEATURES="${FEATURES} getbinpkg"
# Require signatures
FEATURES="${FEATURES} binpkg-request-signature"

Kérjük, futtassa a getuto parancsot is, hogy a Portage beállítsa a szükséges kulcstartót a hitelesítéshez:

root #getuto

A Portage szoftvercsomag-kezelő további funkcióit a kézikönyv következő fejezetében tárgyaljuk.

Opcionális: A USE változó beállítása

A USE az egyik legerőteljesebb változó, amelyet a Gentoo operációs rendszer biztosít a felhasználói számára. Számos program lefordítható választható támogatással bizonyos elemek támogatásával vagy azon elemek nélkül. Például néhány program lefordítható GTK+ támogatással vagy Qt támogatással. Mások lefordíthatók SSL támogatással vagy anélkül. Egyes programok lefordíthatók framebuffer támogatással (svgalib) X11 támogatás helyett (X-server).

A legtöbb disztribúció a csomagjaikat minél szélesebb támogatottsággal fordítja le, ami növeli a programok méretét és az indítási időt, nem is beszélve a rengeteg függőségről. A Gentoo operációs rendszerrel a felhasználók meghatározhatják, hogy egy szoftvercsomagot milyen opciókkal kell lefordítani bináris futtatható kódra. Itt lép be a képbe a USE változó.

A USE változóban a felhasználók kulcsszavakat határoznak meg, amelyek a fordítási opciókra vannak leképezve. Például a ssl lefordítja az SSL támogatást a programokba, amelyek támogatják azt. A -X eltávolítja az X-server támogatást (figyelje meg a mínusz jelet az elején). A gnome gtk -kde -qt5 lefordítja a programokat GNOME (és GTK+) támogatással, és nem KDE (és Qt) támogatással, teljesen a GNOME-hoz igazítva a rendszert (ha az architektúra támogatja).

Az operációs rendszer által használt Gentoo profil make.defaults fájljaiba kerülnek az alapértelmezett USE beállítások. A Gentoo egy összetett öröklési rendszert használ a rendszerprofilokhoz, amelyet az telepítési folyamat során nem részletezünk. A legkönnyebb módja annak, hogy ellenőrizze az aktuálisan aktív USE beállításokat, az a emerge --info parancs futtatása és a sor kiválasztása, amely a USE: kifejezéssel kezdődik.

root #emerge --info | grep ^USE
USE="X acl alsa amd64 berkdb bindist bzip2 cli cracklib crypt cxx dri ..."
Note
A fenti példa lerövidített, a tényleges USE értékek listája sokkal, sokkal nagyobb.

A rendelkezésre álló USE jelölőzászlók teljes leírása megtalálható a rendszerben a /var/db/repos/gentoo/profiles/use.desc fájlban.

root #less /var/db/repos/gentoo/profiles/use.desc

A less parancsban a görgetés a és billentyűkkel végezhető el, és a kilépés a q megnyomásával történik.

Példaként bemutatjuk egy KDE alapú rendszer USE változó beállításait DVD, ALSA és CD rögzítési támogatással:

root #nano /etc/portage/make.conf
FILE /etc/portage/make.confJelölőzászlók engedélyezése egy KDE/Plasma alapú rendszerhez DVD, ALSA és CD rögzítési támogatással
USE="-gtk -gnome qt5 kde dvd alsa cdr"

Amikor egy USE érték meg van határozva a /etc/portage/make.conf fájlban, az hozzáadódik az operációs rendszer USE jelölőzászlólistájához. A USE jelölőzászlókat globálisan el lehet távolítani úgy, hogy egy - mínusz jelet teszünk az érték elé a listában. Például az X grafikus környezetek támogatásának letiltásához a -X értéket lehet beállítani:

FILE /etc/portage/make.confAz alapértelmezett USE jelölőzászlók figyelmen kívül hagyása
USE="-X acl alsa"
Warning
Bár lehetséges, a -* beállítása (amely minden USE értéket letilt, kivéve azokat, amelyek a make.conf fájlban vannak megadva) erősen ellenzett és egyáltalán nem bölcs dolog. Az ebuild fejlesztők bizonyos alapértelmezett USE jelölőzászló értékeket választanak az ebuild-ekben annak érdekében, hogy elkerüljék a konfliktusokat, növeljék a biztonságot, és elkerüljék a hibákat, valamint egyéb okok miatt. Az összes USE jelölőzászló letiltása megszünteti az alapértelmezett viselkedést, és súlyos problémákat okozhat.

CPU_FLAGS_*

Néhány architektúrában (beleértve az AMD64/X86, ARM, PPC) van egy USE_EXPAND változó, amelyet CPU_FLAGS_<ARCH>-nek neveznek, ahol az <ARCH> helyére a releváns rendszer-architektúra neve kerül.

Important
Ne legyen összezavarodva! Az AMD64 és az X86 rendszerek osztoznak néhány közös architektúrán, így az AMD64 rendszerek megfelelő változó neve a CPU_FLAGS_X86.

Ezt arra használják, hogy a buildet specifikus assembly kódba vagy egyéb, általában kézzel írt vagy más egyedi utasításokkal fordítsák le, és nem azonos azzal, hogy a kódfordítót arra kérjük, hogy optimalizált kódot generáljon egy adott processzor jellemzőhöz (pl. -march=).

A felhasználóknak ezt a változót be kell állítaniuk az általuk kívánt COMMON_FLAGS konfigurálása mellett.

Néhány lépés szükséges ennek beállításához:

root #emerge --ask --oneshot app-portage/cpuid2cpuflags

Ellenőrizze a kimenetet manuálisan, ha kíváncsi:

root #cpuid2cpuflags

Majd másolja a kimenetet a package.use fájlba:

root #echo "*/* $(cpuid2cpuflags)" > /etc/portage/package.use/00cpu-flags

VIDEO_CARDS

A VIDEO_CARDS USE_EXPAND változót megfelelően kell beállítani az elérhető grafikus processzorok függvényében. A VIDEO_CARDS beállítása nem szükséges, ha csak konzolos telepítést végez.

Az alábbiakban egy megfelelően beállított VIDEO_CARDS változó példája látható. Cserélje ki a használandó illesztőprogram(ok) nevét.

FILE /etc/portage/make.conf
VIDEO_CARDS="amdgpu radeonsi"

A különféle grafikus processzorokra vonatkozó részletek megtalálhatók az AMDGPU, Intel, Nouveau (Open Source), vagy NVIDIA (Proprietary) cikkekben.

Opcionális: Az ACCEPT_LICENSE változó konfigurálása

A Gentoo Linux Enhancement Proposal 23 (GLEP 23) bevezetésével egy mechanizmust hoztak létre, amely lehetővé teszi a rendszergazdák számára, hogy "szabályozzák a telepített szoftvereket a licencük szempontjából... Néhányan olyan rendszert akarnak, amely mentes minden olyan szoftvertől, amelyet az OSI nem hagyott jóvá; mások egyszerűen kíváncsiak arra, hogy milyen licenceket fogadnak el implicit módon."[2] Az a szándék vezérelte őket, hogy részletesebb ellenőrzést gyakoroljanak a Gentoo rendszeren futó szoftverek felett, így született meg az ACCEPT_LICENSE változó.

A telepítési folyamat során a Portage szoftvercsomag-kezelő figyelembe veszi az ACCEPT_LICENSE változóban beállított értékeket annak megállapításához, hogy a kért szoftvercsomagok megfelelnek-e a rendszergazda által elfogadhatónak ítélt licencnek. Itt rejlik egy probléma: a Gentoo ebuild szoftvercsomag-tároló több ezer ebuildet tartalmaz, ami több száz különálló szoftverlicencet eredményez... Ez azt jelenti, hogy a rendszergazdának minden egyes új szoftverlicencet egyenként kell jóváhagynia? Szerencsére nem. A GLEP 23 egy megoldást is vázol erre a problémára, egy licenc csoportoknak nevezett koncepció formájában.

A rendszer-adminisztráció kényelmét szolgálja, hogy a jogilag hasonló szoftverlicenceket egybecsomagolták – mindegyiket hasonló típusának megfelelően. A licenccsoport-definíciók megtekinthetők, és a Gentoo Licenses projekt kezeli őket. Az egyedi licencek nincsenek egybecsomagolva. A licenccsoportokat szintaktikailag egy @ szimbólum előzi meg, ami lehetővé teszi azok könnyű megkülönböztetését az ACCEPT_LICENSE változóban.

Néhány gyakori licenc csoport közé tartozik:

Egy lista a szoftverlicencekről, amelyek a típusaik szerint csoportosítva vannak.
Név Leírás
@GPL-COMPATIBLE A Free Software Foundation által jóváhagyott GPL-kompatibilis licencek [a_license 1].
@FSF-APPROVED Az FSF által jóváhagyott ingyenes szoftverlicencek (tartalmazza @GPL-COMPATIBLE).
@OSI-APPROVED Licenses approved by the Open Source Initiative [a_license 2]
@MISC-FREE Misc licenses that are probably free software, i.e. follow the Free Software Definition [a_license 3] but are not approved by either FSF or OSI
@FREE-SOFTWARE Combines @FSF-APPROVED, @OSI-APPROVED, and @MISC-FREE.
@FSF-APPROVED-OTHER FSF-approved licenses for "free documentation" and "works of practical use besides software and documentation" (including fonts)
@MISC-FREE-DOCS Misc licenses for free documents and other works (including fonts) that follow the free definition [a_license 4] but are NOT listed in @FSF-APPROVED-OTHER.
@FREE-DOCUMENTS Combines @FSF-APPROVED-OTHER and @MISC-FREE-DOCS.
@FREE Metaset of all licenses with the freedom to use, share, modify and share modifications. Combines @FREE-SOFTWARE and @FREE-DOCUMENTS.
@BINARY-REDISTRIBUTABLE Licenses that at least permit free redistribution of the software in binary form. Includes @FREE.
@EULA License agreements that try to take away your rights. These are more restrictive than "all-rights-reserved" or require explicit approval

A jelenleg rendszer szinten elfogadható licencértékek a következőképpen tekinthetők meg:

user $portageq envvar ACCEPT_LICENSE
@FREE

As visible in the output, the default value is to only allow software which has been grouped into the @FREE category to be installed.

Specific licenses or licenses groups for a system can be defined in the following locations:

  • System wide within the selected profile - this sets the default value.
  • System wide within the /etc/portage/make.conf file. System administrators override the profile's default value within this file.
  • Per-package within a /etc/portage/package.license file.
  • Per-package within a /etc/portage/package.license/ directory of files.

The system wide license default in the profile is overridden within the /etc/portage/make.conf:

FILE /etc/portage/make.confAccept licenses with ACCEPT_LICENSE system wide
# Overrides the profile's ACCEPT_LICENSE default value
ACCEPT_LICENSE="-* @FREE @BINARY-REDISTRIBUTABLE"

Optionally system administrators can also define accepted licenses per-package as shown in the following directory of files example. Note that the package.license directory will need created if it does not already exist:

root #mkdir /etc/portage/package.license

Software license details for an individual Gentoo package are stored within the LICENSE variable of the associated ebuild. One package may have one or many software licenses, therefore it be necessary to specify multiple acceptable licenses for a single package.

FILE /etc/portage/package.license/kernelAccepting licenses on a per-package basis
app-arch/unrar unRAR
sys-kernel/linux-firmware @BINARY-REDISTRIBUTABLE
sys-firmware/intel-microcode intel-ucode
Important
The LICENSE variable in an ebuild is only a guideline for Gentoo developers and users. It is not a legal statement, and there is no guarantee that it will reflect reality. It is recommended to not solely rely on a ebuild developer's interpretation of a software package's license; but check the package itself in depth, including all files that have been installed to the system.

Optional: Updating the @world set

Updating the system's @world set is optional and will be unlikely to perform functional changes unless one or more of the following optional steps have been performed:

  1. A profile target different from the stage file has been selected.
  2. Additional USE flags have been set for installed packages.

Readers who are performing an 'install Gentoo speed run' may safely skip @world set updates until after their system has rebooted into the new Gentoo environment.

Readers who are performing a slow run can have Portage perform updates for package, profile, and/or USE flag changes at the present time:

root #emerge --ask --verbose --update --deep --newuse @world

Removing obsolete packages

It is important to always depclean after system upgrades to remove obsolete packages. Review the output carefully with emerge --depclean --pretend to see if any of the to-be-cleaned packages should be kept if personally using them. To keep a package which would otherwise be depcleaned, use emerge --noreplace foo.

root #emerge --ask --pretend --depclean

If happy, then proceed with a real depclean:

root #emerge --ask --depclean
Tip
If a desktop environment profile target has been selected from a non-desktop stage file, the @world update process could greatly extend the amount of time necessary for the install process. Those in a time crunch can work by this 'rule of thumb': the shorter the profile name, the less specific the system's @world set. The less specific the @world set, the fewer packages the system will require. E.g.:
  • Selecting default/linux/amd64/23.0 will likely require fewer packages to be updated, whereas
  • Selecting default/linux/amd64/23.0/desktop/gnome/systemd will likely require more packages to be installed since the profile target has a larger @system and @profile sets: dependencies supporting the GNOME desktop environment.


Időzóna

Note
Ez a lépés nem vonatkozik a musl libc felhasználóira. Azok a felhasználók, akik nem tudják, mit jelent ez, hajtsák végre ezt a lépést.
Warning
Please avoid the /usr/share/zoneinfo/Etc/GMT* timezones as their names do not indicate the expected zones. For instance, GMT-8 is in fact GMT+8.

Select the timezone for the system. Look for the available timezones in /usr/share/zoneinfo/:

root #ls -l /usr/share/zoneinfo
total 352
drwxr-xr-x 2 root root   1120 Jan  7 17:41 Africa
drwxr-xr-x 6 root root   2960 Jan  7 17:41 America
drwxr-xr-x 2 root root    280 Jan  7 17:41 Antarctica
drwxr-xr-x 2 root root     60 Jan  7 17:41 Arctic
drwxr-xr-x 2 root root   2020 Jan  7 17:41 Asia
drwxr-xr-x 2 root root    280 Jan  7 17:41 Atlantic
drwxr-xr-x 2 root root    500 Jan  7 17:41 Australia
drwxr-xr-x 2 root root    120 Jan  7 17:41 Brazil
-rw-r--r-- 1 root root   2094 Dec  3 17:19 CET
-rw-r--r-- 1 root root   2310 Dec  3 17:19 CST6CDT
drwxr-xr-x 2 root root    200 Jan  7 17:41 Canada
drwxr-xr-x 2 root root     80 Jan  7 17:41 Chile
-rw-r--r-- 1 root root   2416 Dec  3 17:19 Cuba
-rw-r--r-- 1 root root   1908 Dec  3 17:19 EET
-rw-r--r-- 1 root root    114 Dec  3 17:19 EST
-rw-r--r-- 1 root root   2310 Dec  3 17:19 EST5EDT
-rw-r--r-- 1 root root   2399 Dec  3 17:19 Egypt
-rw-r--r-- 1 root root   3492 Dec  3 17:19 Eire
drwxr-xr-x 2 root root    740 Jan  7 17:41 Etc
drwxr-xr-x 2 root root   1320 Jan  7 17:41 Europe
...
root #ls -l /usr/share/zoneinfo/Europe/
total 256
-rw-r--r-- 1 root root 2933 Dec  3 17:19 Amsterdam
-rw-r--r-- 1 root root 1742 Dec  3 17:19 Andorra
-rw-r--r-- 1 root root 1151 Dec  3 17:19 Astrakhan
-rw-r--r-- 1 root root 2262 Dec  3 17:19 Athens
-rw-r--r-- 1 root root 3664 Dec  3 17:19 Belfast
-rw-r--r-- 1 root root 1920 Dec  3 17:19 Belgrade
-rw-r--r-- 1 root root 2298 Dec  3 17:19 Berlin
-rw-r--r-- 1 root root 2301 Dec  3 17:19 Bratislava
-rw-r--r-- 1 root root 2933 Dec  3 17:19 Brussels
...

Suppose the timezone of choice is Europe/Brussels.

OpenRC

The desired timezone name can be written to /etc/timezone:

root #echo "Europe/Brussels" > /etc/timezone

Finally, the sys-libs/timezone-data package can be reconfigured - updating /etc/localtime, based on the /etc/timezone entry:

root #emerge --config sys-libs/timezone-data
Note
The /etc/localtime file is used by the system C library to know the timezone the system is in.

systemd

A slightly different approach is employed when using systemd. A symbolic link is generated:

root #ln -sf ../usr/share/zoneinfo/Europe/Brussels /etc/localtime

Later, when systemd is running, the timezone and related settings can be configured with the timedatectl command.

Configure locales

Note
This step does not apply to users of the musl libc. Users who do not know what that means should perform this step.

Locale generation

Most users will want to use only one or two locales on their system.

Locales specify not only the language that the user should use to interact with the system, but also the rules for sorting strings, displaying dates and times, etc. Locales are case sensitive and must be represented exactly as described. A full listing of available locales can be found in the /usr/share/i18n/SUPPORTED file.

Supported system locales must be defined in the /etc/locale.gen file.

root #nano /etc/locale.gen

The following locales are an example to get both English (United States) and German (Germany/Deutschland) with the accompanying character formats (like UTF-8).

FILE /etc/locale.genEnabling US and DE locales with the appropriate character formats
en_US ISO-8859-1
en_US.UTF-8 UTF-8
de_DE ISO-8859-1
de_DE.UTF-8 UTF-8
Warning
Many applications require least one UTF-8 locale to build properly.

The next step is to run the locale-gen command. This command generates all locales specified in the /etc/locale.gen file.

root #locale-gen

To verify that the selected locales are now available, run locale -a.

On systemd installs, localectl can be used, e.g. localectl set-locale ... or localectl list-locales.

Locale selection

Once done, it is now time to set the system-wide locale settings. Again eselect is used, now with the locale module.

With eselect locale list, the available targets are displayed:

root #eselect locale list
Available targets for the LANG variable:
  [1]  C
  [2]  C.utf8
  [3]  en_US
  [4]  en_US.iso88591
  [5]  en_US.utf8
  [6]  de_DE
  [7]  de_DE.iso88591
  [8]  de_DE.utf8
  [9] POSIX
  [ ]  (free form)

With eselect locale set <NUMBER> the correct locale can be selected:

root #eselect locale set 2

Manually, this can still be accomplished through the /etc/env.d/02locale file and for systemd the /etc/locale.conf file:

FILE /etc/env.d/02localeManually setting system locale definitions
LANG="de_DE.UTF-8"
LC_COLLATE="C.UTF-8"

Setting the locale will avoid warnings and errors during kernel and software compilations later in the installation.

Now reload the environment:

root #env-update && source /etc/profile && export PS1="(chroot) ${PS1}"

For additional guidance through the locale selection process read also the Localization guide and the UTF-8 guide.

Hivatkozások