Difference between pages "Funtoo:Keychain" and "Install/de/Partitioning"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
{{Article
<noinclude>
|Subtitle=Official Project Page
{{InstallPart|the process of partitioning and filesystem creation}}
|Author=Drobbins
</noinclude>
}}
===Vorbereiten der Festplatte ===
<tt>Keychain</tt> helps you to manage SSH and GPG keys in a convenient and secure manner. It acts as a frontend to <tt>ssh-agent</tt> and <tt>ssh-add</tt>, but allows you to easily have one long running <tt>ssh-agent</tt> process per system, rather than the norm of one <tt>ssh-agent</tt> per login session.
 
Diese Sektion handelt über die verschiedenen Möglichkeiten Funtoo Linux auf einer Festplatte zu installieren und zu booten.
 
==== Einleitung ====
 
Früher gab es nur eine Variante einen PC zu booten, alle Desktop- und Servercomputer hatten einen voreingestellten PC  BIOS, alle Festplatten nutzten den Master Boot Record (MBR) um das System zu booten und unsere Festplatten waren  mit dem MBR Partitionsschema in verschiedene Regionen partitioniert. Das war einfach wie's gemacht wurde. Und uns gefiel es!
 
Dann kamen EFI und UEFI, neue firmware designt das System zu booten, gemeinsam mit GTP Partitionstabellen um Partitionen auf Festplatten größer als 2.2TB zu definieren.
Plötzlich haben wir eine breite Wahl von Optionen, Linux Systeme zu installieren und zu booten. Damit haben wir nun eine komplexere Situation als damals.
 
Nehmen wir einen Moment um die verfügbaren Optionen, zur Konfiguration der Festplatte um Linux zu booten, zu besprechen.
Diese Installationsanleitung nutzt und empfiehlt die old-school Methode des BIOS bootens mit hilfe des MBR. Es funktioniert und (außer in seltenen Fällen) ist universal unterstützt.
Mit dieser Methode ist nichts falsch, solange deine Systemfestplatte nur bis zu 2TB groß ist. Solange wird diese Methode die volle Kapazität deiner Festplatte nutzen.
 
Es gibt aber einige Situationen, in denen diese old-school Methode nicht optimal ist. Falls du eine Systemfestplatte >2TB hast, dann erlauben dir MBR Partitionen keinen Zugang zum gesamten Speicher.
Das ist also ein Grund gegen diese Methode. Ein Weiterer ist, dass es "PC" Systeme gibt, welche das booten via BIOS nicht mehr unterstützen und dich zwingen via UEFI zu booten.
Aus Mitleid für die PC-Nutzer, die in diese Zwickmühle geraten, decken wir das Booten via UEFI zusätzlich in dieser Installationsanleitung ab .
 
Unsere empfehlung ist immer noch die old-school Methode, es seiden du hast Gründe dagegen.
Der Bootloader, den wir nutzen um den Linux Kernel zu laden, heißt GRUB. Also nennen wir die Methode  '''BIOS + GRUB(MBR) ''' Methode.
Es ist die traditionelle Methode um ein Linux System bootbar zu machen.
 
Falls du via UEFI booten willst, empfehlen wir dir nicht den MBR zum booten zu nutzen, was nur manche Systeme unterstützen, sondern wir empfehlen UEFI zu nutzen um GRUB zu laden.
GRUB wird dann das Linux System booten. Wir referenzieren zu dieser Methode mit '''UEFI + GRUB (GPT)'''.
 
Und ja, es gibt noch weitere Methoden, von denen einige auf der [[Boot Methods]] Seite dokumentiert sind.
Unsere Empfehlung war immer die  '''BIOS + GRUB (GPT)'' Methode, welche allerdings nun nicht mehr konsistent und hardwareübergreifend unterstützt wird.  


This dramatically reduces the number of times you need to enter your passphrase. With <tt>keychain</tt>, you only need to enter a passphrase once every time your local machine is rebooted. <tt>Keychain</tt> also makes it easy for remote cron jobs to securely &quot;hook in&quot; to a long running <tt>ssh-agent</tt> process, allowing your scripts to take advantage of key-based logins.
'''Die größte Frage ist immer -- Welche Bootmethode sollst du nutzen?''' Hier ist mein Gedankengang.


== Download and Resources ==
;Grundsatz 1 - Old School: Falls du verlässlich via System Rescue CD booten kannst und dir ein leicht blaues Menü angezeigt wird, dann bootet die CD via BIOS und es ist sehr wahrscheinlich, das du auch Funtoo Linux via BIOS booten kannst. Also gehe old-school und nutze diese Methode, es sei denn du hast Gründe via UEFI zu booten. Zum Beispiel eine Systemfestplatte >2.2TB  In diesem Fall beachte Grundsatz 2, wenn dein System UEFI unterstützt.


The latest release of keychain is version <tt>2.7.2_beta1</tt>, and was released on July 7, 2014. The current version of keychain supports <tt>gpg-agent</tt> as well as <tt>ssh-agent</tt>.
;Grundsatz 2 - New School: Falls du verlässlich via System Rescue CD booten kannst und dir ein schwarz und weißes Menü, --Glückwunsch, dein System ist konfiguriert UEFI zu unterstützen. Das bedeutet das du bereit bist Funtoo Linux einzurichten um via UEFI zu booten. Dein System könnte immer noch das Booten übers BIOS unterstützen, aber versuch es einfach mal mit UEFI als erstes. Du kannst in deiner BIOS Konfiguration herum stochern und damit spielen.  


Keychain is compatible with many operating systems, including <tt>AIX</tt>, <tt>*BSD</tt>, <tt>Cygwin</tt>, <tt>MacOS X</tt>, <tt>Linux</tt>, <tt>HP/UX</tt>, <tt>Tru64 UNIX</tt>, <tt>IRIX</tt>, <tt>Solaris</tt> and <tt>GNU Hurd</tt>.
;Was ist der große Unterschied zwischen Old School und New School?: Hier ist der Deal. Falls du mit old-school MBR Partitionen gehst, deine <code>/boot</code> Partition wird ein ext2 Dateisystem haben, und du wirst <code>fdisk</code>nutzen um MBR Partitionen zu erstellen. Fallse du mit new-school GPT Partitionen und booten via UEFI gehst, wird deine <code>/boot</code> Partition ein  vfat Dateisystem haben, da UEFI dies lesen kann,außerdem wirst du <code>gdisk</code> nutzen um GPT Partitionen zu erstellen. Und du wirst GRUB ein wenig anders installieren. Das ist alles was es zu wissen gibt, für den Fall das du neugierig warst.


=== Download ===
;Also Note: To install Funtoo Linux to boot via the New School UEFI method, you must boot System Rescue CD using UEFI -- and see an initial black and white screen. Otherwise, UEFI will not be active and you will not be able to set it up!


* ''Release Archive''
{{Note|'''Einige motherboards unterstützen UEFI nicht richtig.''' Informiere dich. Zum Beispiel, das Award BIOS in meinem Gigabyte GA-990FXA-UD7 rev 1.1 hat eine Option das Booten via UEFI für CD/DVD zu aktivieren. '''Das ist aber nicht ausreichend um UEFI für Festplatten zu nutzen und Funtoo Linux zu installieren.''' UEFI muss für entfernbare Datenträger und fixierte Datenträger unterstützt werden. (Damit du deine neue Funtoo Installation booten kannst) Tatsächlich hagen die neueren revisionen des boards(rev 3.0) volle UEFI unterstützung. Das ist der wichtigste Punkt des dritten Grundsatzes -- kenne die Hardware. }}
** [http://www.funtoo.org/distfiles/keychain/keychain-2.7.2_beta1.tar.bz2 keychain 2.7.2_beta1]
** [http://www.funtoo.org/distfiles/keychain/keychain-2.7.1.tar.bz2 keychain 2.7.1]


* ''Apple MacOS X Packages''
==== Old-School (BIOS/MBR) Method ====
** [http://www.funtoo.org/distfiles/keychain/keychain-2.7.1-macosx.tar.gz keychain 2.7.1 MacOS X package]


Keychain development sources can be found in the [http://www.github.com/funtoo/keychain keychain git repository]. Please use the [https://bugs.funtoo.org Funtoo Linux bug tracker] and [irc://irc.freenode.net/funtoo #funtoo irc channel] for keychain support questions as well as bug reports.
{{Note|Use this method if you are booting using your BIOS, and if your System Rescue CD initial boot menu was light blue. If you're going to use the new-school method, [[#New-School (UEFI/GPT) Method|click here to jump down to UEFI/GPT.]]}}


=== Project History ===
===== Preparation =====


Daniel Robbins originally wrote <tt>keychain</tt> 1.0 through 2.0.3. 1.0 was written around June 2001, and 2.0.3 was released in late August, 2002.
First, it's a good idea to make sure that you've found the correct hard disk to partition. Try this command and verify that <code>/dev/sda</code> is the disk that you want to partition:


After 2.0.3, <tt>keychain</tt> was maintained by various Gentoo developers, including Seth Chandler, Mike Frysinger and Robin H. Johnson, through July 3, 2003.
<console>
# ##i##fdisk -l /dev/sda


On April 21, 2004, Aron Griffis committed a major rewrite of <tt>keychain</tt> which was released as 2.2.0. Aron continued to actively maintain and improve <tt>keychain</tt> through October 2006 and the <tt>keychain</tt> 2.6.8 release. He also made a few commits after that date, up through mid-July, 2007. At this point, <tt>keychain</tt> had reached a point of maturity.
Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


In mid-July, 2009, Daniel Robbins migrated Aron's mercurial repository to git and set up a new project page on funtoo.org, and made a few bug fix commits to the git repo that had been collecting in [http://bugs.gentoo.org bugs.gentoo.org]. Daniel continues to maintain <tt>keychain</tt> and supporting documentation on funtoo.org, and plans to make regular maintenance releases of <tt>keychain</tt> as needed.


== Quick Setup ==
#        Start          End    Size  Type            Name
1        2048  1250263694  596.2G  Linux filesyste Linux filesystem
</console>


=== Linux ===
Now, it's recommended that you erase any existing MBR or GPT partition tables on the disk, which could confuse the system's BIOS at boot time. We do this using <code>sgdisk</code>:
{{fancywarning|This will make any existing partitions inaccessible! You are '''strongly''' cautioned and advised to backup any critical data before proceeding.}}


To install under Gentoo or Funtoo Linux, type
<console>
<console>
###i## emerge keychain
# ##i##sgdisk --zap-all /dev/sda
 
Creating new GPT entries.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
</console>
</console>


For other Linux distributions, use your distribution's package manager, or download and install using the source tarball above. Then generate RSA/DSA keys if necessary. The quick install docs assume you have a DSA key pair named <tt>id_dsa</tt> and <tt>id_dsa.pub</tt> in your <tt>~/.ssh/</tt> directory. Add the following to your <tt>~/.bash_profile</tt>:
This output is also nothing to worry about, as the command still succeded:


{{file|name=~/.bash_profile|body=
<console>
eval `keychain --eval --agents ssh id_rsa`
***************************************************************
}}
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory.
***************************************************************
</console>
 
===== Partitioning =====
 
Now we will use <code>fdisk</code> to create the MBR partition table and partitions:
 
<console>
# ##i##fdisk /dev/sda
</console>


If you want to take advantage of GPG functionality, ensure that GNU Privacy Guard is installed and omit the <tt>--agents ssh</tt> option above.
Within <code>fdisk</code>, follow these steps:


=== Apple MacOS X ===
'''Empty the partition table''':


To install under MacOS X, install the MacOS X package for keychain. Assuming you have an <tt>id_dsa</tt> and <tt>id_dsa.pub</tt> key pair in your <tt>~/.ssh/</tt> directory, add the following to your <tt>~/.bash_profile</tt>:
<console>
Command (m for help): ##i##o ↵
</console>


{{file|name=~/.bash_profile|body=
'''Create Partition 1''' (boot):
eval `keychain --eval --agents ssh --inherit any id_dsa`
}}


{{Fancynote|The <tt>--inherit any</tt> option above causes keychain to inherit any ssh key passphrases stored in your Apple MacOS Keychain. If you would prefer for this to not happen, then this option can be omitted.}}
<console>
Command (m for help): ##i##n ↵
Partition type (default p): ##i##↵
Partition number (1-4, default 1): ##i##↵
First sector: ##i##↵
Last sector: ##i##+128M ↵
</console>


== Background ==
'''Create Partition 2''' (swap):


You're probably familiar with <tt>ssh</tt>, which has become a secure replacement for the venerable <tt>telnet</tt> and <tt>rsh</tt> commands.
<console>
Command (m for help): ##i##n ↵
Partition type (default p): ##i##↵
Partition number (2-4, default 2): ##i##↵
First sector: ##i##↵
Last sector: ##i##+2G ↵
Command (m for help): ##i##t ↵
Partition number (1,2, default 2): ##i## ↵
Hex code (type L to list all codes): ##i##82 ↵
</console>


Typically, when one uses <tt>ssh</tt> to connect to a remote system, one supplies a secret passphrase to <tt>ssh</tt>, which is then passed in encrypted form over the network to the remote server. This passphrase is used by the remote <tt>sshd</tt> server to determine if you should be granted access to the system.
'''Create the root partition:'''


However, OpenSSH and nearly all other SSH clients and servers have the ability to perform another type of authentication, called asymmetric public key authentication, using the RSA or DSA authentication algorithms. They are very useful, but can also be complicated to use. <tt>keychain</tt> has been designed to make it easy to take advantage of the benefits of RSA and DSA authentication.
<console>
Command (m for help): ##i##n ↵
Partition type (default p): ##i##↵
Partition number (3,4, default 3): ##i##↵
First sector: ##i##↵
Last sector: ##i##↵
</console>


== Generating a Key Pair ==
'''Verify the partition table:'''


To use RSA and DSA authentication, first you use a program called <tt>ssh-keygen</tt> (included with OpenSSH) to generate a ''key pair'' -- two small files. One of the files is the ''public key''. The other small file contains the ''private key''. <tt>ssh-keygen</tt> will ask you for a passphrase, and this passphrase will be used to encrypt your private key. You will need to supply this passphrase to use your private key. If you wanted to generate a DSA key pair, you would do this:
<console>
Command (m for help): ##i##p


<console># ##i##ssh-keygen -t dsa
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Generating public/private dsa key pair.</console>
Units: sectors of 1 * 512 = 512 bytes
You would then be prompted for a location to store your key pair. If you do not have one currently stored in <tt>~/.ssh</tt>, it is fine to accept the default location:
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x82abc9a6


<console>Enter file in which to save the key (/root/.ssh/id_dsa): </console>
Device    Boot    Start      End    Blocks  Id System
Then, you are prompted for a passphrase. This passphrase is used to encrypt the ''private key'' on disk, so even if it is stolen, it will be difficult for someone else to use it to successfully authenticate as you with any accounts that have been configured to recognize your public key.
/dev/sda1          2048    264191    131072  83 Linux
/dev/sda2        264192  4458495  2097152  82 Linux swap / Solaris
/dev/sda3        4458496 625142447 310341976  83 Linux
</console>


Note that conversely, if you '''do not''' provide a passphrase for your private key file, then your private key file '''will not''' be encrypted. This means that if someone steals your private key file, ''they will have the full ability to authenticate with any remote accounts that are set up with your public key.''
'''Write the parition table to disk:'''


Below, I have supplied a passphrase so that my private key file will be encrypted on disk:
<console>
Command (m for help): ##i##w
</console>


<console>Enter passphrase (empty for no passphrase): ##i#########
Your new MBR partition table will now be written to your system disk.
Enter same passphrase again: ##i#########
Your identification has been saved in /var/tmp/id_dsa.
Your public key has been saved in /var/tmp/id_dsa.pub.
The key fingerprint is:
5c:13:ff:46:7d:b3:bf:0e:37:1e:5e:8c:7b:a3:88:f4 root@devbox-ve
The key's randomart image is:
+--[ DSA 1024]----+
|          .      |
|          o  . |
|          o . ..o|
|      . . . o  +|
|        S    o. |
|            . o.|
|        .  ..++|
|        . o . =o*|
|        . E .+*.|
+-----------------+</console>


== Setting up Authentication ==
{{Note|You're done with partitioning! Now, jump over to [[#Creating filesystems|Creating filesystems]].}}


Here's how you use these files to authenticate with a remote server. On the remote server, you would append the contents of your ''public key'' to the <tt>~.ssh/authorized_keys</tt> file, if such a file exists. If it doesn't exist, you can simply create a new <tt>authorized_keys</tt> file in the remote account's <tt>~/.ssh</tt> directory that contains the contents of your local <tt>id_dsa.pub</tt> file.
==== New-School (UEFI/GPT) Method ====


Then, if you weren't going to use <tt>keychain</tt>, you'd perform the following steps. On your local client, you would start a program called <tt>ssh-agent</tt>, which runs in the background. Then you would use a program called <tt>ssh-add</tt> to tell <tt>ssh-agent</tt> about your secret private key. Then, if you've set up your environment properly, the next time you run <tt>ssh</tt>, it will find <tt>ssh-agent</tt> running, grab the private key that you added to <tt>ssh-agent</tt> using <tt>ssh-add</tt>, and use this key to authenticate with the remote server.
{{Note|Use this method if you are booting using UEFI, and if your System Rescue CD initial boot menu was black and white. If it was light blue, this method will not work.}}


Again, the steps in the previous paragraph is what you'd do if <tt>keychain</tt> wasn't around to help. If you are using <tt>keychain</tt>, and I hope you are, you would simply add the following line to your <tt>~/.bash_profile</tt> or if a regular user to<tt>~/.bashrc</tt> :
The <tt>gdisk</tt> commands to create a GPT partition table are as follows. Adapt sizes as necessary, although these defaults will work for most users. Start <code>gdisk</code>:


{{file|name=~/.bash_profile|body=
<console>
eval `keychain --eval id_dsa`
# ##i##gdisk /dev/sda
}}
</console>
 
Within <tt>gdisk</tt>, follow these steps:
 
'''Create a new empty partition table''' (This ''will'' erase all data on the disk when saved):
 
<console>
Command: ##i##o ↵
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): ##i##y ↵
</console>
 
'''Create Partition 1''' (boot):
 
<console>
Command: ##i##n ↵
Partition Number: ##i##1 ↵
First sector: ##i##↵
Last sector: ##i##+500M ↵
Hex Code: ##i##↵
</console>


The next time you log in or source your <tt>~/.bash_profile</tt> or if you use <tt>~/.bashrc</tt>, <tt>keychain</tt> will start, start <tt>ssh-agent</tt> for you if it has not yet been started, use <tt>ssh-add</tt> to add your <tt>id_dsa</tt> private key file to <tt>ssh-agent</tt>, and set up your shell environment so that <tt>ssh</tt> will be able to find <tt>ssh-agent</tt>. If <tt>ssh-agent</tt> is already running, <tt>keychain</tt> will ensure that your <tt>id_dsa</tt> private key has been added to <tt>ssh-agent</tt> and then set up your environment so that <tt>ssh</tt> can find the already-running <tt>ssh-agent</tt>. It will look something like this:
'''Create Partition 2''' (swap):


Note that when <tt>keychain</tt> runs for the first time after your local system has booted, you will be prompted for a passphrase for your private key file if it is encrypted. But here's the nice thing about using <tt>keychain</tt> -- even if you are using an encrypted private key file, you will only need to enter your passphrase when your system first boots (or in the case of a server, when you first log in.) After that, <tt>ssh-agent</tt> is already running and has your decrypted private key cached in memory. So if you open a new shell, you will see something like this:
<console>
Command: ##i##n ↵
Partition Number: ##i##2 ↵
First sector: ##i##↵
Last sector: ##i##+4G ↵
Hex Code: ##i##8200 ↵
</console>


This means that you can now <tt>ssh</tt> to your heart's content, without supplying a passphrase.
'''Create Partition 3''' (root):


You can also execute batch <tt>cron</tt> jobs and scripts that need to use <tt>ssh</tt> or <tt>scp</tt>, and they can take advantage of passwordless RSA/DSA authentication as well. To do this, you would add the following line to the top of a bash script:
<console>
Command: ##i##n ↵
Partition Number: ##i##3 ↵
First sector: ##i##↵
Last sector: ##i##↵##!i## (for rest of disk)
Hex Code: ##i##↵
</console>


{{file|name=example-script.sh|body=
Along the way, you can type "<tt>p</tt>" and hit Enter to view your current partition table. If you make a mistake, you can type "<tt>d</tt>" to delete an existing partition that you created. When you are satisfied with your partition setup, type "<tt>w</tt>" to write your configuration to disk:
eval `keychain --noask --eval id_dsa` || exit 1
}}


The extra <tt>--noask</tt> option tells <tt>keychain</tt> that it should not prompt for a passphrase if one is needed. Since it is not running interactively, it is better for the script to fail if the decrypted private key isn't cached in memory via <tt>ssh-agent</tt>.
'''Write Partition Table To Disk''':


== Keychain Options ==
<console>
Command: ##i##w ↵
Do you want to proceed? (Y/N): ##i##Y ↵
</console>


=== Specifying Agents ===
The partition table will now be written to disk and <tt>gdisk</tt> will close.


In the images above, you will note that <tt>keychain</tt> starts <tt>ssh-agent</tt>, but also starts <tt>gpg-agent</tt>. Modern versions of <tt>keychain</tt> also support caching decrypted GPG keys via use of <tt>gpg-agent</tt>, and will start <tt>gpg-agent</tt> by default if it is available on your system. To avoid this behavior and only start <tt>ssh-agent</tt>, modify your <tt>~/.bash_profile</tt> as follows:
Now, your GPT/GUID partitions have been created, and will show up as the following ''block devices'' under Linux:


{{file|name=~/.bash_profile|body=
* <tt>/dev/sda1</tt>, which will be used to hold the <tt>/boot</tt> filesystem,
eval `keychain --agents ssh --eval id_dsa` || exit 1
* <tt>/dev/sda2</tt>, which will be used for swap space, and
}}
* <tt>/dev/sda3</tt>, which will hold your root filesystem.


The additional <tt>--agents ssh</tt> option tells <tt>keychain</tt> just to manage <tt>ssh-agent</tt>, and ignore <tt>gpg-agent</tt> even if it is available.
==== Creating filesystems ====


=== Clearing Keys ===
{{Note|This section covers both BIOS ''and'' UEFI installs. Don't skip it!}}


Sometimes, it might be necessary to flush all cached keys in memory. To do this, type:
Before your newly-created partitions can be used, the block devices need to be initialized with filesystem ''metadata''. This process is known as ''creating a filesystem'' on the block devices. After filesystems are created on the block devices, they can be mounted and used to store files.


<console># ##i##keychain --clear</console>
Let's keep this simple. Are you using old-school MBR partitions? If so, let's create an ext2 filesystem on /dev/sda1:
Any agent(s) will continue to run.


=== Improving Security ===
<console>
# ##i##mkfs.ext2 /dev/sda1
</console>


To improve the security of <tt>keychain</tt>, some people add the <tt>--clear</tt> option to their <tt>~/.bash_profile</tt> <tt>keychain</tt> invocation. The rationale behind this is that any user logging in should be assumed to be an intruder until proven otherwise. This means that you will need to re-enter any passphrases when you log in, but cron jobs will still be able to run when you log out.
If you're using new-school GPT partitions for UEFI, you'll want to create a vfat filesystem on /dev/sda1, because this is what UEFI is able to read:


=== Stopping Agents ===
<console>
# ##i##mkfs.vfat -F 32 /dev/sda1
</console>


If you want to stop all agents, which will also of course cause your keys/identities to be flushed from memory, you can do this as follows:
Now, let's create a swap partition. This partition will be used as disk-based virtual memory for your Funtoo Linux system.


<console># ##i##keychain -k all</console>
You will not create a filesystem on your swap partition, since it is not used to store files. But it is necessary to initialize it using the <code>mkswap</code> command. Then we'll run the <code>swapon</code> command to make your newly-initialized swap space immediately active within the live CD environment, in case it is needed during the rest of the install process:
If you have other agents running under your user account, you can also tell <tt>keychain</tt> to just stop only the agents that <tt>keychain</tt> started:


<console># ##i##keychain -k mine</console>
<console>
# ##i##mkswap /dev/sda2
# ##i##swapon /dev/sda2
</console>


=== GPG ===
Now, we need to create a root filesystem. This is where Funtoo Linux will live. We generally recommend ext4 or XFS root filesystems. If you're not sure, choose ext4. Here's how to create a root ext4 filesystem:


Keychain can ask you for your GPG passphrase if you provide it the GPG key ID. To find it out:
<console>
<console>
$##i## gpg -k
# ##i##mkfs.ext4 /dev/sda3
pub  2048R/DEADBEEF 2012-08-16
uid                  Name (Comment) <email@host.tld>
sub  2048R/86D2FAC6 2012-08-16
</console>
</console>


Note the '''DEADBEEF''' above is the ID. Then, in your login script, do your usual
...and here's how to create an XFS root filesystem, if you choose to use XFS:


<console>
<console>
$##i## keychain --dir ~/.ssh/.keychain ~/.ssh/id_rsa DEADBEEF
# ##i##mkfs.xfs /dev/sda3
$##i## source ~/.ssh/.keychain/$HOST-sh
$##i## source ~/.ssh/.keychain/$HOST-sh-gpg
</console>
</console>


=== Learning More ===
Your filesystems (and swap) have all now been initialized, so that that can be mounted (attached to your existing directory heirarchy) and used to store files. We are ready to begin installing Funtoo Linux on these brand-new filesystems.


The instructions above will work on any system that uses <tt>bash</tt> as its default shell, such as most Linux systems and Mac OS X.
{{fancywarning|1=
When deploying an OpenVZ host, please use ext4 exclusively. The Parallels development team tests extensively with ext4, and modern versions of <code>openvz-rhel6-stable</code> are '''not''' compatible with XFS, and you may experience kernel bugs.
}}


To learn more about the many things that <tt>keychain</tt> can do, including alternate shell support, consult the keychain man page, or type <tt>keychain --help | less</tt> for a full list of command options.
==== Mounting filesystems ====


I also recommend you read my original series of articles about [http://www.openssh.com OpenSSH] that I wrote for IBM developerWorks, called <tt>OpenSSH Key Management</tt>. Please note that <tt>keychain</tt> 1.0 was released along with Part 2 of this article, which was written in 2001. <tt>keychain</tt> has changed quite a bit since then. In other words, read these articles for the conceptual and [http://www.openssh.com OpenSSH] information, but consult the <tt>keychain</tt> man page for command-line options and usage instructions :)
Mount the newly-created filesystems as follows, creating <code>/mnt/funtoo</code> as the installation mount point:


* [http://www.ibm.com/developerworks/library/l-keyc.html Common Threads: OpenSSH key management, Part 1] - Understanding RSA/DSA Authentication
<console>
* [http://www.ibm.com/developerworks/library/l-keyc2/ Common Threads: OpenSSH key management, Part 2] - Introducing <tt>ssh-agent</tt> and <tt>keychain</tt>
# ##i##mkdir /mnt/funtoo
* [http://www.ibm.com/developerworks/library/l-keyc3/ Common Threads: OpenSSH key management, Part 3] - Agent forwarding and <tt>keychain</tt> improvements
# ##i##mount /dev/sda3 /mnt/funtoo
# ##i##mkdir /mnt/funtoo/boot
# ##i##mount /dev/sda1 /mnt/funtoo/boot
</console>
 
Optionally, if you have a separate filesystem for <code>/home</code> or anything else:
 
<console>
# ##i##mkdir /mnt/funtoo/home
# ##i##mount /dev/sda4 /mnt/funtoo/home
</console>


As mentioned at the top of the page, <tt>keychain</tt> development sources can be found in the [http://www.github.com/funtoo/keychain keychain git repository]. Please use the [http://groups.google.com/group/funtoo-dev funtoo-dev mailing list] and [irc://irc.freenode.net/funtoo #funtoo irc channel] for keychain support questions as well as bug reports.
If you have <code>/tmp</code> or <code>/var/tmp</code> on a separate filesystem, be sure to change the permissions of the mount point to be globally-writeable after mounting, as follows:


[[Category:HOWTO]]
<console>
[[Category:Projects]]
# ##i##chmod 1777 /mnt/funtoo/tmp
[[Category:First Steps]]
</console>
[[Category:Articles]]
{{ArticleFooter}}

Revision as of 17:17, January 27, 2015


   Note

This is a template that is used as part of the Installation instructions which covers: the process of partitioning and filesystem creation. Templates are being used to allow multiple variant install guides that use most of the same re-usable parts.


Vorbereiten der Festplatte

Diese Sektion handelt über die verschiedenen Möglichkeiten Funtoo Linux auf einer Festplatte zu installieren und zu booten.

Einleitung

Früher gab es nur eine Variante einen PC zu booten, alle Desktop- und Servercomputer hatten einen voreingestellten PC BIOS, alle Festplatten nutzten den Master Boot Record (MBR) um das System zu booten und unsere Festplatten waren mit dem MBR Partitionsschema in verschiedene Regionen partitioniert. Das war einfach wie's gemacht wurde. Und uns gefiel es!

Dann kamen EFI und UEFI, neue firmware designt das System zu booten, gemeinsam mit GTP Partitionstabellen um Partitionen auf Festplatten größer als 2.2TB zu definieren. Plötzlich haben wir eine breite Wahl von Optionen, Linux Systeme zu installieren und zu booten. Damit haben wir nun eine komplexere Situation als damals.

Nehmen wir einen Moment um die verfügbaren Optionen, zur Konfiguration der Festplatte um Linux zu booten, zu besprechen. Diese Installationsanleitung nutzt und empfiehlt die old-school Methode des BIOS bootens mit hilfe des MBR. Es funktioniert und (außer in seltenen Fällen) ist universal unterstützt. Mit dieser Methode ist nichts falsch, solange deine Systemfestplatte nur bis zu 2TB groß ist. Solange wird diese Methode die volle Kapazität deiner Festplatte nutzen.

Es gibt aber einige Situationen, in denen diese old-school Methode nicht optimal ist. Falls du eine Systemfestplatte >2TB hast, dann erlauben dir MBR Partitionen keinen Zugang zum gesamten Speicher. Das ist also ein Grund gegen diese Methode. Ein Weiterer ist, dass es "PC" Systeme gibt, welche das booten via BIOS nicht mehr unterstützen und dich zwingen via UEFI zu booten. Aus Mitleid für die PC-Nutzer, die in diese Zwickmühle geraten, decken wir das Booten via UEFI zusätzlich in dieser Installationsanleitung ab .

Unsere empfehlung ist immer noch die old-school Methode, es seiden du hast Gründe dagegen. Der Bootloader, den wir nutzen um den Linux Kernel zu laden, heißt GRUB. Also nennen wir die Methode BIOS + GRUB(MBR) Methode. Es ist die traditionelle Methode um ein Linux System bootbar zu machen.

Falls du via UEFI booten willst, empfehlen wir dir nicht den MBR zum booten zu nutzen, was nur manche Systeme unterstützen, sondern wir empfehlen UEFI zu nutzen um GRUB zu laden. GRUB wird dann das Linux System booten. Wir referenzieren zu dieser Methode mit UEFI + GRUB (GPT).

Und ja, es gibt noch weitere Methoden, von denen einige auf der Boot Methods Seite dokumentiert sind. Unsere Empfehlung war immer die 'BIOS + GRUB (GPT) Methode, welche allerdings nun nicht mehr konsistent und hardwareübergreifend unterstützt wird.

Die größte Frage ist immer -- Welche Bootmethode sollst du nutzen? Hier ist mein Gedankengang.

Grundsatz 1 - Old School
Falls du verlässlich via System Rescue CD booten kannst und dir ein leicht blaues Menü angezeigt wird, dann bootet die CD via BIOS und es ist sehr wahrscheinlich, das du auch Funtoo Linux via BIOS booten kannst. Also gehe old-school und nutze diese Methode, es sei denn du hast Gründe via UEFI zu booten. Zum Beispiel eine Systemfestplatte >2.2TB In diesem Fall beachte Grundsatz 2, wenn dein System UEFI unterstützt.
Grundsatz 2 - New School
Falls du verlässlich via System Rescue CD booten kannst und dir ein schwarz und weißes Menü, --Glückwunsch, dein System ist konfiguriert UEFI zu unterstützen. Das bedeutet das du bereit bist Funtoo Linux einzurichten um via UEFI zu booten. Dein System könnte immer noch das Booten übers BIOS unterstützen, aber versuch es einfach mal mit UEFI als erstes. Du kannst in deiner BIOS Konfiguration herum stochern und damit spielen.
Was ist der große Unterschied zwischen Old School und New School?
Hier ist der Deal. Falls du mit old-school MBR Partitionen gehst, deine /boot Partition wird ein ext2 Dateisystem haben, und du wirst fdisknutzen um MBR Partitionen zu erstellen. Fallse du mit new-school GPT Partitionen und booten via UEFI gehst, wird deine /boot Partition ein vfat Dateisystem haben, da UEFI dies lesen kann,außerdem wirst du gdisk nutzen um GPT Partitionen zu erstellen. Und du wirst GRUB ein wenig anders installieren. Das ist alles was es zu wissen gibt, für den Fall das du neugierig warst.
Also Note
To install Funtoo Linux to boot via the New School UEFI method, you must boot System Rescue CD using UEFI -- and see an initial black and white screen. Otherwise, UEFI will not be active and you will not be able to set it up!
   Note

Einige motherboards unterstützen UEFI nicht richtig. Informiere dich. Zum Beispiel, das Award BIOS in meinem Gigabyte GA-990FXA-UD7 rev 1.1 hat eine Option das Booten via UEFI für CD/DVD zu aktivieren. Das ist aber nicht ausreichend um UEFI für Festplatten zu nutzen und Funtoo Linux zu installieren. UEFI muss für entfernbare Datenträger und fixierte Datenträger unterstützt werden. (Damit du deine neue Funtoo Installation booten kannst) Tatsächlich hagen die neueren revisionen des boards(rev 3.0) volle UEFI unterstützung. Das ist der wichtigste Punkt des dritten Grundsatzes -- kenne die Hardware.

Old-School (BIOS/MBR) Method

   Note

Use this method if you are booting using your BIOS, and if your System Rescue CD initial boot menu was light blue. If you're going to use the new-school method, click here to jump down to UEFI/GPT.

Preparation

First, it's a good idea to make sure that you've found the correct hard disk to partition. Try this command and verify that /dev/sda is the disk that you want to partition:

root # fdisk -l /dev/sda

Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


root #         Start          End    Size  Type            Name
 1         2048   1250263694  596.2G  Linux filesyste Linux filesystem

Now, it's recommended that you erase any existing MBR or GPT partition tables on the disk, which could confuse the system's BIOS at boot time. We do this using sgdisk:

   Warning

This will make any existing partitions inaccessible! You are strongly cautioned and advised to backup any critical data before proceeding.

root # sgdisk --zap-all /dev/sda

Creating new GPT entries.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.

This output is also nothing to worry about, as the command still succeded:

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 
***************************************************************
Partitioning

Now we will use fdisk to create the MBR partition table and partitions:

root # fdisk /dev/sda

Within fdisk, follow these steps:

Empty the partition table:

Command (m for help): o ↵

Create Partition 1 (boot):

Command (m for help): n ↵
Partition type (default p): 
Partition number (1-4, default 1): 
First sector: 
Last sector: +128M ↵

Create Partition 2 (swap):

Command (m for help): n ↵
Partition type (default p): 
Partition number (2-4, default 2): 
First sector: 
Last sector: +2G ↵
Command (m for help): t ↵ 
Partition number (1,2, default 2): 
Hex code (type L to list all codes): 82 ↵

Create the root partition:

Command (m for help): n ↵
Partition type (default p): 
Partition number (3,4, default 3): 
First sector: 
Last sector: 

Verify the partition table:

Command (m for help): p

Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x82abc9a6

Device    Boot     Start       End    Blocks  Id System
/dev/sda1           2048    264191    131072  83 Linux
/dev/sda2         264192   4458495   2097152  82 Linux swap / Solaris
/dev/sda3        4458496 625142447 310341976  83 Linux

Write the parition table to disk:

Command (m for help): w

Your new MBR partition table will now be written to your system disk.

   Note

You're done with partitioning! Now, jump over to Creating filesystems.

New-School (UEFI/GPT) Method

   Note

Use this method if you are booting using UEFI, and if your System Rescue CD initial boot menu was black and white. If it was light blue, this method will not work.

The gdisk commands to create a GPT partition table are as follows. Adapt sizes as necessary, although these defaults will work for most users. Start gdisk:

root # gdisk /dev/sda

Within gdisk, follow these steps:

Create a new empty partition table (This will erase all data on the disk when saved):

Command: o ↵
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y ↵

Create Partition 1 (boot):

Command: n ↵
Partition Number: 1 ↵
First sector: 
Last sector: +500M ↵
Hex Code: 

Create Partition 2 (swap):

Command: n ↵
Partition Number: 2 ↵
First sector: 
Last sector: +4G ↵
Hex Code: 8200 ↵

Create Partition 3 (root):

Command: n ↵
Partition Number: 3 ↵
First sector: 
Last sector:  (for rest of disk)
Hex Code: 

Along the way, you can type "p" and hit Enter to view your current partition table. If you make a mistake, you can type "d" to delete an existing partition that you created. When you are satisfied with your partition setup, type "w" to write your configuration to disk:

Write Partition Table To Disk:

Command: w ↵
Do you want to proceed? (Y/N): Y ↵

The partition table will now be written to disk and gdisk will close.

Now, your GPT/GUID partitions have been created, and will show up as the following block devices under Linux:

  • /dev/sda1, which will be used to hold the /boot filesystem,
  • /dev/sda2, which will be used for swap space, and
  • /dev/sda3, which will hold your root filesystem.

Creating filesystems

   Note

This section covers both BIOS and UEFI installs. Don't skip it!

Before your newly-created partitions can be used, the block devices need to be initialized with filesystem metadata. This process is known as creating a filesystem on the block devices. After filesystems are created on the block devices, they can be mounted and used to store files.

Let's keep this simple. Are you using old-school MBR partitions? If so, let's create an ext2 filesystem on /dev/sda1:

root # mkfs.ext2 /dev/sda1

If you're using new-school GPT partitions for UEFI, you'll want to create a vfat filesystem on /dev/sda1, because this is what UEFI is able to read:

root # mkfs.vfat -F 32 /dev/sda1

Now, let's create a swap partition. This partition will be used as disk-based virtual memory for your Funtoo Linux system.

You will not create a filesystem on your swap partition, since it is not used to store files. But it is necessary to initialize it using the mkswap command. Then we'll run the swapon command to make your newly-initialized swap space immediately active within the live CD environment, in case it is needed during the rest of the install process:

root # mkswap /dev/sda2
root # swapon /dev/sda2

Now, we need to create a root filesystem. This is where Funtoo Linux will live. We generally recommend ext4 or XFS root filesystems. If you're not sure, choose ext4. Here's how to create a root ext4 filesystem:

root # mkfs.ext4 /dev/sda3

...and here's how to create an XFS root filesystem, if you choose to use XFS:

root # mkfs.xfs /dev/sda3

Your filesystems (and swap) have all now been initialized, so that that can be mounted (attached to your existing directory heirarchy) and used to store files. We are ready to begin installing Funtoo Linux on these brand-new filesystems.

   Warning

When deploying an OpenVZ host, please use ext4 exclusively. The Parallels development team tests extensively with ext4, and modern versions of openvz-rhel6-stable are not compatible with XFS, and you may experience kernel bugs.

Mounting filesystems

Mount the newly-created filesystems as follows, creating /mnt/funtoo as the installation mount point:

root # mkdir /mnt/funtoo
root # mount /dev/sda3 /mnt/funtoo
root # mkdir /mnt/funtoo/boot
root # mount /dev/sda1 /mnt/funtoo/boot

Optionally, if you have a separate filesystem for /home or anything else:

root # mkdir /mnt/funtoo/home
root # mount /dev/sda4 /mnt/funtoo/home

If you have /tmp or /var/tmp on a separate filesystem, be sure to change the permissions of the mount point to be globally-writeable after mounting, as follows:

root # chmod 1777 /mnt/funtoo/tmp