|
|
| Line 1: |
Line 1: |
| == Introduction == | | {{News |
| | | |Summary=Funtoo is switching to an improved system for managing multiple OpenGL providers (Mesa/Xorg, AMD and nVidia). The update may involve blockers and file collisions. |
| GPT, which stands for GUID Partition Table, is a disk partitioning scheme that was introduced by Intel for Itanium architecture systems, as part of EFI, the Extensible Firmware Interface. While you are probably not using an Itanium architecture computer, and you are likely using a BIOS-based rather than an EFI-based system, you still may want to use GPT partitioning. Why? Because the standard MBR-based partitioning scheme only supports system disks that are less than 2TiB in size. On modern systems, especially systems with hardware RAID logical volumes, it is very easy to go beyond the 2TiB limit. GUID partition tables support disks that are larger than 2TiB in size.
| | |News Format=Extended |
| | | |News Category=Packages |
| === GPT Technology Overview === | | |Author=Mgorny |
| | | |Publication Status=Draft |
| This section contains a technical overview of GPT technology.
| | |Publication Date=2015/02/28 |
| | |
| GUID partition tables support up to 512 partitions. GPT data structures are stored in the first sectors of the drive with a secondary copy stored at the end of the drive. This allows the partitioning scheme of your disk to be recovered in situations where the primary partition table has been corrupted.
| |
| | |
| For compatibility with legacy partitioning tools, GPT partitioning tools typically rewrite the MBR partition table (generally located in the first sector of the disk) in a way those tools will interpret it like ''"This disk has only one partition (of an unknown type) covering the whole disk".''
| |
| | |
| It is possible to convert an existing MBR-partitioned disk to GPT format using the <tt>gdisk</tt> command. Please carefully read the <tt>gdisk</tt> man page before using this capability, as it is potentially dangerous, particularly if you are performing it on your boot disk.
| |
| | |
| {{ fancyimportant|Funtoo Linux fully supports GPT on x86-32bit and x86-64-bit systems. GPT is supported on SPARC systems, but currently only for non-boot disks.
| |
| }} | | }} |
| | == New OpenGL management == |
| | === System principles === |
| | The new OpenGL management design assumes that the reference OpenGL implementation (mesa/Xorg) is to be used to build packages. After switching to the new system, all packages will use the mesa/Xorg headers and link to the mesa/Xorg libraries. This improves portability of software built on Funtoo and solves some of the build failures when non-standard OpenGL provider was enabled. |
|
| |
|
| === Booting GPT ===
| | The third-party OpenGL libraries and modules provided by proprietary driver vendors can be enabled for run-time program use. They will not affect how the program is built. However, they will be loaded by the dynamic loader when starting executables. The Xorg server will also load the modules provided by blob driver vendor if appropriate. |
| | |
| If you decide to use a GPT-based partitioning scheme for your system disk, either out of necessity due to a 2TiB+ disk, or because you want to try GPT out, then the question arises -- how do you get the darn thing to boot? This is where the new <tt>GRUB</tt> boot loader comes in. The new <tt>GRUB</tt> (version 1.9x, found at <tt>sys-boot/grub</tt>) is a redesign of the original <tt>GRUB</tt> (version 0.9x, now called <tt>sys-boot/grub-legacy</tt> in Funtoo) boot-loader that includes very mature support for booting from GPT-based disks.
| |
| | |
| Now, let's take a look at how to get GPT-based booting working under Funtoo Linux.
| |
| | |
| == Getting Started ==
| |
| | |
| The first thing you'll need to do is to use a LiveCD. I recommend [http://www.sysresccd.org/Main_Page System Rescue CD] for this task as it is Gentoo-based and includes all the proper tools. Go ahead and boot the LiveCD, and then get to the point where you are ready to partition your system disk. | |
| | |
| At this point, you have two choices as to what partitioning tool to use. You can use either <tt>gdisk</tt> or <tt>parted</tt>. <tt>gdisk</tt> is a very nice <tt>fdisk</tt>-like partitioning tool that supports GPT partitioning. It is rather new software but seems to work quite well. The other tool you can use, GNU <tt>parted</tt>, has been around for a while and is more mature, but is harder to use.
| |
| | |
| We'll take a look at how to create partitions using <tt>gdisk</tt>. Alternatively, <code>cgdisk</code>, curses-based gdisk for users familiar with cfdisk or <code>sgdisk</code>, command-line tool can be used for creating and managing GPT partitions.
| |
| | |
| == Partitioning Using Gdisk ==
| |
| | |
| OK, the first step is using <tt>gdisk</tt> is to start it up, specifying the disk you want to modify:
| |
| | |
| <pre># gdisk /dev/sda</pre>
| |
| You should find <tt>gdisk</tt> very familiar to <tt>fdisk</tt>. Here is the partition table we want to end up with:
| |
| | |
| <pre>Command (? for help): p
| |
| Disk /dev/sda: 312581808 sectors, 149.1 GiB
| |
| Disk identifier (GUID): 17
| |
| Partition table holds up to 128 entries
| |
| First usable sector is 34, last usable sector is 312581774
| |
| Total free space is 0 sectors (0 bytes)
| |
| | |
| Number Start (sector) End (sector) Size Code Name
| |
| 1 34 204833 100.0 MiB 0700 Linux/Windows data
| |
| 2 204834 270369 512.0 kiB EF02 BIOS boot partition
| |
| 3 270370 1318945 512.0 MiB 8200 Linux swap
| |
| 4 1318946 312581774 148.4 GiB 0700 Linux/Windows data
| |
| | |
| Command (? for help): </pre>
| |
| Above, you'll see that we have a 100 MiB boot partition, a 512 kiB "BIOS boot partition", 512 MiB of swap, and the remaining disk used by a 148.4 GiB root partition.
| |
| | |
| The one new thing here is the "BIOS boot partition." What is it? In GRUB-speak, this BIOS boot partition is basically the location of the meat of GRUB's boot loading code - the quivalent of the <tt>stage1_5</tt> and <tt>stage2</tt> files in legacy GRUB. Since GPT-based partition tables have less "bonus" space than their MBR equivalents, and explicit partition of code <tt>EF02</tt> is required to hold the guts of the boot loader.
| |
| | |
| In all other respects, the partition table is similar to that of an MBR-based disk. We have a boot and root partition with code <tt>0700</tt>, and a Linux swap partition with code <tt>8200</tt>. One this partition table has been written to disk and appropriate <tt>mkfs</tt> and <tt>mkswap</tt> commands are issued, <tt>/dev/sda1</tt> will be used to hold <tt>/boot</tt>, <tt>/dev/sda2</tt> will be used by the new GRUB directly, <tt>/dev/sda3</tt> will house our swap and <tt>/dev/sda4</tt> will hold our root filesystem.
| |
| | |
| Go ahead and create filesystems on these partitions, and then mount the root and boot filesystems to <tt>/mnt/gentoo</tt> and <tt>/mnt/gentoo/boot</tt> respectively. Now go ahead and unpack a stage3 tarball to <tt>/mnt/gentoo</tt> and chroot in as you normally do.
| |
| | |
| == Configuring The Kernel ==
| |
| | |
| Your kernel will need a couple of extra GPT-related options enabled in order for it to make sense of your GPT partitions and find your filesystems. These options can be found under <tt>Enable the block layer ---> Partition Types</tt>:
| |
| | |
| <pre>[*] Advanced Partition Selection (PARTITION_ADVANCED)
| |
| [*] EFI GUID Partition Support (EFI_PARTITION)</pre>
| |
| If you are using a non-Funtoo distribution then you may need to append a proper <tt>rootfstype=</tt> option to your kernel boot options to allow Linux to properly mount the root filesystem when <tt>Advanced Partition Selection</tt> is enabled. [[Boot-Update]] does this for you automatically.
| |
| | |
| Now just go ahead and compile and install your kernel, and copy it to <tt>/boot/bzImage</tt>.
| |
| | |
| == Booting The System ==
| |
| | |
| To get the system booted, you will want to first edit <tt>/etc/fstab</tt> inside the chroot so that it reflects the partitions and filesystems you just created. Then, emerge <tt>boot-update</tt> version 1.4_beta2 or later:
| |
| | |
| <pre># emerge boot-update</pre>
| |
| [[Boot-Update]] is a front-end for the GRUB 1.9x boot loader and provides a necessary simplified configuration interface. <tt>boot-update</tt> is used to generate boot loader configuration files. But before we get to <tt>boot-update</tt>, we first need to install GRUB to your hard disk. This is done as follows:
| |
| | |
| <pre># grub-install /dev/sda</pre>
| |
| <tt>grub-install</tt> will detect and use <tt>/dev/sda2</tt> and use it to store its boot loader logic.
| |
| | |
| Now it's time to create an <tt>/etc/boot.conf</tt> file. For more information on all available options, consult the [[Boot-Update]] guide -- I'll show you a sample configuration for the sample GPT partition scheme above:
| |
| | |
| <pre>boot {
| |
| generate grub
| |
| default bzImage
| |
| }
| |
| | |
| "Funtoo Linux" {
| |
| kernel bzImage
| |
| }</pre>
| |
| Once <tt>/etc/boot.conf</tt> has been created, then type:
| |
|
| |
|
| <pre># boot-update</pre>
| | === Implementation === |
| This will auto-generate a <tt>/boot/grub/grub.cfg</tt> file for you, and you will now be able to reboot into Funtoo Linux using a GPT partitioning scheme.
| | The reference implementation (mesa/Xorg) packages install headers and libraries into standard system locations (/usr/include, /usr/lib*). The compiler and linker finds them using the usual rules and uses them. |
|
| |
|
| For more information on all the options available for <tt>/etc/boot.conf</tt>, please consult the [[Boot-Update]] guide.
| | The third-party OpenGL vendors install libraries and server extension modules into vendor-named subdirectories of /usr/lib*/opengl. Those files are not used directly. |
|
| |
|
| [[Category:Funtoo features]]
| | {{Package|app-admin/eselect-opengl}} is used to select OpenGL implementation used at run-time. The choice of implementation is controlled via dynamic linker configuration (ld.so.conf) and Xorg server configuration. If the reference implementation is selected, the eselect module outputs null configuration that causes the linker and server to use the standard paths. If an another implementation is selected, the configuration prepends /usr/lib*/opengl paths to linker and server configuration, causing them to prefer the third-party libraries over reference. |
| | {{NewsFooter}} |
