Difference between pages "Funtoo Filesystem Guide, Part 3" and "GUID Booting Guide"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
{{Article
|Subtitle=Tmpfs and Bind Mounts
|Author=Drobbins
|Previous in Series=Funtoo Filesystem Guide, Part 2
|Next in Series=Funtoo Filesystem Guide, Part 4
}}
== Introduction ==
== Introduction ==
In my previous articles in this series, I introduced the benefits of journaling and the ReiserFS and showed how to set up a rock-solid ReiserFS system. In this article, we're going to tackle a couple of semi-offbeat topics. First, we'll take a look at tmpfs, also known as the virtual memory (VM) filesystem. Tmpfs is probably the best RAM disk-like system available for Linux right now, and was introduced with Linux kernel 2.4. Then, we'll take a look at another capability introduced with Linux kernel 2.4 called "bind mounts", which allow a great deal of flexibilit
y when it comes to mounting (and remounting) filesystems.


== Introducing Tmpfs ==
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.
If I had to explain tmpfs in one breath, I'd say that tmpfs is like a ramdisk, but different. Like a ramdisk, tmpfs can use your RAM, but it can also use your swap devices for storage. And while a traditional ramdisk is a block device and requires a mkfs command of some kind before you can actually use it, tmpfs is a filesystem, not a block device; you just mount it, and it's there.  
All in all, this makes tmpfs the niftiest RAM-based filesystem I've had the opportunity to meet.


== Tmpfs and VM ==
=== GPT Technology Overview ===
Let's take a look at some of tmpfs's more interesting properties. As I mentioned above, tmpfs can use both RAM and swap. This might seem a bit arbitrary at first, but remember that tmpfs is also known as the "virtual memory filesystem". And, as you probably know, the Linux kernel's virtual memory resources come from both your RAM and swap devices. The VM subsystem in the kernel allocates these resources to other parts of the system and takes care of managing these resources behind-the-scenes, often transparently moving RAM pages to swap and vice-versa.
The tmpfs filesystem requests pages from the VM subsystem to store files. tmpfs itself doesn't know whether these pages are on swap or in RAM; it's the VM subsystem's job to make those kinds of decisions. All the tmpfs filesystem knows is that it is using some form of virtual memory.


== Not a Block Device ==
This section contains a technical overview of GPT technology.
Here's another interesting property of the tmpfs filesystem. Unlike most "normal" filesystems, like ext3, ext2, XFS, JFS, ReiserFS and friends, tmpfs does not exist on top of an under
lying block device. Because tmpfs sits on top of VM directly, you can create a tmpfs filesystem with a simple mount command:


<pre># mount tmpfs /mnt/tmpfs -t tmpfs</pre>After executing this command, you'll have a new tmpfs filesystem mounted at /mnt/tmpfs, ready for use. Note that there's no need to run mkfs.tmpfs; in fact, it's impossible, as no such command exists. Immediately after the mount command, the filesystem is mounted and available for use, and is of type tmpfs. This is very different from how Linux ramdisks are used; standard Linux ramdisks are block devices, so they must be formatted with a filesystem of your choice before you can use them. In contrast, tmpfs is a filesystem. So, you can just mount it and go.
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.
}}


== Tmpfs Advantages ==
=== Booting GPT ===


=== Dynamic Filesystem Size ===
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.
You're probably wondering about how big that tmpfs filesystem was that we mounted at <tt>/mnt/tmpfs</tt>, above. The answer to that question is a bit unexpected, especially when compared to disk-based filesystems. <tt>/mnt/tmpfs</tt> will initially have a very small capacity, but as files are copied and created, the tmpfs filesystem driver will allocate more VM and will dynamically increase the filesystem capacity as needed. And, as files are removed from <tt>/mnt/tmpfs</tt>, the tmpfs filesystem driver will dynamically shrink the size of the filesystem and free VM resources, and by doing so return VM into circulation so that it can be used by other parts of the system as needed. Since VM is a precious resource, you don't want anything hogging more VM than it ac
tually needs, and the great thing about tmpfs is that this all happens automatically.


=== Speed ===
Now, let's take a look at how to get GPT-based booting working under Funtoo Linux.
The other major benefit of tmpfs is its blazing speed. Because a typical tmpfs filesystem will reside completely in RAM, reads and writes can be almost instantaneous. Even if some swap is used, performance is still excellent and those parts of the tmpfs filesystem will be moved to RAM as more free VM resources become available. Having the VM subsystem automatically move parts of the tmpfs filesystem to swap can actually be good for performance, since by doing so, the VM subsystem can free up RAM for processes that need it. This, along with its dynamic resizing abilities, allow for much better overall OS performance and flexibility than the alternative of using a traditional RAM disk.


=== No Persistence ===
== Getting Started ==


While this may not seem like a positive, tmpfs data is not preserved between reboots, because virtual memory is volatile in nature. I guess you probably figured that tmpfs was called &quot;tmpf
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.
s&quot; for a reason, didn't you? However, this can actually be a good thing. It makes tmpfs an excellent filesystem for holding data that you don't need to keep, such as temporary files (those found in <tt>/tmp</tt>) and parts of the <tt>/var</tt> filesystem tree.


== Using Tmpfs ==
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.


To use tmpfs, all you need is a modern (2.4+) kernel with <tt>Virtual memory file system support (former shm fs)</tt> enabled; this option lives under the <tt>File systems</tt> section of the kernel configuration options. Once you have a tmpfs-enabled kernel, you can go ahead and mount tmpfs filesystems. In fact, it's a good idea to enable tmpfs in all your kernels if you compile the
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.
m yourself - whether you plan to use tmpfs or not. This is because you need to have kernel tmpfs support in order to use POSIX shared memory. System V shared memory will work without tmpfs in y
our kernel, however. Note that you do not need a tmpfs filesystem to be mounted for POSIX shared memory to work; you simply need the support in your kernel. POSIX shared memory isn't used too much right now, but this situation will likely change as time goes on.


=== Avoiding low VM conditions ===
== Partitioning Using Gdisk ==


The fact that tmpfs dynamically grows and shrinks as needed makes one wonder: what happens when your tmpfs filesystem grows to the point where it exhausts all of your virtual memory, and you have no RAM or swap left? Well, generally, this kind of situation is a bit ugly. With kernel 2.4.4, the kernel would immediately lock up. With more recent kernels, the VM subsystem has in many ways been fixed, and while exhausting VM isn't exactly a wonderful experience, things don't blow up completely, either. When a modern kernel gets to the point where it can't allocate any more VM, you obviously won't be unable to write any new data to your tmpfs filesystem. In addition, it's likely that some other things will happen. First, the other processes on the system will be unable to allocate much more memory; generally, this means that the system will most likely become extremely sluggish and almost unresponsive. Thus, it may be tricky or unusually time-consuming for the superuser to take the necessary steps to alleviate this low-VM condition.
OK, the first step is using <tt>gdisk</tt> is to start it up, specifying the disk you want to modify:


In addition, the kernel has a built-in last-ditch system for freeing memory when no more is available; it'll find a process that's hogging VM resources and kill it. Unfortunately, this &quot;kill a process&quot; solution generally backfires when tmpfs growth is to blame for VM exhaustion. Here's the reason. Tmpfs itself can't (and shouldn't) be killed, since it is part of the kernel  and not a user process, and there's no easy way for the kernel to find out which process is filling up the tmpfs filesystem. So, the kernel mistakenly attacks the biggest VM-hog of a process it can find, which is generally your X server if you happen to be running one. So, your X server dies, and the root cause of the low-VM condition (tmpfs) isn't addressed. Ick.
<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:


=== Low VM: the solution ===
<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)


Fortunately, tmpfs allows you to specify a maximum upper bound for the filesystem size when a filesystem is mounted or remounted. Actually, as of kernel 2.4.6 and util-linux-2.11g, these parameters can only be set on mount, not on remount, but we can expect them to be settable on remount sometime in the near future. The optimal maximum tmpfs size setting depends on the resources and
Number  Start (sector)    End (sector)  Size      Code  Name
usage pattern of your particular Linux box; the idea is to prevent a completely full tmpfs filesystem from exhausting all virtual memory and thus causing the ugly low-VM conditions that we talked about earlier. A good way to find a good tmpfs upper-bound is to use top to monitor your system's swap usage during peak usage periods. Then, make sure that you specify a tmpfs upper-bound that's slightly less than the sum of all free swap and free RAM during these peak usage times.
  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


Creating a tmpfs filesystem with a maximum size is easy. To create a new tmpfs filesystem with a maximum filesystem size of 32 MB, type:
Command (? for help): </pre>
Above, you'll see that we have a 100 MiB boot partition, a 512 kiB &quot;BIOS boot partition&quot;, 512 MiB of swap, and the remaining disk used by a 148.4 GiB root partition.


<pre># mount tmpfs /dev/shm -t tmpfs -o size=32m</pre>
The one new thing here is the &quot;BIOS boot partition.&quot; 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 &quot;bonus&quot; space than their MBR equivalents, and explicit partition of code <tt>EF02</tt> is required to hold the guts of the boot loader.


This time, instead of mounting our new tmpfs filesystem at /mnt/tmpfs, we created it at /dev/shm, which is a directory that happens to be the &quot;official&quot; mount point for a tmpfs filesystem. If you happen to be using devfs, you'll find that this directory has already been created for you.
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.
Also, if we want to limit the filesystem size to 512 KB or 1 GB, we can specify size=512k and size=1g, respectively. In addition to limiting size, we can also limit the number of inodes (filesystem objects) by specifying the nr_inodes=x parameter. When using nr_inodes, x can be a simple integer, and can also be followed with a k, m, or g to specify thousands, millions, or billions (!) of inodes.


Also, if you'd like to add the equivalent of the above mount tmpfs command to your /etc/fstab, it'd look like this:
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.


<pre>tmpfs  /dev/shm    tmpfs  size=32m    0  0</pre>
== Configuring The Kernel ==


=== Mounting On Top of Existing Mount Points ===
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 ---&gt; Partition Types</tt>:
Back in the 2.2 days, any attempt to mount something to a mount point where something had already been mounted resulted in an error. However, thanks to a rewrite of the kernel mounting code, using mount points multiple times is not a problem. Here's an example scenario: let's say that we have an existing filesystem mounted at <tt>/tmp</tt>. However, we decide that we'd like to start
using tmpfs for <tt>/tmp</tt> storage. In the old days, your only option would be to unmount <tt>/tmp</tt> and remount your new tmpfs <tt>/tmp</tt> filesystem in its place, as follows:


<pre>#  umount /tmp
<pre>[*] Advanced Partition Selection (PARTITION_ADVANCED)
#  mount tmpfs /tmp -t tmpfs -o size=64m</pre>
[*] EFI GUID Partition Support (EFI_PARTITION)</pre>
However, this solution may not work for you. Maybe there are a number of running processes that have open files in <tt>/tmp</tt>; if so, when trying to unmount <tt>/tmp</tt>, you'd get the following error:
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.


<pre>umount: /tmp: device is busy</pre>
Now just go ahead and compile and install your kernel, and copy it to <tt>/boot/bzImage</tt>.
However, with Linux 2.4+, you can mount your new <tt>/tmp</tt> filesystem without getting the &quot;device is busy&quot; error:


<pre># mount tmpfs /tmp -t tmpfs -o size=64m</pre>
== Booting The System ==
With a single command, your new tmpfs <tt>/tmp</tt> filesystem is mounted at <tt>/tmp</tt>, on top of the already-mounted partition, which can no longer be directly accessed. However, while you can't get to the original <tt>/tmp</tt>, any processes that still have open files on this original filesystem can continue to access them. And, if you umount your tmpfs-based <tt>/tmp</tt>, your original mounted <tt>/tmp</tt> filesystem will reappear. In fact, you can mount any number of filesystems to the same mount point, and the mount point will act like a stack; unmount the current filesystem, and the last-most-recently mounted filesystem will reappear from underneath.


== Bind Mounts ==
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:


Using bind mounts, we can mount all, or even part of an already-mounted filesystem to another location, and have the filesystem accessible from both mount points at the same time! For example, you can use bind mounts to mount your existing root filesystem to <tt>/home/drobbins/nifty</tt>, as follows:
<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># mount --bind / /home/drobbins/nifty</pre>
<pre># grub-install /dev/sda</pre>
Now, if you look inside <tt>/home/drobbins/nifty</tt>, you'll see your root filesystem (<tt>/home/drobbins/nifty/etc</tt>, <tt>/home/drobbins/nifty/opt</tt>, etc.). And if you modify a file on your root filesystem, you'll see the modifications in <tt>/home/drobbins/nifty</tt> as well. This is because they are one and the same filesystem; the kernel is simply mapping the filesystem to two different mount points for us. Note that when you mount a filesystem somewhere else, any filesystems that were mounted to mount points inside the bind-mounted filesystem will not be moved along. In other words, if you have <tt>/usr</tt> on a separate filesystem, the bind mount we performed above will leave <tt>/home/drobbins/nifty/usr</tt> empty. You'll need an additional bind mount command to allow you to browse the contents of <tt>/usr</tt> at <tt>/home/drobbins/nifty/usr</tt>:
<tt>grub-install</tt> will detect and use <tt>/dev/sda2</tt> and use it to store its boot loader logic.


<pre>#  mount --bind /usr /home/drobbins/nifty/usr</pre>
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:
=== Bind mounting parts of filesystems ===


Bind mounting makes even more neat things possible. Let's say that you have a tmpfs filesystem mounted at <tt>/dev/shm</tt>, its traditional location, and you decide that you'd like to start using tmpfs for <tt>/tmp</tt>, which currently lives on your root filesystem. Rather than mounting a new tmpfs filesystem to <tt>/tmp</tt> (which is possible), you may decide that you'd like the new <tt>/tmp</tt> to share the currently mounted <tt>/dev/shm</tt> filesystem. However, while you could bind mount <tt>/dev/shm</tt> to <tt>/tmp</tt> and be done with it, your <tt>/dev/shm</tt> contains some directories that you don't want to appear in <tt>/tmp</tt>. So, what do you do? How about this:
<pre>boot {
        generate grub
        default bzImage
}


<pre># mkdir /dev/shm/tmp
&quot;Funtoo Linux&quot; {
# chmod 1777 /dev/shm/tmp
        kernel bzImage
# mount --bind /dev/shm/tmp /tmp</pre>
}</pre>
In this example, we first create a <tt>/dev/shm/tmp</tt> directory and then give it 1777 perms, the proper permissions for <tt>/tmp</tt>. Now that our directory is ready, we can mount <tt>/dev/shm/tmp</tt>, and only <tt>/dev/shm/tmp</tt> to <tt>/tmp</tt>. So, while <tt>/tmp/foo</tt> would map to <tt>/dev/shm/tmp/foo</tt>, there's no way for you to access the <tt>/dev/shm/bar</tt> file from <tt>/tmp</tt>.
Once <tt>/etc/boot.conf</tt> has been created, then type:


As you can see, bind mounts are extremely powerful and make it easy to make modifications to your filesystem layout without any fuss. Next article, we'll check out ext3.
<pre># boot-update</pre>
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.


== Resources ==
For more information on all the options available for <tt>/etc/boot.conf</tt>, please consult the [[Boot-Update]] guide.
Be sure to checkout the other articles in this series:
* [[Funtoo Filesystem Guide, Part 1|Part 1]]: Journaling and ReiserFS
* [[Funtoo Filesystem Guide, Part 2|Part 2]]: Using ReiserFS and Linux
* [[Funtoo Filesystem Guide, Part 3|Part 3]]: Tmpfs and bind mounts
* [[Funtoo Filesystem Guide, Part 4|Part 4]]: Introducing Ext3
* [[Funtoo Filesystem Guide, Part 5|Part 5]]: Ext3 in action


[[Category:Filesystem Guides]]
[[Category:Articles]]
[[Category:Articles]]
{{ArticleFooter}}

Revision as of 18:07, January 11, 2015

Introduction

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.

GPT Technology Overview

This section contains a technical overview of GPT technology.

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 gdisk command. Please carefully read the gdisk man page before using this capability, as it is potentially dangerous, particularly if you are performing it on your boot disk.

   Important

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.

Booting GPT

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 GRUB boot loader comes in. The new GRUB (version 1.9x, found at sys-boot/grub) is a redesign of the original GRUB (version 0.9x, now called sys-boot/grub-legacy 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 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 gdisk or parted. gdisk is a very nice fdisk-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 parted, 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 gdisk. Alternatively, cgdisk, curses-based gdisk for users familiar with cfdisk or sgdisk, command-line tool can be used for creating and managing GPT partitions.

Partitioning Using Gdisk

OK, the first step is using gdisk is to start it up, specifying the disk you want to modify: 

# gdisk /dev/sda

You should find gdisk very familiar to fdisk. Here is the partition table we want to end up with: 

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):

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 stage1_5 and stage2 files in legacy GRUB. Since GPT-based partition tables have less "bonus" space than their MBR equivalents, and explicit partition of code EF02 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 0700, and a Linux swap partition with code 8200. One this partition table has been written to disk and appropriate mkfs and mkswap commands are issued, /dev/sda1 will be used to hold /boot, /dev/sda2 will be used by the new GRUB directly, /dev/sda3 will house our swap and /dev/sda4 will hold our root filesystem.

Go ahead and create filesystems on these partitions, and then mount the root and boot filesystems to /mnt/gentoo and /mnt/gentoo/boot respectively. Now go ahead and unpack a stage3 tarball to /mnt/gentoo 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 Enable the block layer ---> Partition Types: 

[*] Advanced Partition Selection (PARTITION_ADVANCED)
[*] EFI GUID Partition Support (EFI_PARTITION)

If you are using a non-Funtoo distribution then you may need to append a proper rootfstype= option to your kernel boot options to allow Linux to properly mount the root filesystem when Advanced Partition Selection is enabled. Boot-Update does this for you automatically.

Now just go ahead and compile and install your kernel, and copy it to /boot/bzImage.

Booting The System

To get the system booted, you will want to first edit /etc/fstab inside the chroot so that it reflects the partitions and filesystems you just created. Then, emerge boot-update version 1.4_beta2 or later: 

# emerge boot-update

Boot-Update is a front-end for the GRUB 1.9x boot loader and provides a necessary simplified configuration interface. boot-update is used to generate boot loader configuration files. But before we get to boot-update, we first need to install GRUB to your hard disk. This is done as follows: 

# grub-install /dev/sda

grub-install will detect and use /dev/sda2 and use it to store its boot loader logic.

Now it's time to create an /etc/boot.conf 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: 

boot {
        generate grub
        default bzImage
}

"Funtoo Linux" {
        kernel bzImage
}

Once /etc/boot.conf has been created, then type: 

# boot-update

This will auto-generate a /boot/grub/grub.cfg file for you, and you will now be able to reboot into Funtoo Linux using a GPT partitioning scheme.

For more information on all the options available for /etc/boot.conf, please consult the Boot-Update guide.

Retrieved from "https://www.funtoo.org/index.php?title=Funtoo_Filesystem_Guide,_Part_3&oldid=8576"