Difference between pages "UEFI Install Guide" and "Virtual Packages"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
(two first cases for virtuals)
 
Line 1: Line 1:
{{Note|This material has been integrated into the main [[Funtoo Linux Installation]] guide, so please look at that guide if you are installing Funtoo Linux. Editors: this page still contains some good content that we might want to move over there.}}
Virtual packages are special packages that correspond to a feature that can be satisfied by one or more package(s). This Wiki page aims to describe when and how to use them correctly, and what are their implications.


This tutorial will show you how to install Funtoo on a UEFI system. UEFI, also known as the [[Wikipedia:Unified Extensible Firmware Interface|Unified Extensible Firmware Interface]], is a new firmware interface that is used on some newer computers as a replacement for the traditional PC BIOS. It has an integrated boot loader, so setting up booting is different.  
== Virtual packages, metapackages and package sets ==
Virtual packages, metapackages and package sets are similar concepts. However, they have a few important differences that make them fit for different use cases.


This tutorial is meant to be an "overlay" over the Regular Funtoo Installation. Follow the normal installation and only follow steps in this tutorial when dealing with partitioning and configuring the boot loader (GRUB). All steps are otherwise identical to the regular installation process.
Virtual packages and metapackages are regular Funtoo packages (ebuilds) that install no files. Instead, they cause other packages to be installed by specifying them in their runtime dependencies. They can both be used in any context valid for regular packages. They can have multiple versions, slots and USE flags. They have to be located in an active repository, and once there they can be installed and uninstalled like regular packages.


== What Are We Doing? ==
Package sets are not packages but special atoms supported by Portage. Package sets can only specify other packages, either via a static list or dynamically (e.g. via running Python code that determines the package list). Package sets can't be versioned and don't have USE flags. Package sets can be used alongside packages in emerge commands and other package sets but they can't be referenced inside regular packages. Package sets can be installed into user's system, located in repositories or created by user in Portage configuration.


This guide will show you how to set up your UEFI system to load the GRUB boot loader, which will then load your Funtoo Linux kernel and initramfs. This is the "UEFI + GRUB" method as described on the [[Boot Methods]] page.
Virtual packages represent a commonly used feature that can be provided by multiple different providers. Virtuals provide a convenient way of specifying all possible alternatives without having to update multiple ebuilds.


== First Steps ==
Metapackages and package sets are used to represent lists of packages that user may want to install together. They provide a convenience for users, e.g. providing a shortcut to install all packages comprising a desktop environment.


To install Funtoo Linux on a UEFI system, first you need to boot SysRescueCD in UEFI mode. To do this, enable UEFI in your BIOS, and if necessary disable legacy booting. After some fiddling, you should be able to boot SysRescueCD and get a black and white text menu instead of the traditional aqua/cyan-colored menu. The black and white menu indicates that you booted SysRescueCD in UEFI mode. Once you've accomplished this, you're ready to continue with your Funtoo Linux installation and partition your drive. See below for details.
== When virtual packages can be used? ==
For virtual package ebuild to work correctly, the two following requirements must be met:
# the virtual providers must be interchangeable at runtime with no consequences to the reverse dependencies. In other words, installing another provider and removing the currently used provider must not cause any breakage or require reverse dependencies to be rebuilt.
# Reverse dependencies need to have consistent, predictable requirements for the alternatives. In other words, the packages must not require a very specific versions of the alternatives.


{{fancynote|If the <tt>/sys/firmware/efi</tt> directory exists, then you have successfully booted in EFI mode and will be able to configure your Funtoo system to boot in EFI mode. If the directory doesn't exist, fix this first. It is a requirement for setting up EFI booting.}}
Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.


== Partitioning ==
== Common uses for virtual packages ==
=== System components and services ===
Example: ''virtual/service-manager''


To set up your partitions for UEFI booting, you will create a ~500MB FAT32 partition on <tt>/dev/sda1</tt>, and set it to type <tt>EF00</tt> using <tt>gdisk</tt>.  
One of the common uses for virtuals is to define abstract ''system services''. Those virtuals are not very specific on how those services are provided. They are mostly intended to be used in the @system package set, to ensure that the user system doesn't lack key components such as a service manager or a package manager.


<console>
The providers for this kind of virtuals do not have to meet any specific requirements except for having a particular function. In particular, there's no requirement for common configuration or provided executables. The user is responsible for ensuring that the installed implementation is set up and working.
Command: ##i##n ↵
Partition Number: ##i##1 ↵
First sector: ##i##↵
Last sector: ##i##+500M ↵
Hex Code: ##i##EF00
</console>


This partition will serve as your Funtoo <tt>/boot</tt> filesystem as well as the partition that the UEFI firmware can read to load GRUB. Then you will set up swap on <tt>/dev/sda2</tt> and your root filesystem on <tt>/dev/sda3</tt>. To create the FAT32 filesystem, type:
=== Tools provided by multiple packages ===
Example: ''virtual/eject''


<console>
This kind of virtuals is used when multiple packages may provide tools with the same names. The virtual is used in packages that rely on those tools being present, in particular when the tools are used at build-time of the package or are called by package's scripts (executables).
# ##i##mkfs.vfat -F 32 /dev/sda1
</console>


Your <tt>/etc/fstab</tt> entry for this filesystem will also differ, and will look like this:
While the tools don't necessarily need to be fully compatible, they need to have a common basic usage. In particular, when a tool from one provider is replaced by a tool from another, the reverse dependencies must remain in working state, with no need for rebuilds or configuration adjustments.
 
<pre>
/dev/sda1 /boot vfat noatime 1 2
</pre>
 
== Kernel ==
 
=== VFAT ===
 
Make sure you add VFAT support to your kernel if you are building it manually.
 
=== EFI Framebuffer ===
 
If you have the following option enabled in your kernel, then uvesafb and efifb will not be able to detect the framebuffer:
 
{{kernelop|title=Bus options (PCI etc.)|desc=
    [*] Mark VGA/VBE/EFI FB as generic system framebuffer (NEW)
}}
 
If you have that option enabled, ''you must also enable'':
 
{{kernelop|title=Device Drivers,Graphics support,Frame buffer Devices|desc=
    [*]  Simple framebuffer support
}}
 
This is the preferred method of using the EFI framebuffer, the efifb and uvesafb drivers will be used as a fallback if the above is not compatible.
=== Grub method ===
 
==== Unmask Grub 2.02_beta2 ====
 
Unmask the latest version of GRUB by placing this in your <code>/etc/portage/package.unmask</code>:
 
<pre>
sys-boot/grub
</pre>
 
The 2.00 version of GRUB has known issues with UEFI booting. Using 2.02 is essential for having this boot method work reliably.
 
==== 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 <tt>/etc/portage/make.conf</tt>:
 
<pre>
GRUB_PLATFORMS="efi-64"
</pre>
 
Then, <tt>emerge grub</tt>. You will notice <tt>efibootmgr</tt> getting pulled in as a dependency. This is expected and good.
 
==== 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 <tt>/boot</tt>. GRUB will boot those. But how do we get UEFI to boot GRUB? Well, we need to run the following command:
 
<console>
# ##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.
 
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.
 
==== 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 <code>/boot/grub/grub.cfg</code> to support UEFI booting.
 
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:
 
{{file|name=/etc/boot.conf|desc=|body=
boot {
        generate grub
        default "Funtoo Linux"
        timeout 3
}
 
"Funtoo Linux" {
        kernel vmlinuz[-v]
        params += rootfstype=ext4 root=/dev/sda2
}
}}
 
After you have edited your <code>/etc/boot.conf</code> file, run <code>boot-update</code>. If you check your <code>/boot/grub/grub.cfg</code> now, you should see something like this:
 
{{file|name=/boot/grub/grub.cfg|desc=|body=
set timeout=3
 
  insmod part_gpt
  insmod fat
  set root=(hostdisk//dev/sda,gpt1)
  search --no-floppy --fs-uuid --set 3CFD-6884
if loadfont /grub/unifont.pf2; then
  set gfxmode=text
  insmod gfxterm
  insmod vbe
  terminal_output gfxterm
fi
 
set menu_color_normal=cyan/blue
set menu_color_highlight=blue/cyan
 
menuentry "Funtoo Linux - vmlinuz-3.16.3" {
  insmod part_gpt
  insmod fat
  set root=(hostdisk//dev/sda,gpt1)
  search --no-floppy --fs-uuid --set 3CFD-6884
  linux /vmlinuz-3.16.3 video=uvesafb:1920x1080-32,mtrr:3,ywrap rootfstype=ext4 root=/dev/sda2
  set gfxpayload=text
}
set default=0
}}
 
To get your <code>/boot/grub/grub.cfg</code> to support booting with UEFI, make your <code>/boot/grub/grub.cfg</code> look like this:
{{file|name=/boot/grub/grub.cfg|desc=|body=
set timeout=3
 
  insmod part_gpt
  insmod fat
  insmod efi_gop
  insmod efi_uga
  set root=(hostdisk//dev/sda,gpt1)
  search --no-floppy --fs-uuid --set 3CFD-6884
if loadfont /grub/unifont.pf2; then
  set gfxmode=auto
  insmod gfxterm
  insmod vbe
  terminal_output gfxterm
fi
 
set menu_color_normal=cyan/blue
set menu_color_highlight=blue/cyan
 
menuentry "Funtoo Linux - vmlinuz-3.16.3" {
  insmod part_gpt
  insmod fat
  set root=(hostdisk//dev/sda,gpt1)
  search --no-floppy --fs-uuid --set 3CFD-6884
  linux /vmlinuz-3.16.3 video=uvesafb:1920x1080-32,mtrr:3,ywrap rootfstype=ext4 root=/dev/sda2
  set gfxpayload=keep
}
set default=0
}}
 
The lines that we have added and altered do the following:
* <code>insmod efi_gop</code> and <code>insmod efi_uga</code>: Both of these involve adding support for the UEFI framebuffer to GRUB.
* <code>set gfxmode=auto</code>: Instead of having the GRUB boot option screen being displayed at the smallest resolution possible, changing this to auto will make it fit the resolution of your display.
 
== Known Issues ==
*With pure UEFI boot mode, with legacy mode disabled, following error expected:
** video driver not supported, boot hangs, hard reboot required.
*Choose UEFI first, next legacy driver. It depends on motherboard vendor and efi bios version.
**In UEFI bios choose grub option, if your succeeded with above guide, additional menu should appear in Boot Menu, otherwise it boots into EFI shell: <code>grub:NAME of you hard drive</code>
* On some systems, installing the packages that are required for UEFI booting with any gcc later than a 4.x.x release may lead to a black screen after the GRUB screen. To fix this, before you begin installing any packages on your system, emerge =gcc-4.6.4-r2 and proceed with the installation as usual. Remember to switch your compiler back to the version of gcc that came with your system after you have finished installing. To do this, use <code>gcc-config 2</code>.
 
=== Done! ===
 
Remember to follow all other steps in the regular Funtoo Install Guide. Assuming you did everything correctly, your system should now boot via UEFI! We will be adding UEFI support to boot-update soon to make this process easier.
 
[[Category:HOWTO]]

Revision as of 13:31, February 7, 2015

Virtual packages are special packages that correspond to a feature that can be satisfied by one or more package(s). This Wiki page aims to describe when and how to use them correctly, and what are their implications.

Virtual packages, metapackages and package sets

Virtual packages, metapackages and package sets are similar concepts. However, they have a few important differences that make them fit for different use cases.

Virtual packages and metapackages are regular Funtoo packages (ebuilds) that install no files. Instead, they cause other packages to be installed by specifying them in their runtime dependencies. They can both be used in any context valid for regular packages. They can have multiple versions, slots and USE flags. They have to be located in an active repository, and once there they can be installed and uninstalled like regular packages.

Package sets are not packages but special atoms supported by Portage. Package sets can only specify other packages, either via a static list or dynamically (e.g. via running Python code that determines the package list). Package sets can't be versioned and don't have USE flags. Package sets can be used alongside packages in emerge commands and other package sets but they can't be referenced inside regular packages. Package sets can be installed into user's system, located in repositories or created by user in Portage configuration.

Virtual packages represent a commonly used feature that can be provided by multiple different providers. Virtuals provide a convenient way of specifying all possible alternatives without having to update multiple ebuilds.

Metapackages and package sets are used to represent lists of packages that user may want to install together. They provide a convenience for users, e.g. providing a shortcut to install all packages comprising a desktop environment.

When virtual packages can be used?

For virtual package ebuild to work correctly, the two following requirements must be met:

  1. the virtual providers must be interchangeable at runtime with no consequences to the reverse dependencies. In other words, installing another provider and removing the currently used provider must not cause any breakage or require reverse dependencies to be rebuilt.
  2. Reverse dependencies need to have consistent, predictable requirements for the alternatives. In other words, the packages must not require a very specific versions of the alternatives.

Virtuals can not be used if the underlying packages don't provide binary compatibility at least between predictable range of versions.

Common uses for virtual packages

System components and services

Example: virtual/service-manager

One of the common uses for virtuals is to define abstract system services. Those virtuals are not very specific on how those services are provided. They are mostly intended to be used in the @system package set, to ensure that the user system doesn't lack key components such as a service manager or a package manager.

The providers for this kind of virtuals do not have to meet any specific requirements except for having a particular function. In particular, there's no requirement for common configuration or provided executables. The user is responsible for ensuring that the installed implementation is set up and working.

Tools provided by multiple packages

Example: virtual/eject

This kind of virtuals is used when multiple packages may provide tools with the same names. The virtual is used in packages that rely on those tools being present, in particular when the tools are used at build-time of the package or are called by package's scripts (executables).

While the tools don't necessarily need to be fully compatible, they need to have a common basic usage. In particular, when a tool from one provider is replaced by a tool from another, the reverse dependencies must remain in working state, with no need for rebuilds or configuration adjustments.

Retrieved from "https://www.funtoo.org/index.php?title=UEFI_Install_Guide&oldid=8968"