Difference between pages "UEFI Install Guide" and "IPv4 calculations"

From Funtoo
(Difference between pages)
Jump to: navigation, search
(Configuring GRUB)
 
(The Internet layer)
 
Line 1: Line 1:
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.
+
WARNING: Work in progress. Do not edit this article unless you are the original author.
  
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.
 
  
== What Are We Doing? ==
+
= Refresh on TCP/IP model =  
  
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.
+
When the ARPANet (a packet oriented network) was born in those good old seventies, engineers had to solve the problem of making computers being able to exchange packets of information over the network and they invented in 1974 something you are now using to view this page: TCP/IP! TCP/IP is a collection of various network protocols, being organized as a stack. Just like your boss does not do everything in the company and delegates at lower levels which in turn delegates at an even more lower level, no protocol in the TCP/IP suite takes all responsibilities, they are working together in a hierarchical and cooperative manner.  A level of the TCP/IP stack knows what its immediate lower subordinate can do for it and whatever it will do will be done the right way and will not worry about the manner the job will be done. Also the only problem for a given level of the stack is to fulfill its own duties and deliver the service requested  by the upper layer, it does not have to worry about the ultimate goal of what upper levels do.  
 +
 
 +
<illustration goes here TCP/IP model>
  
== First Steps ==
+
The above illustration sounds horribly familiar : yes, it is sounds like this good old OSI model. Indeed it is a tailored view of the original OSI model and it works the exact same way: so the data sent by an application A1 (residing on computer C1) to another application A2 (residing on computer C2) goes through C1's TCP/IP stack (from top to bottom), reach the C1's lower layers that will take the responsibility to move the bits from C1 to C2 over a physical link (electrical or lights pulses, radio waves...sorry no quantum mechanism yet) . C2's lower layers will receive the bits sent by C1 and pass  what has been received to the C2's TCP/IP  stack (bottom to top) which will pass the data to A2. If C1 and C2 are not on the same network the process is a bit more complex because it involves relays (routers) but the global idea remains the same. Also there is no shortcuts in the process : both TCP/IP stacks are crossed in their whole, either from top to bottom for the sender or  bottom to top for the receiver. The transportation process in itself is also absolutely transparent from an application's point of view:  A1 knows it can rely on the TCP/IP stack to transmits some data to A2, ''how'' the data is transmitted is not its problem, A1 just assumes the data can be transmitted by some means. The TCP/IP stack is also loosely coupled to a particular network technology because its frontier is precisely the physical transportation of bits over a medium and so the physical network's technology,  just the same way A1 does not care about how the TCP/IP stack will move the data from one computer to another. The TCP/IP stack itself does not care about the details about how the bits are physically moved and thus it can work with any network technology no matter the technology is Ethernet, Token Ring or FDDI for example.
  
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.
+
= The Internet layer =
  
'''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.'''
+
The goal of this article being more focused on calculation of addresses used at the ''Internet layer'' so  let's forget the gory details of the TCP/IP stack works (you can find an extremely detailed discussion in [[How the TCP/IP stack works]]...  to be written...). From here, we assume you have a good general understanding of its functionalities and how a network transmission works. As you know the ''Internet'' layer is responsible to handle logical addressing issues of a TCP segment (or UDP datagram) that has either to be transmitted over the network or that has been received from the network.
  
== Partitioning ==
+
Who would ''ever'' need millions of addresses afterall?  So in theory with those 32 bits we can have around 4 billions of computers within that network and arbitrarily retain that the very first connected computer must be given the number "0", the second one "1", the third one "2" and so on until we exhaust the address pool at number 4294967295 giving no more than 4294967296 (2^32) computers on that network because no number can be a duplicate.
  
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>.
+
= Classful and classless networks =
  
<console>
+
Those addresses follows the thereafter logic:
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:
+
{| class="wikitable"
 +
|-
 +
| colspan="2" | '''32 bits (fixed length)'''
 +
|-
 +
| '''Network''' part (variable length of N bits ) || '''Host''' part (length : 32 - N bits)
 +
|}
  
<console>
+
* The network address : this part is uniquely assigned amongst all of the organizations in the world (i.e. No one in the world can hold the same network part) 
# ##i##mkfs.vfat -F 32 /dev/sda1
+
* The host address :  unique within a given network part
</console>
+
  
Your <tt>/etc/fstab</tt> entry for this filesystem will also differ, and will look like this:
+
So in theory we can have something like this (remember the network nature is not to be unique, it hs to be be a collection of networks  :
  
{{File
+
* Network 1 Host 1
|/etc/fstab|<pre>
+
*
/dev/sda1 /boot vfat noatime 1 2
+
</pre>}}
+
  
Make sure you add VFAT support to your kernel if you are building it manually.
 
  
== Boot Loader ==
+
Just like your birthday cake is divided in more or less smaller parts depending on how guests' appetite, the IPv4 address space has also been divided into more or less smaller parts just because organizations needs more or less computers on their networks. How to make this possible? Simply by dedicating a variable number of bits to the network part! Do you see the consequence? An IPv4 address being '''always''' 32 bits wide, the more bits you dedicate to the network part the lesser you have for the host part and vice-versa, this is a tradeoff, always. Basically, having more bits in :
 +
* the network part : means more networks possible at the cost of having less hosts per network 
 +
* the host part : means less networks but more hosts per network
  
=== Emerging GRUB ===
+
It might sounds a bit abstract but let's take an example : imagine we dedicate only 8 bits for the network part and the remaining 24 for the hosts part. What happens?  First if we only
  
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>:
+
  
{{File
+
Is the network part assigned by each organization to itself? Of course not! Assignment are coordinated at the worldwide level by what we call Regional Internet Registries or RIRs which, in turn, can delegate assignments to third-parties located within their geographic jurisdiction. Those latter are called Local Internet Registries or LIRs (the system is detailed in RFC 7020). All of those RIRs are themselves put under the responsibility of now now well-known Internet Assigned Numbers Authority or [http://www.iana.org IANA]. As of 2014 five RIR exists :
|/etc/portage/make.conf|<pre>
+
   
.....
+
* ARIN (American Registry for Internet Numbers) : covers North America
GRUB_PLATFORMS="efi-64"
+
* LACNIC (Latin America and Caribbean Network Information Centre): covers South America and the Caribbean
</pre>}}
+
* RIPE-NCC (Réseaux IP Européens / or RIPE Network Coordination Centre): covers Europe, Russia and middle east
 
+
* Afrinic (Africa Network Information Center) : covers the whole Africa
Then, <tt>emerge grub</tt>. You will notice <tt>efibootmgr</tt> getting pulled in as a dependency. This is expected and good.
+
* APNIC (Asian and Pacific Network Information Centre) : covers oceania and far east.
 
+
=== 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 /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.
+
=== 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 not use boot-update directly and will create a <tt>/boot/grub/grub.cfg</tt> file manually that looks like this:
+
{{File
+
|/boot/grub/grub.cfg|<pre>
+
set timeout=3
+
set gfxmode=auto
+
insmod efi_gop
+
insmod efi_uga
+
 
+
menuentry "Funtoo Linux genkernel - kernel-debian-sources-x86_64-3.2.35-2" { 
+
    insmod part_gpt
+
    insmod fat  
+
    set root=(hostdisk//dev/sda,gpt1)
+
    search --no-floppy --fs-uuid --set __REPLACE_UUID_OF_SDA1__
+
    linux /kernel-debian-sources-x86_64-3.2.35-2 real_root=/dev/sda3
+
    initrd /initramfs-debian-sources-x86_64-3.2.35-2 
+
    set gfxpayload=keep
+
}
+
set default=0
+
</pre>}}
+
 
+
Note the <tt>search</tt> line where it says '''<tt>__REPLACE_UUID_OF_SDA1__</tt>''' above. You will need to run '''<tt>blkid /dev/sda1</tt>''' and use the UUID value that is displayed. For example, on my system, I need to use '''<tt>C34B-19CF</tt>'''. You can also change the <tt>menuentry</tt> line text in quotes to say whatever you want, and the <tt>linux</tt> and <tt>initrd</tt> lines should reference your kernel versions in <tt>/boot</tt>. As above, use the path <tt>/</tt> instead of <tt>/boot</tt> as the path should be relative to the root of the VFAT filesystem.
+
 
+
== 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:
+
* grub:NAME of you hard drive
+
 
+
=== 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.
+

Revision as of 15:55, 16 January 2014

WARNING: Work in progress. Do not edit this article unless you are the original author.


Refresh on TCP/IP model

When the ARPANet (a packet oriented network) was born in those good old seventies, engineers had to solve the problem of making computers being able to exchange packets of information over the network and they invented in 1974 something you are now using to view this page: TCP/IP! TCP/IP is a collection of various network protocols, being organized as a stack. Just like your boss does not do everything in the company and delegates at lower levels which in turn delegates at an even more lower level, no protocol in the TCP/IP suite takes all responsibilities, they are working together in a hierarchical and cooperative manner. A level of the TCP/IP stack knows what its immediate lower subordinate can do for it and whatever it will do will be done the right way and will not worry about the manner the job will be done. Also the only problem for a given level of the stack is to fulfill its own duties and deliver the service requested by the upper layer, it does not have to worry about the ultimate goal of what upper levels do.

<illustration goes here TCP/IP model>

The above illustration sounds horribly familiar : yes, it is sounds like this good old OSI model. Indeed it is a tailored view of the original OSI model and it works the exact same way: so the data sent by an application A1 (residing on computer C1) to another application A2 (residing on computer C2) goes through C1's TCP/IP stack (from top to bottom), reach the C1's lower layers that will take the responsibility to move the bits from C1 to C2 over a physical link (electrical or lights pulses, radio waves...sorry no quantum mechanism yet) . C2's lower layers will receive the bits sent by C1 and pass what has been received to the C2's TCP/IP stack (bottom to top) which will pass the data to A2. If C1 and C2 are not on the same network the process is a bit more complex because it involves relays (routers) but the global idea remains the same. Also there is no shortcuts in the process : both TCP/IP stacks are crossed in their whole, either from top to bottom for the sender or bottom to top for the receiver. The transportation process in itself is also absolutely transparent from an application's point of view: A1 knows it can rely on the TCP/IP stack to transmits some data to A2, how the data is transmitted is not its problem, A1 just assumes the data can be transmitted by some means. The TCP/IP stack is also loosely coupled to a particular network technology because its frontier is precisely the physical transportation of bits over a medium and so the physical network's technology, just the same way A1 does not care about how the TCP/IP stack will move the data from one computer to another. The TCP/IP stack itself does not care about the details about how the bits are physically moved and thus it can work with any network technology no matter the technology is Ethernet, Token Ring or FDDI for example.

The Internet layer

The goal of this article being more focused on calculation of addresses used at the Internet layer so let's forget the gory details of the TCP/IP stack works (you can find an extremely detailed discussion in How the TCP/IP stack works... to be written...). From here, we assume you have a good general understanding of its functionalities and how a network transmission works. As you know the Internet layer is responsible to handle logical addressing issues of a TCP segment (or UDP datagram) that has either to be transmitted over the network or that has been received from the network.

Who would ever need millions of addresses afterall? So in theory with those 32 bits we can have around 4 billions of computers within that network and arbitrarily retain that the very first connected computer must be given the number "0", the second one "1", the third one "2" and so on until we exhaust the address pool at number 4294967295 giving no more than 4294967296 (2^32) computers on that network because no number can be a duplicate.

Classful and classless networks

Those addresses follows the thereafter logic:

32 bits (fixed length)
Network part (variable length of N bits ) Host part (length : 32 - N bits)
  • The network address : this part is uniquely assigned amongst all of the organizations in the world (i.e. No one in the world can hold the same network part)
  • The host address : unique within a given network part

So in theory we can have something like this (remember the network nature is not to be unique, it hs to be be a collection of networks  :

  • Network 1 Host 1


Just like your birthday cake is divided in more or less smaller parts depending on how guests' appetite, the IPv4 address space has also been divided into more or less smaller parts just because organizations needs more or less computers on their networks. How to make this possible? Simply by dedicating a variable number of bits to the network part! Do you see the consequence? An IPv4 address being always 32 bits wide, the more bits you dedicate to the network part the lesser you have for the host part and vice-versa, this is a tradeoff, always. Basically, having more bits in :

  • the network part : means more networks possible at the cost of having less hosts per network
  • the host part : means less networks but more hosts per network

It might sounds a bit abstract but let's take an example : imagine we dedicate only 8 bits for the network part and the remaining 24 for the hosts part. What happens? First if we only


Is the network part assigned by each organization to itself? Of course not! Assignment are coordinated at the worldwide level by what we call Regional Internet Registries or RIRs which, in turn, can delegate assignments to third-parties located within their geographic jurisdiction. Those latter are called Local Internet Registries or LIRs (the system is detailed in RFC 7020). All of those RIRs are themselves put under the responsibility of now now well-known Internet Assigned Numbers Authority or IANA. As of 2014 five RIR exists :

  • ARIN (American Registry for Internet Numbers) : covers North America
  • LACNIC (Latin America and Caribbean Network Information Centre): covers South America and the Caribbean
  • RIPE-NCC (Réseaux IP Européens / or RIPE Network Coordination Centre): covers Europe, Russia and middle east
  • Afrinic (Africa Network Information Center) : covers the whole Africa
  • APNIC (Asian and Pacific Network Information Centre) : covers oceania and far east.