Handbook:Parts/Installation/Stage

From Gentoo Wiki
Jump to:navigation Jump to:search
This page is a translated version of the page Handbook:Parts/Installation/Stage and the translation is 5% complete.
Outdated translations are marked like this.
Tip
On supported architectures, it is recommended for users targeting a desktop (graphical) operating system environment to use a stage file with the term desktop within the name. These files include packages such as sys-devel/llvm and dev-lang/rust-bin and USE flag tuning which will greatly improve install time.

The stage file acts as the seed of a Gentoo install. Stage files are generated with Catalyst by the Release Engineering Team. Stage files are based on specific profiles, and contain an almost-complete system.

When choosing a stage file, it's important to pick one with profile targets corresponding to the desired system type.

Önemli
While it's possible to make major profile changes after an installation has been established, switching requires substantial effort and consideration, and is outside the scope of this installation manual. Switching init systems is difficult, but switching from no-multilib to multilib requires extensive Gentoo and low-level toolchain knowledge.
Tip
Most users should not need to use the 'advanced' tarballs options; they are for atypical or advanced software or hardware configurations.

OpenRC

OpenRC is a dependency-based init system (responsible for starting up system services once the kernel has booted) that maintains compatibility with the system provided init program, normally located in /sbin/init. It is Gentoo's native and original init system, but is also deployed by a few other Linux distributions and BSD systems.

OpenRC does not function as a replacement for the /sbin/init file by default and is 100% compatible with Gentoo init scripts. This means a solution can be found to run the dozens of daemons in the Gentoo ebuild repository.

systemd

systemd is a modern SysV-style init and rc replacement for Linux systems. It is used as the primary init system by a majority of Linux distributions. systemd is fully supported in Gentoo and works for its intended purpose. If something seems lacking in the Handbook for a systemd install path, review the systemd article before asking for support.

Multilib (32 and 64-bit)

Not
Not every architecture has a multilib option. Many only run with native code. Multilib is most commonly applied to amd64.

The multilib profile uses 64-bit libraries when possible, and only falls back to the 32-bit versions when strictly necessary for compatibility. This is an excellent option for the majority of installations because it provides a great amount of flexibility for customization in the future.

Tip
Using multilib targets makes it easier to switch profiles later, compared to no-multilib

No-multilib (pure 64-bit)

Uyarı
Readers who are just starting out with Gentoo should not choose a no-multilib tarball unless it is absolutely necessary. Migrating from a no-multilib to a multilib system requires an extremely well-working knowledge of Gentoo and the lower-level toolchain (it may even cause our Toolchain developers to shudder a little). It is not for the faint of heart and is beyond the scope of this guide.

Selecting a no-multilib tarball to be the base of the system provides a complete 64-bit operating system environment - free of 32-bit software. This effectively renders the ability to switch to multilib profiles burdensome, although still technically possible.

Kurulum dosyasını indirmek

Before downloading the stage file, the current directory should be set to the location of the mount used for the install:

root #cd /mnt/gentoo

Tarihi ve saati ayarlamak

Stage archives are generally obtained using HTTPS which requires relatively accurate system time. Clock skew can prevent downloads from working, and can cause unpredictable errors if the system time is adjusted by any considerable amount after installation.

The current date and time can be verified with date:

root #date
Mon Oct  3 13:16:22 PDT 2021

If the displayed date/time is more than few minutes off, it should be updated using one of the following methods.

Automatic

Using NTP to correct clock skew is typically easier and more reliable than manually setting the system clock.

chronyd, part of net-misc/chrony can be used to update the system clock to UTC with:

root #chronyd -q
Önemli
Systems without a functioning Real-Time Clock (RTC) must sync the system clock at every system start, and on regular intervals thereafter. This is also beneficial for systems with a RTC, as the battery could fail, and clock skew can accumulate.
Uyarı
Standard NTP traffic not authenticated, it is important to verify time data obtained from the network.

Manual

When NTP access is unavailable, date can be used to manually set the system clock.

Not
UTC time is recommended for all Linux systems. Later, a system timezone is defined, which changes the offset when the date is displayed.

The following argument format is used to set the time: MMDDhhmmYYYY syntax (Month, Day, hour, minute and Year).

Örneğin sistemin zamanını 29 Mart 2014, 16:21 olarak ayarlamak için:

root #date 032916212014

Graphical browsers

Those using environments with fully graphical web browsers will have no problem copying a stage file URL from the main website's download section. Simply select the appropriate tab, right click the link to the stage file, then Copy Link to copy the link to the clipboard, then paste the link to the wget utility on the command-line to download the stage file:

root #wget <PASTED_STAGE_FILE_URL>

Command-line browsers

More traditional readers or 'old timer' Gentoo users, working exclusively from command-line may prefer using links (www-client/links), a non-graphical, menu-driven browser. To download a stage, surf to the Gentoo mirror list like so:

links ile bir HTTP proxy (ağ geçidi) kullanmak istiyorsanız, -http-proxy seçeneği ile belirtebilirsiniz:

root #links -http-proxy proxy.server.com:8080 https://www.gentoo.org/downloads/mirrors/

links'e benzer bir tarayıcı olarak, dilerseniz lynx de kullanabilirsiniz.

Eğer proxy gerekiyorsa, http_proxy ve/veya ftp_proxy ortam değişkenlerini atayabilirsiniz:

root #export http_proxy="http://proxy.sunucu.com:port"
root #export ftp_proxy="http://proxy.sunucu.com:port"

Yansı listesinde, fiziki olarak size yakın bir yansı seçin. Genellikle HTTP yansılar yeterli olmakta, ancak dilerseniz diğer protokollerde erişim sağlanabilen yansılar da var. releases/amd64/autobuilds/ dizinine gidin. Kuruluma elverişli tüm dosyaları burada bulabilirsiniz (alt-mimariye göre dizinlere ayrılmış bir yapı da görebilirsiniz). Bir tane dosya seçip, indirmek için D tuşuna basın.

After the stage file download completes, it is possible to verify the integrity and validate the contents of the stage file. Those interested should proceed to the next section.

İşlem tamamlandığında Q tuluna basarak çıkabilirsiniz.

Verifying and validating

Not
Most stages are now explicitly suffixed with the init system type (openrc or systemd), although some architectures may still be missing these for now.

Minimal kurulum CD'lerinde olduğu gibi, burada da bazı yardımcı dosyalar bulunmakta:

  • .CONTENTS dosyası, ilgili kurulum dosyasında bulunan dosyaların listesini içerir
  • .DIGESTS dosyası, kurulum dosyasının farklı algoritmalar ile çıkarılmış parmak izini içerir
  • .DIGESTS.asc dosyası da tıpkı .DIGESTS dosyası gibi parmakizlerini içerir, ancak kriptografik olarak Gentoo projesi tarafından imzalanmış dosyadır
root #wget https://distfiles.gentoo.org/releases/
  • .CONTENTS.gz - A compressed file that contains a list of all files inside the stage file.
  • .DIGESTS - Contains checksums of the stage file in using several cryptographic hash algorithms.
  • .sha256 - Contains a PGP signed SHA256 checksum of the stage file. This file may not be available for download for all stage files.

İndirdikten sonra, kurulum dosyasının bütünlüğünü kontrol edebilirsiniz. openssl kullanarak parmak izi üretip, .DIGESTS veya .DIGESTS.asc dosyasındaki iz ile karşılaştırabilirsiniz.

Örneğin SHA512 izini onaylamak için:

root #openssl dgst -r -sha512 stage3-amd64-<release>.tar.bz2

dgst instructs the openssl command to use the Message Digest sub-command, -r prints the digest output in coreutils format, and -sha512 selects the SHA512 digest.

Whirlpool kontrolü için:

root #openssl dgst -r -whirlpool stage3-amd64-<release>.tar.bz2

Komutların çıktılarını .DIGESTS(.asc) dosyaları ile kıyaslayabilirsiniz. Eğer değerler uyuşmuyorsa indirdiğiniz dosya hatalı olabilir.

sha512sum komutu da kullanabilirsiniz:

root #sha512sum stage3-amd64-<release>.tar.bz2

The --check option instructs sha256sum to read a list of expected files and associated hashes, and then print an associated "OK" for each file that calculates correctly or a "FAILED" for files that do not.

ISO kalıbı gibi, bu dosyanın da kriptografik imzasını .DIGESTS.asc yardımıyla onaylayabilirsiniz. Örnek olarak gpg ile kontrol edelim:

For official Gentoo live images, the sec-keys/openpgp-keys-gentoo-release package provides PGP signing keys for automated releases. The keys must first be imported into the user's session in order to be used for verification:

root #gpg --import /usr/share/openpgp-keys/gentoo-release.asc

For all non-official live images which offer gpg and wget in the live environment, a bundle containing Gentoo keys can be fetched and imported:

root #wget -O - https://qa-reports.gentoo.org/output/service-keys.gpg | gpg --import

Verify the signature of the tarball and, optionally, associated checksum files:

root #gpg --verify stage3-amd64-<release>.tar.bz2.DIGESTS.asc

If verification succeeds, "Good signature from" will be in the output of the previous command(s).

The fingerprints of the OpenPGP keys used for signing release media can be found on the release media signatures page.

Kurulum dosyasını yüklemek

Şimdi tar komutunun yardımı ile kurulum paketini sistemimize çıkartıyoruz:

root #tar xvjpf stage3-*.tar.bz2 --xattrs

Kullandığınız seçeneklerin (xvjpf ve --xattrs) doğruluğunu kontrol edin. x çıkartmaya, v detaylı bilgi almaya, j dosyanın bir bzip2 dosyası olduğuna, p dosya içerisindeki izinlerin korunması gerektiğine, f de komuta bir paketi parametre olarak vereceğimizi işaret eder. --xattrs ise paketteki gelişmiş dosya etiketlerini de korumamız gerektiğini belirtir.

  • x extract, instructs tar to extract the contents of the archive.
  • p preserve permissions.
  • v verbose output.
  • f file, provides tar with the name of the input archive.
  • --xattrs-include='*.*' Preserves extended attributes in all namespaces stored in the archive.
  • --numeric-owner Ensure that the user and group IDs of files being extracted from the tarball remain the same as Gentoo's release engineering team intended (even if adventurous users are not using official Gentoo live environments for the installation process).

Paketimizi kurduğumuza göre derleme seçeneklerini düzenleme ile devam edebiliriz.

Derleme seçeneklerini düzenleme

Giriş

Gentoo'yu kendi ihtiyacımıza göre düzenlemek için, Portage davranışını etkileyecek olan bazı değişkenleri ayarlayabiliriz. Tüm bunlar tabi ki export ile ayarlanabilir, ancak kalıcı olmaz. Bunun yerine Portage'ın okuduğu /etc/portage/make.conf dosyasında düzenlemeler yapacağız.

Not
Technically variables can be exported via the shell's profile or rc files, however that is not best practice for basic system administration.

Portage reads in the make.conf file when it runs, which will change runtime behavior depending on the values saved in the file. make.conf can be considered the primary configuration file for Portage, so treat its content carefully.

Not
Tüm geçerli değişkenler /mnt/gentoo/usr/share/portage/config/make.conf.example dosyasında var. Ancak başarılı bir kurulum için aşağıdakilerin ayarlanması yeterli.

For a successful Gentoo installation only the variables that are mentioned below need to be set.}}

Bir editör açıp (biz nano kullanacağız) bahsedeceğimiz değişkenleri ayarlayabiliriz.

root #nano -w /mnt/gentoo/etc/portage/make.conf

make.conf.example dosyasında da görülebileceği gibi dosyanın biçimlendirilme türü, yorum olan satıların "#" ile başlaması, diğer satırların da DEĞİŞKEN="içerik" şeklinde tanımlanması.

CFLAGS ve CXXFLAGS

CFLAGS ve CXXFLAGS değerleri, C ve C++ kodları derlememize yarayacak olan gcc derleyicisi tarafından kullanılmakta. Burada genel olarak tanımlayacağız ancak (yönetimi biraz karmaşık olsa da) sisteminizden maksimum performansı almak için her uygulamanın nasıl derlenmesi gerektiğini de tanımlayabilirsiniz.

make.conf dosyasında sistemin genelinde kullanılması faydalı olan seçenekler ayarlanmalıdır. Burada kararlı olduğundan emin olmadığınız, deneysel ayarlar uygularsanız faydadan çok zararını görürsünüz (çalışmayan veya hatalı çalışan uygulamalar).

Mümkün olan tüm değişkenleri anlatmayacağız. Dilerseniz GNU online belgeleri'ni veya gcc bilgilendirme sayfasını (Linux sistemlerde info gcc komutuyla) inceleyebilirsiniz. make.conf.example dosyası da gayet açıklayıcıdır, okumanızı tavsiye ederiz.

İlk ayarlardan biri hedef mimariyi belirleyen -march= veya -mtune= bayrağı. Kullanılabilecek değişkenler make.conf.example dosyasında (yorumlu olarak) var. En sık kullanılan değer, derleyiciye mimariyi otomatik olarak seçmesini belirten native değişkeni.

Bir diğer değişken de gcc'nin optimizasyon seviyesini ayarlayan -O bayrağı (sıfır değil, büyük o harfi). Kullanılabilecek değişkenler s (boyut optimizasyonu), 0 (yani sıfır, optimizasyonsuz), 1, 2, hatta daha fazla optimizasyon için 3. Her seviye önceki seviyeye bazı eklemelerde bulunur. -O3 sistem genelinde kullanıldığında bazı hatalara sebep olmaktadır, bu sebeple önerilen değer -O2'dir.

Diğer bir popüler bayrak da -pipe. Bu bayrak derlemenin bazı aşamalarında geçiş için geçici dosyalar yerine pipe (geçiş özelliği) kullanılmasını sağlar. Oluşturulan kodda bir değişiklik olmamakta, ancak derlemenin daha fazla RAM kullanarak daha hızlı tamamlanmasını sağlamaktadır. Düşük RAM'e sahip sistemlerde önerilmez.

-fomit-frame-pointer gibi bazı değişkenler kullanılması uygulamalar hata ürettiğinde hataların ayıklanarak farkedilmesini zorlaştırıcı etkiler barındırmaktadır.

CFLAGS ve CXXFLAGS değerlendirilirken kullanmak istediğiniz bayrakları tek satırda toplayın. Kurulum paketinde gelen bayraklar genelde yeterli olmakta. Aşağıda da bir örnek görebilirsiniz:

CODE Örnek CFLAGS ve CXXFLAGS değişkenleri
CFLAGS="-march=native -O2 -pipe"
# Her iki değişken için de aynısını kullanalım
CXXFLAGS="${CFLAGS}"
Not
GCC optimizasyon sayfasında farklı bayrakların sistemi nasıl etkileyeceğine dair detaylı açıklamalar bulabilirsiniz.

MAKEOPTS

MAKEOPTS değişkeni aynı anda işlemci katmanında kaç tane derleme işleminin paralel olarak yapılması gerektiğini ayarlar. Her durumda olmasa da, genellikle sistemdeki işlemci çekirdeği sayısının bir fazlası en uygun değer olarak tanımlanır.

Further, as of Portage 3.0.53[1], if left undefined, Portage's default behavior is to set the MAKEOPTS load-average value to the same number of threads returned by nproc.

A good choice is the smaller of: the number of threads the CPU has, or the total amount of system RAM divided by 2 GiB.

Uyarı
Using a large number of jobs can significantly impact memory consumption. A good recommendation is to have at least 2 GiB of RAM for every job specified (so, e.g. -j6 requires at least 12 GiB). To avoid running out of memory, lower the number of jobs to fit the available memory.
Tip
When using parallel emerges (--jobs), the effective number of jobs run can grow exponentially (up to make jobs multiplied by emerge jobs). This can be worked around by running a localhost-only distcc configuration that will limit the number of compiler instances per host.
CODE make.conf'da örnek MAKEOPTS tanımı
MAKEOPTS="-j2"

Search for MAKEOPTS in man 5 make.conf for more details.

Hazırsanız başlayalım

/mnt/gentoo/etc/portage/make.conf dosyasını isteğinize göre düzenleyip dosyayı kaydedin (nano ile düzenliyorsanız Ctrl+X ile çıkış diyaloğunu açabilirsiniz).