Difference between pages "Funtoo:About/pt-br" and "Install/BootLoader"

From Funtoo
< Funtoo:About(Difference between pages)
Jump to navigation Jump to search
m (Tocadotux moved page Funtoo:Pt-br-About to Funtoo:Funtoo:About/pt-br: Making as Paul advised me)
 
 
Line 1: Line 1:
= Visão do Projeto =
<noinclude>
{{InstallPart|boot loader configuration}}
</noinclude>
=== Installing a Bootloader ===


Daniel Robbins originalmente escreveu a [[ Gentoo Linux Philosophy|Filosofia Gentoo Linux]], e nisso definiu o conceito de uma ferramenta ideal assim sendo algo que "simplesmente funciona", não fica no caminho do usuário, e responde a vontade do usuário ao invés de forçar o usuário a trabalhar de um jeito particular.
These install instructions show you how to use GRUB to boot using BIOS (old-school) or UEFI (new-school).


Funtoo Linux é um projeto de pessoas que concordam filosofia da ferramenta ideal, e que são ''apaixonados'' pelo nosso desejo de melhorar a tecnologia de ser tão próximo desse ideial quanto possível. O foco de nossos esforços é o melhoramento contínuo da distribuição Gentoo Linux.
==== Old School (BIOS) ====


O foco do desenvolvimento do Funtoo Linux é atualmente direcionado ao sistema central (core system), significando qualquer coisa em um stage3, portage, core languages, kernels, aplicações de servidor, e em cima do X11 e gerenciadores de janelas simples, e incluindo ambientes desktop como o GNOME e o KDE.
If you're using the BIOS to boot, setting up GRUB, the bootloader, is pretty easy.


== Foco, Foco, Foco ==
To use this recommended boot method, first emerge <code>boot-update</code>. This will also cause <code>grub-2</code> to be merged, since it is a dependency of <code>boot-update</code>.


Desenvolvedores deveriam utilizar esses princípios gerais para determinar em quais prioridades focar primeiro. -Essas areas abaixo estão listadas em ordem de prioridade, então o próximo parágrafo é a principal prioridade (top priority), seguido pela próxima prioridade, etc. Só por que algo é prioridade mais baixa não significa que é "menos importante" - somente significa tratar as coisas de prioridades mais altas (higher-priority) antes.
<console>
(chroot) # ##i##emerge boot-update
</console>


=== Ele controe (Does it Build)? ===
Then, edit <code>/etc/boot.conf</code> and specify "<code>Funtoo Linux genkernel</code>" as the <code>default</code> setting at the top of the file, replacing <code>"Funtoo Linux"</code>.


* '''Ele constrói confiavelmente?'''
<code>/etc/boot.conf</code> should now look like this:


O primeiro teste - o software constrói a partir do código fonte corretamente? Isso não se trata somente de emergir ebuilds no seu sistema -- O builds do stage funciona sem problemas utilizando o Metro? Se não, isso precisa ser corrigido primeiro. O Funtoo Linux continuamente constrói lançamentos de do sistema operacional atualizados, e essa devem ser construídas confiavelmente em todos os momentos. O fóco aqui é para builds 100% corretos e eficientes utilizando o Metro, e depois emergindo aplicações iniciais em um sistema Funtoo Linux.
<pre>
boot {
generate grub
default "Funtoo Linux genkernel"
timeout 3
}


=== Ele executa (Does It Run)? ===
"Funtoo Linux" {
kernel bzImage[-v]
}


* '''Ele executa bem?'''
"Funtoo Linux genkernel" {
kernel kernel[-v]
initrd initramfs[-v]
params += real_root=auto
}


OK, ele constrói. Ele executa corretamente? Ele funciona? Isso é bem vago, então vamos colocar algumas especificações aqui. Quando instalar o Funtoo Linux a partir do stage3, tudo funciona? Quais complicações ou falhas foram  encontradas na instalação inicial? Essas devem ser corrigidas, ou soluções devem ser colocadas no lugar, e correções a longo prazo devem ser trabalhadas para melhorar a experiência do usuário. Lembre-se de que o foco do Funtoo Linux é no sistema central - Essa é a coisa que você toca quando você instala o Funtoo Linux pela primeira vez. Você deve reinstalar o Funtoo Linux regularmente para verificar por quaisquer questões e priorizar as questões de instalação do usuário e a experiência inicial do usuário.
"Funtoo Linux better-initramfs" {
kernel vmlinuz[-v]
initrd /initramfs.cpio.gz
}
</pre>


=== Posso Usá-lo (Can I Use It)? ===
Please read <code>man boot.conf</code> for further details.


* '''Facilmente (Easily)?'''
===== Running grub-install and boot-update =====
* '''Para Trabalho de Verdade (For Real Work)?'''


OK, ele constrói, e executa. Mas eu posso realizar tarefas de verdade com a ferramenta? Qual é a facilidade ou dificuldade  de realizar essas tarefas? A tecnologia (e documentação) devem ser projetadas oferecer suporte ao usuário na questão de realizar estas tarefas, ao invés de forçar o usuário a saltar por arcos obter algo configurado corretamente. As coisas devem ser automatizadas o tanto o quanto possível sem assumir controle distante do usuário. Razoável, padrões seguros que são adequados para a cargas produtivas devem ser utilizadas por todas as aplicações. As coisas devem emergir sem bloqueadores ou ausência de recursos que devem ser habilitadas manualmente pelo usuário. E uma implicância - se o emerge parar de dizer ao usuário que eles devem definir uma variável USE para que continue, isso é algo que deve ser corrigido de um jeito ou de outro. Então, quando tudo é dito e feito, ele deve funcionar.
Finally, we will need to actually install the GRUB boot loader to your disk, and also run <code>boot-update</code> which will generate your boot loader configuration file:


=== Is It Documented? ===
<console>
(chroot) # ##i##grub-install --no-floppy /dev/sda
(chroot) # ##i##boot-update
</console>


* '''For free software projects, documentation is key.'''
Now you need to update your boot loader configuration file:
<console>
(chroot) # ##i##boot-update
</console>
You only need to run <code>grub-install</code> when you first install Funtoo Linux, but you need to re-run <code>boot-update</code> every time you modify your <code>/etc/boot.conf</code> file, so your changes are applied on next boot.


If software builds, runs and works, others still may not be able to use it until proper documentation is available. Upstream documentation isn't always complete or easy to understand, so often additional user documentation is required. If manual steps are required, they should be documented clearly and correctly. The documentation option of choice is the Funtoo wiki as well as man pages.
==== New School (UEFI) ====


For source code, verbose comments should be used. You may be working on the code now, but someone else might be working on it six months from now. Developers are expected to write clear comments that are sufficiently non-technical and provide the necessary context to allow less experienced developers to understand critical parts of code, and ideally '''all''' parts of the code. Please see [[Coding Standards]].
If you're using UEFI to boot, setting up the boot loader is a bit more complicated for now, but this process will be improving soon. Perform the following steps.


=== Is It Well-Designed? ===
===== Emerging GRUB =====


* '''Optimized?'''
You will still use GRUB as a boot loader, but before emerging grub, you will need to enable EFI booting. To do this,
* '''Maintainable?'''
add the following line to <code>/etc/make.conf</code>:


It builds and runs, and I can use it to perform real work. But is the system well-designed? Does it work reliably? Are all available patches and fixes in place to ensure a reliable computing experience? Is Funtoo Linux providing the best technology possible to users? And is this technology easy to maintain? Remember, all things being equal, less code is better than more code because it is easier to maintain. Are there verbose comments in code where necessary?
<pre>


=== Are We Getting Better? ===
For 64-bit systems:


OK, we're doing all of the above steps. Here is the next test - are we getting better? Is the quality, security, usability and maintainability of the distribution improving over time, or is it going up, and then going down, and we're not really making any forward progress? The ultimate goal at the end of the day is to make forward progress in the quality of the distribution. This requires better automation, better tools, better processes, and investment in research and development and new ways of doing things. It also requires the right attitude. If we are doing a lot of work and the overall quality of the distribution is not improving, then our efforts are not making a long-term difference, even though they may be addressing immediate bugs and issues. We must ensure that our efforts are worthwhile, and they are making a positive long-term difference in the quality of the distribution.
GRUB_PLATFORMS="efi-64"


=== What is The Real Problem? ===
For 32-bit systems, i.e. Intel Atom devices:


Building on this theme - when a bug is encountered, what is the ''real'' problem, or ''root cause''? Strategic thinking as well as in-depth troubleshooting is required to identify the root cause of a problem. Should we just fix root causes? No, this is impractical, because doing this takes a lot of time. Instead, workarounds are often used to quickly restore quality to acceptable levels. However, just implementing workarounds is dangerous, because bugs tend to multiply while the underlying issue goes unresolved. The proper solution is to implement workarounds but to not lose focus on the need to address the underlying issues, or root causes, of the problem. In fact, much of the focus of Funtoo Linux is on this last step - aggressively fixing a bunch of immediate issues so we can start to address the deeper problems once and for all...
GRUB_PLATFORMS="efi-32"


=== Architecture ===
</pre>


...and addressing root causes of problems often requires a significant change in software architecture. Funtoo Linux is a project that is not afraid of making significant, even aggressive, architectural changes in order to fix problems. This is what our users expect us to do, and ''as long as these changes are properly tested, managed, planned, automated and communicated to users'', they will not get upset. As stated in the previous paragraph, the Funtoo Linux project is zealous about addressing these core architectural issues -- but we need to get a handle on the more fundamental challenges first. Once workarounds are in place, we'll take a stab at some core system change that will pay dividends well into the future.
Then, <code>emerge boot-update</code>. You will notice <code>grub</code> and <code>efibootmgr</code> getting pulled in as dependencies. This is expected and good:


== Examples ==
<console>
(chroot) # ##i##emerge boot-update
</console>


Below, you will find examples of existing efforts that have aligned with these goals. This section will give you a feel for how real projects can be started that align with the Funtoo Linux vision defined above.
===== Installing GRUB =====


=== Boot-Update ===
Now, for the magic of getting everything in place for booting. You should copy your kernel and initramfs (if you have one -- you will if you are following the default install) to <tt>/boot</tt>. GRUB will boot those. But how do we get UEFI to boot GRUB? Well, we need to run the following command (for 32bit simply set it as efi-32):


[[Boot-Update]] was designed by Daniel Robbins to provide a more elegant way to configure boot loaders under Funtoo Linux. This project was prioritized for several reasons. For one, it had to do with the initial installation experience (see [[#Does it Run?]]) Also, lack of GRUB2 support, as well as GPT/GUID support, was identified as a critical weakness in current Gentoo Linux functionality (see [[#Is it Well-Designed?]]) Because of this, a new unified configurator was written which uses <tt>/etc/boot.conf</tt> as the global boot loader configuration file. This represented a change in boot loader architecture (see [[#Architecture]]) under Funtoo Linux, in order to improve usability and flexibilty over existing solutions, and to attempt to reduce or eliminate a class of problems related to boot loader configuration, which is especially troublesome with GRUB2.
<console>
(chroot) # ##i##grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id="Funtoo Linux [GRUB]" --recheck /dev/sda
</console>
This command will simply install all the stuff to <tt>/boot/EFI</tt> and <tt>/boot/grub</tt> that your system needs to boot. In particular, the <tt>/boot/EFI/grub/grubx64.efi</tt> file will be created. This is the GRUB boot image that UEFI will load and start.


=== Metro ===
A more detailed explanation of the flags used in the above command:
* <code>--target=x86_64-efi</code>: Tells GRUB that we want to install it in a way that allows it to boot in UEFI
* <code>--efi-directory=/boot</code>: All GRUB UEFI files will be installed in ''/boot''
* <code>--bootloader-id="Funtoo Linux [GRUB]"</code>: This flag is not necessary for GRUB to boot. However, it allows you to change the text of the boot option in the UEFI BIOS. The stuff in the quotes can be set to anything that you would like.
* <code>--recheck</code>: If a device map already exists on the disk or partition that GRUB is being installed on, it will be removed.
* <code>/dev/sda</code>:The device that we are installing GRUB on.


[[Metro]] was designed by Daniel Robbins and is used to address the "[[#Does It Build?]]" question. The existing solution, catalyst, was difficult to maintain (see [[#Is It Well-Designed?]]), so Metro was developed to provide a new mechanism for building OS releases.
===== Configuring GRUB =====


=== Forked Ebuilds ===
OK, now UEFI has the GRUB image it needs to boot. But we still need to configure GRUB itself so it finds and boots your kernel and initramfs. This is done by performing the following steps. Since boot-update doesn't yet support UEFI, we will use boot-update, but then edit our <code>/boot/grub/grub.cfg</code> to support UEFI booting.


Not all improvements involve large software development efforts. In fact, the majority of fixes involve relatively small fixes to ebuilds. These fixes are often made to fix a Metro build failure (see [[#Does it Build?]]) or address some quality issue (see [[#Is It Well-Designed?]]). The <tt>www-servers/nginx</tt> ebuild was improved to provide better default settings for production systems, with corresponding changes made to <tt>sys-libs/pam</tt> to allow this to work. <tt>dev-lang/python</tt> contains fixes to ensure that Metro builds complete properly and a valid <tt>/usr/bin/python</tt> symlink always exists.
First, you will need to edit <code>/etc/boot.conf</code>. Format this as you would if you were booting without UEFI. If you are not sure how this should look, below is an example of what it could look like if you are booting from an unencrypted ext4 partition:


=== OpenVZ ===
{{file|name=/etc/boot.conf|desc=|body=
boot {
        generate grub
        default "Funtoo Linux"
        timeout 3
}


OpenVZ support is a specific priority of Funtoo Linux. Funtoo Linux maintains a patched <tt>sys-cluster/vzctl</tt> with various patches to fix a variety of problems. In addition, <tt>openvz-rhel6-stable</tt> and <tt>openvz-rhel5-stable</tt> ebuilds have been created to ease installation of production-quality OpenVZ kernels (see [[#Can I Use It?]]) In addition, [[OpenVZ]] documentation exists on the wiki (see [[#Can I Use It?]])
"Funtoo Linux" {
        kernel vmlinuz[-v]
        params += rootfstype=ext4 root=/dev/sda2
}
}}


[[Category:QA]]
After you have edited your <code>/etc/boot.conf</code> file, run <code>boot-update</code>. You should now have a <code>/boot/grub/grub.cfg</code> file, which you can edit using the following command:
 
<console>
# ##i##nano /boot/grub/grub.cfg
</console>
 
 
To get your <code>/boot/grub/grub.cfg</code> to support booting with UEFI, make the following changes. Below the existing insmod lines, add the following lines.  Both of these involve adding support for the UEFI framebuffer to GRUB.:
 
<pre>
  insmod efi_gop
  insmod efi_uga
</pre>
 
Then, change the <code>set gfxpayload</code> line to read as follows. UEFI does not support text mode, so we will keep video initialized to the current resolution.:
 
<pre>
  set gfxpayload=keep
</pre>
 
You can now save your changes by pressing <code>Control-X</code> and answering <code>y</code> when asked if you want to save the modified buffer. When prompted for a filename, hit Enter to use the existing filename.

Revision as of 07:26, January 1, 2015


   Note

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


Installing a Bootloader

These install instructions show you how to use GRUB to boot using BIOS (old-school) or UEFI (new-school).

Old School (BIOS)

If you're using the BIOS to boot, setting up GRUB, the bootloader, is pretty easy.

To use this recommended boot method, first emerge boot-update. This will also cause grub-2 to be merged, since it is a dependency of boot-update.

(chroot) # emerge boot-update

Then, edit /etc/boot.conf and specify "Funtoo Linux genkernel" as the default setting at the top of the file, replacing "Funtoo Linux".

/etc/boot.conf should now look like this:

boot {
	generate grub
	default "Funtoo Linux genkernel" 
	timeout 3 
}

"Funtoo Linux" {
	kernel bzImage[-v]
}

"Funtoo Linux genkernel" {
	kernel kernel[-v]
	initrd initramfs[-v]
	params += real_root=auto 
} 

"Funtoo Linux better-initramfs" {
	kernel vmlinuz[-v]
	initrd /initramfs.cpio.gz
}

Please read man boot.conf for further details.

Running grub-install and boot-update

Finally, we will need to actually install the GRUB boot loader to your disk, and also run boot-update which will generate your boot loader configuration file:

(chroot) # grub-install --no-floppy /dev/sda
(chroot) # boot-update

Now you need to update your boot loader configuration file:

(chroot) # boot-update

You only need to run grub-install when you first install Funtoo Linux, but you need to re-run boot-update every time you modify your /etc/boot.conf file, so your changes are applied on next boot.

New School (UEFI)

If you're using UEFI to boot, setting up the boot loader is a bit more complicated for now, but this process will be improving soon. Perform the following steps.

Emerging GRUB

You will still use GRUB as a boot loader, but before emerging grub, you will need to enable EFI booting. To do this, add the following line to /etc/make.conf:


For 64-bit systems:

GRUB_PLATFORMS="efi-64"

For 32-bit systems, i.e. Intel Atom devices:

GRUB_PLATFORMS="efi-32"

Then, emerge boot-update. You will notice grub and efibootmgr getting pulled in as dependencies. This is expected and good:

(chroot) # emerge boot-update
Installing GRUB

Now, for the magic of getting everything in place for booting. You should copy your kernel and initramfs (if you have one -- you will if you are following the default install) to /boot. GRUB will boot those. But how do we get UEFI to boot GRUB? Well, we need to run the following command (for 32bit simply set it as efi-32):

(chroot) # grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id="Funtoo Linux [GRUB]" --recheck /dev/sda

This command will simply install all the stuff to /boot/EFI and /boot/grub that your system needs to boot. In particular, the /boot/EFI/grub/grubx64.efi file will be created. This is the GRUB boot image that UEFI will load and start.

A more detailed explanation of the flags used in the above command:

  • --target=x86_64-efi: Tells GRUB that we want to install it in a way that allows it to boot in UEFI
  • --efi-directory=/boot: All GRUB UEFI files will be installed in /boot
  • --bootloader-id="Funtoo Linux [GRUB]": This flag is not necessary for GRUB to boot. However, it allows you to change the text of the boot option in the UEFI BIOS. The stuff in the quotes can be set to anything that you would like.
  • --recheck: If a device map already exists on the disk or partition that GRUB is being installed on, it will be removed.
  • /dev/sda:The device that we are installing GRUB on.
Configuring GRUB

OK, now UEFI has the GRUB image it needs to boot. But we still need to configure GRUB itself so it finds and boots your kernel and initramfs. This is done by performing the following steps. Since boot-update doesn't yet support UEFI, we will use boot-update, but then edit our /boot/grub/grub.cfg to support UEFI booting.

First, you will need to edit /etc/boot.conf. Format this as you would if you were booting without UEFI. If you are not sure how this should look, below is an example of what it could look like if you are booting from an unencrypted ext4 partition:

   /etc/boot.conf
boot {
        generate grub
        default "Funtoo Linux"
        timeout 3
}

"Funtoo Linux" {
        kernel vmlinuz[-v]
        params += rootfstype=ext4 root=/dev/sda2
}

After you have edited your /etc/boot.conf file, run boot-update. You should now have a /boot/grub/grub.cfg file, which you can edit using the following command:

root # nano /boot/grub/grub.cfg


To get your /boot/grub/grub.cfg to support booting with UEFI, make the following changes. Below the existing insmod lines, add the following lines. Both of these involve adding support for the UEFI framebuffer to GRUB.:

  insmod efi_gop
  insmod efi_uga

Then, change the set gfxpayload line to read as follows. UEFI does not support text mode, so we will keep video initialized to the current resolution.:

  set gfxpayload=keep

You can now save your changes by pressing Control-X and answering y when asked if you want to save the modified buffer. When prompted for a filename, hit Enter to use the existing filename.