Difference between pages "Package:Whenjobs" and "Install/ru/Partitioning"

From Funtoo
(Difference between pages)
Jump to navigation Jump to search
 
 
Line 1: Line 1:
{{Ebuild
<noinclude>
|Summary=A cron daemon replacement that is powerful, yet simple.
{{InstallPart|процесс разбиения диска и создания файловых систем}}
|CatPkg=sys-process/whenjobs
</noinclude>
|Maintainer=Golodhrim,
=== Подготовка жесткого диска ===
|Repository=Funtoo Overlay
 
}}
В этой части  мы научимся различным способам установки Funtoo Linux -- и загрузки с -- жесткий диск.
{{fancywarning|This document is a work in progress, as we are still investigating whenjobs for funtoo usage. For information about it see Funtoo tickets about [http://bugs.funtoo.org/browse/FL-316 whenjobs], [http://bugs.funtoo.org/browse/FL-337 initscript], [http://bugs.funtoo.org/browse/FL-338 User Feedback] and [http://bugs.funtoo.org/browse/FL-351 this document].}}
== What are whenjobs? ==


Whenjobs was written by Richard Jones from [http://www.redhat.com RedHat Linux]. Whenjobs is designed to be a cron daemon replacement with some improvements over normal cron-jobs. Further, we have added some improvements to Whenjobs. Whenjobs gives users a more simple syntax for jobs to run and, with Funtoo improvements, an effective user-management option for whenjobs -- that way we fixed the default behaviour of whenjobs to not been able to run as root and let us execute the daemon on a per-user basis by default.
==== Введение ====


=== Questions for help and testing ===
В прежние времена существовал лишь один способ загрузить PC-совместимый компьютер. Все наши дектопы и сервера имели стандартный PC BIOS, все наши харды использовали MBR и были разбиты используя схему разбивки MBR.  Вот как это все было и нам это нравилось!


We would like to get your feedback to [http://bugs.funtoo.org/browse/FL-338 FL-338]. So, please test and report your experience with whenjobs.
Затем появились EFI и UEFI,  встроенные программы нового образца наряду со схемой разбивки GPT, поддерживающая диски размером более 2.2TБ. Неожиданно, нам стали доступны различные способы установки и загрузки Линукс систем . То, что было единым методом, стало чем-то более сложным.


== How to install whenjobs ==
Let's take a moment to review the options available to you for configuring a hard drive to boot Funtoo Linux. This Install Guide uses, and recommends, the old-school method of BIOS booting and using an MBR. It works and (except for rare cases) is universally supported. There's nothing wrong with it. If your system disk is 2TB or smaller in size, it won't prevent you from using all of your disk's capacity, either.


The installation of {{Package|sys-process/whenjobs}} is really easy, just merge it:
But, there are some situations where the old-school method isn't optimal. If you have a system disk >2TB in size, then MBR partitions won't allow you to access all your storage. So that's one reason. Another reason is that there are some so-called "PC" systems out there that don't support BIOS booting anymore, and force you to use UEFI to boot. So, out of compassion for people who fall into this predicament, this Install Guide documents UEFI booting too.


<console>
Our recommendation is still to go old-school unless you have reason not to. The boot loader we will be using to load the Linux kernel in this guide is called GRUB, so we call this method the '''BIOS + GRUB (MBR)''' method. It's the traditional method of setting up a PC-compatible system to boot Linux.
###i## emerge -avt whenjobs
</console>


== How to get started ==
If you need to use UEFI to boot, we recommend not using the MBR at all for booting, as some systems support this, but others don't. Instead, we recommend using UEFI to boot GRUB, which in turn will load Linux. We refer to this method as the '''UEFI + GRUB (GPT)''' method.


As mentioned above, we added a user-management feature. Also, whenjobs has a changed syntax compared to normal cronjobs -- we will discuss that now.
And yes, there are even more methods, some of which are documented on the [[Boot Methods]] page. We used to recommend a '''BIOS + GRUB (GPT)''' method but it is not consistently supported across a wide variety of hardware.


=== User management ===
'''The big question is -- which boot method should you use?''' Here's how to tell.


The user management for whenjobs is done with a single file located at <tt>/etc/whenjobs.users.conf</tt>. Just add a user to that file by a comma seperated list like:
;Principle 1 - Old School: If you can reliably boot System Rescue CD and it shows you an initial light blue menu, you are booting the CD using the BIOS, and it's likely that you can thus boot Funtoo Linux using the BIOS. So, go old-school and use BIOS booting, ''unless'' you have some reason to use UEFI, such as having a >2.2TB system disk. In that case, see Principle 2, as your system may also support UEFI booting.


<pre>
;Principle 2 - New School: If you can reliably boot System Rescue CD and it shows you an initial black and white menu -- congratulations, your system is configured to support UEFI booting. This means that you are ready to install Funtoo Linux to boot via UEFI. Your system may still support BIOS booting, but just be trying UEFI first. You can poke around in your BIOS boot configuration and play with this.
root,user1,user2,user3
</pre>


where user1-user3 must be system-usernames, as they are checked. Please do not add any other lines to that file, as there is no way for comments in the file. In addition, adding other lines will break whenjobs -- you will not be able to start the daemon later. Currently, there is no initscript, but we are working on one and that initscript will then use that file in the same way.
;What's the Big Difference between Old School and New School?: Here's the deal. If you go with old-school MBR partitions, your <code>/boot</code> partition will be an ext2 filesystem, and you'll use <code>fdisk</code> to create your MBR partitions. If you go with new-school GPT partitions and UEFI booting, your <code>/boot</code> partition will be a vfat filesystem, because this is what UEFI is able to read, and you will use <code>gdisk</code> to create your GPT partitions. And you'll install GRUB a bit differently. That's about all it comes down to, in case you were curious.


=== whenjobs commands ===
;Also Note: To install Funtoo Linux to boot via the New School UEFI method, you must boot System Rescue CD using UEFI -- and see an initial black and white screen. Otherwise, UEFI will not be active and you will not be able to set it up!


There are some basic commands for whenjobs you should be aware of before we get to explain the script syntax for whenjobs:
{{Note|'''Some motherboards may appear to support UEFI, but don't.''' Do your research. For example, the Award BIOS in my Gigabyte GA-990FXA-UD7 rev 1.1 has an option to enable UEFI boot for CD/DVD. '''This is not sufficient for enabling UEFI boot for hard drives and installing Funtoo Linux.''' UEFI must be supported for both removable media (so you can boot System Rescue CD using UEFI) as well as fixed media (so you can boot your new Funtoo Linux installation.) It turns out that later revisions of this board (rev 3.0) have a new BIOS that fully supports UEFI boot.  This may point to a third principle -- know thy hardware.}}


To edit/list a job script, use:
==== Old-School (BIOS/MBR) Method ====


<console>
{{Note|Use this method if you are booting using your BIOS, and if your System Rescue CD initial boot menu was light blue. If you're going to use the new-school method, [[#New-School (UEFI/GPT) Method|click here to jump down to UEFI/GPT.]]}}
# ##i##whenjobs -e | --edit
# ##i##whenjobs -l | --list
</console>


in the above case we added both the short and long version in one line so please use either the '''-e''' or the '''--edit''' version as there is no piping done at that part. We will use the same syntax for further examples if there are multiple ways of calling the function we need.
===== Preparation =====


Another import part is to set or get variables we want to set or set in whenjobs, that can be done with:
First, it's a good idea to make sure that you've found the correct hard disk to partition. Try this command and verify that <code>/dev/sda</code> is the disk that you want to partition:


<console>
<console>
to get a variable:
# ##i##fdisk -l /dev/sda
###i## whenjobs --get variable
 
to set a variable or multiple varibles:
Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
###i## whenjobs --set variable=value [variable=value ...]
Units = sectors of 1 * 512 = 512 bytes
and to display all set variables:
Sector size (logical/physical): 512 bytes / 512 bytes
###i## whenjobs --variables
I/O size (minimum/optimal): 512 bytes / 512 bytes
</console>
Disk label type: gpt


Another important function in whenjobs is the way to start, stop and request the status of the per-user daemon:
<console>
# ##i##whenjobs --daemon-start
# ##i##whenjobs --daemon-stop
# ##i##whenjobs --daemon-status
# ##i##whenjobs --daemon-restart
</console>


Finally we have the ability to inspect running jobs:
#         Start          End    Size  Type            Name
<console>
1        2048  1250263694  596.2G  Linux filesyste Linux filesystem
# ##i##whenjobs --jobs
# ##i##whenjobs --cancel serial
# ##i##whenjobs --start "name"
# ##i##whenjobs --tail serial
</console>
</console>


=== How to get started with whenjobs now ===
Now, it's recommended that you erase any existing MBR or GPT partition tables on the disk, which could confuse the system's BIOS at boot time. We do this using <code>sgdisk</code>:
{{fancywarning|This will make any existing partitions inaccessible! You are '''strongly''' cautioned and advised to backup any critical data before proceeding.}}


First edit the above mentioned <tt>whenjobs.users.conf</tt> file if not already done and start a daemon on a per-user basis with
<console>
# ##i##sgdisk --zap-all /dev/sda


<console>
Creating new GPT entries.
# ##i##whenjobs --daemon-start
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.
</console>
</console>


Thats all for starting whenjobs and now we have time to write some whenjobs-scripts. We will use here some basic examples nothing for real time usage but it should be able to give you the impression on how to write your own scripts and use the variables in the later process. First we need to edit our whenjobs-script. This can be done by two ways:
This output is also nothing to worry about, as the command still succeded:


<console>
<console>
Version A) (manual way, not recommended)
***************************************************************
# ##i##EDITOR ~/.whenjobs/jobs.ml
Found invalid GPT and valid MBR; converting MBR to GPT format
Edit the file with the scripts you want to use and save it, but after that you need to upload it so that whenjobs knows about it
in memory.
# ##i##whenjobs --upload
***************************************************************
Version B) (automatically by whenjobs, recommended)
# ##i##whenjobs -e  | --edit
just save your script now and whenjobs will upload it automatically for you.
</console>
</console>


So far we are now fine with getting to the scripts, next let us add some basics. We will now start with a periodic call, like if we would like to check out load everyage every 10 minutes we would do it like this:
===== Partitioning =====


{{fancywarning|A note aside, the scripts are real shell scripts, so parts beginning with a '''#''' are comments and parts without are the shell script commands that are executed!}}
Now we will use <code>fdisk</code> to create the MBR partition table and partitions:


<source lang="ocaml">
<console>
every 10 minutes :
# ##i##fdisk /dev/sda
<<
</console>
  # Get the current load average.
  load=`awk '{print $1}' /proc/loadavg`
  whenjobs --set --type float load=$load
>>
</source>


The power of whenjobs comes in game when you would like to base on a variable you set somewhere else:
Within <code>fdisk</code>, follow these steps:


<source lang="ocaml">
'''Empty the partition table''':
when load >= 6 :
<<
  mail -s "ALERT: high load average: $load" MAILADDRESS < /dev/null
>>
</source>


That part will notify a user via email when his load average is greater or equal to 6, as when statements are "edge-triggered".
<console>
Command (m for help): ##i##o ↵
</console>


The '''--type''' switch above for setting a variable can be one of '''bool, int, float, string or unit'''
'''Create Partition 1''' (boot):


==== Periodic expressions ====
<console>
Command (m for help): ##i##n ↵
Partition type (default p): ##i##↵
Partition number (1-4, default 1): ##i##↵
First sector: ##i##↵
Last sector: ##i##+128M ↵
</console>


For periodic expressions you have to use the following syntax
'''Create Partition 2''' (swap):


<source lang="ocaml">
<console>
every <period> :
Command (m for help): ##i##n ↵
<<
Partition type (default p): ##i##↵
  # shell script
Partition number (2-4, default 2): ##i##↵
>>
First sector: ##i##↵
</source>
Last sector: ##i##+2G ↵
Command (m for help): ##i##t ↵
Partition number (1,2, default 2): ##i## ↵
Hex code (type L to list all codes): ##i##82 ↵
</console>


where '''<period>''' is one of the following period expressions:
'''Create the root partition:'''


{| class="wikitable"
<console>
! <period>
Command (m for help): ##i##n ↵
! Description
Partition type (default p): ##i##↵
!
Partition number (3,4, default 3): ##i##↵
! Special <period>
First sector: ##i##↵
! Description
Last sector: ##i##↵
|-
</console>
| second
| runs every second
|
| X seconds
| runs every X seconds
|-
| minute
| runs every minute
|
| X minutes
| runs every X minutes
|-
| hour
| runs every hour
|
| X hours
| runs every X hours
|-
| day
| runs every day, at midnight UTC
|
| X days
| runs every X days, at midnight UTC
|-
| week
| runs every week, on a Thursday at midnight UTC
|
| X weeks
| runs every X weeks, on a Thursday at midnight UTC
|-
| month
| runs every month, on the 1st at midnight UTC
|
| X months
| runs every X month, on the 1st at midnight UTC
|-
| year
| runs every year, on the 1/1 at midnight UTC
|
| X years
| runs every X years, on the 1/1 at midnight UTC
|-
| decade
| runs every 10 years
|
| X decades
| runs every X decades
|-
| century
| runs every 100 years
|
| X centuries
| runs every X centuries
|-
| millenium
| runs every 1000 years
|
| X millenia
| runs every X mellenia
|}


==== When expressions ====
'''Verify the partition table:'''


For dependent jobs you need to use the when-statements with the following syntax:
<console>
Command (m for help): ##i##p


<source lang="ocaml">
Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
when <expr> :
Units: sectors of 1 * 512 = 512 bytes
<<
Sector size (logical/physical): 512 bytes / 512 bytes
  # shell script
I/O size (minimum/optimal): 512 bytes / 512 bytes
>>
Disklabel type: dos
</source>
Disk identifier: 0x82abc9a6


where '''<expr>''' is a when expression. But don't forget the colon between periods expression or when expression and the shell script.
Device    Boot    Start      End    Blocks  Id System
/dev/sda1          2048    264191    131072  83 Linux
/dev/sda2        264192  4458495  2097152  82 Linux swap / Solaris
/dev/sda3        4458496 625142447 310341976  83 Linux
</console>


All in all you can say, that a when-expression is a job which runs, when the described conditions become true.
'''Write the parition table to disk:'''


{| class="wikitable"
<console>
! <expr>
Command (m for help): ##i##w
! meaning
</console>
!
! <expr>
! meaning
|-
| expr && expr
| boolean "and" of the two sub-expressions
|
| ! expr
| boolean negative of expr
|-
| expr <nowiki>||</nowiki> expr
| boolean "or" of the two sub-expressions
|
| expr + expr
| for numeric sub-expression, this performs addition, for strings it performs string concatenation, else it returns an error.
|-
| expr < expr
| evaluates sub-expressions and compares them with the operator
|
| expr - expr
| evaluates sub-expressions and if both are numeric uses operator on them else returns error
|-
| expr <= expr
| evaluates sub-expressions and compares them with the operator
|
| expr * expr
| evaluates sub-expressions and if both are numeric uses operator on them else returns error
|-
| expr == expr
| evaluates sub-expressions and compares them with the operator
|
| expr / expr
| evaluates sub-expressions and if both are numeric uses operator on them else returns error
|-
| expr >= expr
| evaluates sub-expressions and compares them with the operator
|
| expr mod expr
| evaluates sub-expressions and if both are numeric uses operator on them else returns error (infix operator)
|-
| expr > expr
| evaluates sub-expressions and compares them with the operator
|
| len expr
| returns the length of the string in expr
|-
| variable
| returns the value of named variable
|
| prev variable
| returns previous value of named variable
|-
| changes variable
| same as !(prev variabel == variable)
|
| increases variable
| same as prev variable < variable
|-
| decreases variable
| prev variable > variable
|
| reloaded ()
| do not use it, it does not what you want (manpage warning)
|-
| false
| constant equals always false
|
| true
| constant equals always true
|-
| "any string"
| empty string in boolean = false, else equals true
|
| N
| any integer, boolean 0=false, non-zero=true
|-
| N. | .N | N.N | N.NeN
| and floating point number, boolean 0=false, non-zero=true
|
|
|
|}


==== shell scripts ====
Your new MBR partition table will now be written to your system disk.


The code between '''<< ... >>''' is a simple shell script and is executed using $SHELL. If $SHELL is not set, it is executed with '''/bin/sh'''
{{Note|You're done with partitioning! Now, jump over to [[#Creating filesystems|Creating filesystems]].}}


{| class="wikitable"
==== New-School (UEFI/GPT) Method ====
! available variable
! Description
|-
| $JOBNAME
| The name of the job. If the job has been named explicitly, then that name is available through this variable, else it will be some implicit name like '''job$1'''.
|-
| $JOBSERIAL
| The serial number of the job. This is simply a variable that increments each time a job is run, and is unique to that run of the job.
|-
| $HOME, $LOGNAME etc
| these are available as normal
|}


The shell scripts run with its current directory set to an temporary directory, that is cleaned up automacically after the job exists. So you don't have to worry about cleaning them up later. If you would like to store some values permanently, save the files to a well-known directory, eg. $HOME, '''/var''' etc.
{{Note|Use this method if you are booting using UEFI, and if your System Rescue CD initial boot menu was black and white. If it was light blue, this method will not work.}}


All shell scripts are executed as the ordinary user. They have no special privileges.
The <tt>gdisk</tt> commands to create a GPT partition table are as follows. Adapt sizes as necessary, although these defaults will work for most users. Start <code>gdisk</code>:


==== Job names ====
<console>
# ##i##gdisk
</console>


If you like to give a job a unique name use the following syntax:
Within <tt>gdisk</tt>, follow these steps:


<source lang="ocaml">
'''Create a new empty partition table''' (This ''will'' erase all data on the disk when saved):
job "JOBNAME"
every <period> :
<<
  # shell script
>>
</source>


==== OCAML expressions ====
<console>
Command: ##i##o ↵
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): ##i##y ↵
</console>


You can also use OCAML expressions in the code. they are useful for factoring common code or strings, for example:
'''Create Partition 1''' (boot):


<source lang="ocaml">
<console>
let prefix = "daily_"
Command: ##i##n ↵
Partition Number: ##i##1 ↵
First sector: ##i##↵
Last sector: ##i##+500M ↵
Hex Code: ##i##↵
</console>


job (prefix ^ "virus_scan")
'''Create Partition 2''' (swap):
every day :
<<
  # shell script
>>


job (prefix ^ "disk_check")
<console>
every day :
Command: ##i##n ↵
<<
Partition Number: ##i##2 ↵
  # shell script
First sector: ##i##↵
>>
Last sector: ##i##+4G ↵
</source>
Hex Code: ##i##8200 ↵
</console>


===== initial value of variables =====
'''Create Partition 3''' (root):


Variables are empty until they first get set, you can set a default starting value for a variable if you like with the following code
<console>
Command: ##i##n ↵
Partition Number: ##i##3 ↵
First sector: ##i##↵
Last sector: ##i##↵##!i## (for rest of disk)
Hex Code: ##i##↵
</console>


<source lang="ocaml">
Along the way, you can type "<tt>p</tt>" and hit Enter to view your current partition table. If you make a mistake, you can type "<tt>d</tt>" to delete an existing partition that you created. When you are satisfied with your partition setup, type "<tt>w</tt>" to write your configuration to disk:
let () =
  Whentools.set_variable "variable" "value";
  Whentools.set_variable_int "counter" 0
</source>


===== Pre functions =====
'''Write Partition Table To Disk''':


You can let arrange to run a '''pre''' function before a job runs. This function may decide to not run the job. One possible usage for that is the that you only want to have one job at time from the same job to run:
<console>
Command: ##i##w ↵
Do you want to proceed? (Y/N): ##i##Y ↵
</console>


<source lang="ocaml">
The partition table will now be written to disk and <tt>gdisk</tt> will close.
job "only one"
pre (Whentools.one ())
every <period> :
<<
  # shell script
>>
</source>


===== Post functions =====
Now, your GPT/GUID partitions have been created, and will show up as the following ''block devices'' under Linux:


The same is for stuff after a job has run. This is handled by the '''post''' function.
* <tt>/dev/sda1</tt>, which will be used to hold the <tt>/boot</tt> filesystem,
* <tt>/dev/sda2</tt>, which will be used for swap space, and
* <tt>/dev/sda3</tt>, which will hold your root filesystem.


<source lang="ocaml">
==== Creating filesystems ====
job "talk to me after finished"
post (Whentools.mailto "you@example.com")
every <period> :
<<
  # shell script
>>
</source>


===== Basic available Whentools functions =====
{{Note|This section covers both BIOS ''and'' UEFI installs. Don't skip it!}}


{| class="wikitable"
Before your newly-created partitions can be used, the block devices need to be initialized with filesystem ''metadata''. This process is known as ''creating a filesystem'' on the block devices. After filesystems are created on the block devices, they can be mounted and used to store files.
! function
! Description
|-
| style="vertical-align:top;"| whentools.mailto [~only_on_failure:true] [~from:from_address] email_address result
| This built-in post function sends the result of the script by email to the given email address.


If the optional "~only_on_failure:true" flag is set, then it is only sent out if the script failed.
Let's keep this simple. Are you using old-school MBR partitions? If so, let's create an ext2 filesystem on /dev/sda1:


If the optional "~from" flag is set, then the from address is set accordingly.  This is sometimes needed when sending mail.
<console>
# ##i##mkfs.ext2 /dev/sda1
</console>


Note the "result" parameter is passed implicitly by the daemon. You do not need to add it.
If you're using new-school GPT partitions for UEFI, you'll want to create a vfat filesystem on /dev/sda1, because this is what UEFI is able to read:


Here are some examples of using the mailto function:
<console>
# ##i##mkfs.vfat -F 32 /dev/sda1
</console>


<source lang="ocaml">
Now, let's create a swap partition. This partition will be used as disk-based virtual memory for your Funtoo Linux system.
job "ex.1"
post (Whentools.mailto "you@example.com")
every 10 seconds :
<<
  # shell script 1
>>


job "ex.2"
You will not create a filesystem on your swap partition, since it is not used to store files. But it is necessary to initialize it using the <code>mkswap</code> command. Then we'll run the <code>swapon</code> command to make your newly-initialized swap space immediately active within the live CD environment, in case it is needed during the rest of the install process:
post (Whentools.mailto ~only_on_failure:true "you@example.com")
every 10 seconds :
<<
  # shell script 2
>>


let from = "me@example.com"
<console>
let to_addr = "you@example.com"
# ##i##mkswap /dev/sda2
# ##i##swapon /dev/sda2
</console>


job "ex.3"
Now, we need to create a root filesystem. This is where Funtoo Linux will live. We generally recommend ext4 or XFS root filesystems. If you're not sure, choose ext4. Here's how to create a root ext4 filesystem:
post (Whentools.mailto ~from to_addr)
every 10 seconds :
<<
  # shell script 3
>>
</source>
|-
| style="vertical-align:top;"| Whentools.max n
| This built-in pre function ensures that a maximum of n instances of the job are running.


It checks the list of running jobs, and if n or more instances are already running, then it returns "false", which ensures that the new job is not started.
<console>
|-
# ##i##mkfs.ext4 /dev/sda3
| style="vertical-align:top;"| Whentools.one ()
</console>
| This built-in pre function ensures that only one instance of the job is running.  It is the same as calling: Whentools.max 1


|-
...and here's how to create an XFS root filesystem, if you choose to use XFS:
| style="vertical-align:top;"| Whentools.set_variable name string
| Set variable name to the string
|-
| Whentools.set_variable_bool name b
| Set variable name to the boolean value b
|-
| style="vertical-align:top;"| Whentools.set_variable_int name i
| Set variable name to the integer value i
|-
| style="vertical-align:top;"| Whentools.set_variable_string name s
| Set variable name to the string value <s>.  This is the same as Whentools.set_variable
|-
| style="vertical-align:top;"| Whentools.set_variable_float name f
| Set variable name to the floating point value f
|}


For the preinfo passed to the pre functions and results for the post functions have a view in the manpage.
<console>
# ##i##mkfs.xfs /dev/sda3
</console>


== Examples ==
Your filesystems (and swap) have all now been initialized, so that that can be mounted (attached to your existing directory heirarchy) and used to store files. We are ready to begin installing Funtoo Linux on these brand-new filesystems.


Finally here are some examples to which questions came up, hope you find them helpful for your first own tries... :)
{{fancywarning|1=
When deploying an OpenVZ host, please use ext4 exclusively. The Parallels development team tests extensively with ext4, and modern versions of <code>openvz-rhel6-stable</code> are '''not''' compatible with XFS, and you may experience kernel bugs.
}}


<source lang="ocaml">
==== Mounting filesystems ====
every 1 minute :
<<
  testtime=`date +%H%M`
  whenjobs --set --type int test=${testtime}
  whenjobs --set --type int runtime=0016
>>


when test == 0017 :
Mount the newly-created filesystems as follows, creating <code>/mnt/funtoo</code> as the installation mount point:
<<
  echo `date` >\> ~/test.log
>>


when test == runtime
<console>
<<
# ##i##mkdir /mnt/funtoo
  whenjobs --get runtime >\> ~/test.log
# ##i##mount /dev/sda3 /mnt/funtoo
>>
# ##i##mkdir /mnt/funtoo/boot
</source>
# ##i##mount /dev/sda1 /mnt/funtoo/boot
</console>


The above whenjobs have the need to run each day at a specific time, so we show you here two ways of doing it.
Optionally, if you have a separate filesystem for <code>/home</code> or anything else:


First we define a variable test for whenjobs based on the date with the HHMM output what would for example result in 0017 for 12:17am and 1428 for 2:28pm. then in the first when expression we test if our variable equals 0017 and if yes it runs, the second version is to define a second variable called runtime and then do like the second test does a test for it based on comparing both variables.
<console>
# ##i##mkdir /mnt/funtoo/home
# ##i##mount /dev/sda4 /mnt/funtoo/home
</console>


But now enough with that long doc, happy whenjobing for all of you... :)
If you have <code>/tmp</code> or <code>/var/tmp</code> on a separate filesystem, be sure to change the permissions of the mount point to be globally-writeable after mounting, as follows:


 
<console>
[[Category:HOWTO]]
# ##i##chmod 1777 /mnt/funtoo/tmp
[[Category:Labs]]
</console>
[[Category:Ebuilds]]
{{EbuildFooter}}

Revision as of 13:31, January 5, 2015


   Note

This is a template that is used as part of the Installation instructions which covers: процесс разбиения диска и создания файловых систем. Templates are being used to allow multiple variant install guides that use most of the same re-usable parts.


Подготовка жесткого диска

В этой части мы научимся различным способам установки Funtoo Linux -- и загрузки с -- жесткий диск.

Введение

В прежние времена существовал лишь один способ загрузить PC-совместимый компьютер. Все наши дектопы и сервера имели стандартный PC BIOS, все наши харды использовали MBR и были разбиты используя схему разбивки MBR. Вот как это все было и нам это нравилось!

Затем появились EFI и UEFI, встроенные программы нового образца наряду со схемой разбивки GPT, поддерживающая диски размером более 2.2TБ. Неожиданно, нам стали доступны различные способы установки и загрузки Линукс систем . То, что было единым методом, стало чем-то более сложным.

Let's take a moment to review the options available to you for configuring a hard drive to boot Funtoo Linux. This Install Guide uses, and recommends, the old-school method of BIOS booting and using an MBR. It works and (except for rare cases) is universally supported. There's nothing wrong with it. If your system disk is 2TB or smaller in size, it won't prevent you from using all of your disk's capacity, either.

But, there are some situations where the old-school method isn't optimal. If you have a system disk >2TB in size, then MBR partitions won't allow you to access all your storage. So that's one reason. Another reason is that there are some so-called "PC" systems out there that don't support BIOS booting anymore, and force you to use UEFI to boot. So, out of compassion for people who fall into this predicament, this Install Guide documents UEFI booting too.

Our recommendation is still to go old-school unless you have reason not to. The boot loader we will be using to load the Linux kernel in this guide is called GRUB, so we call this method the BIOS + GRUB (MBR) method. It's the traditional method of setting up a PC-compatible system to boot Linux.

If you need to use UEFI to boot, we recommend not using the MBR at all for booting, as some systems support this, but others don't. Instead, we recommend using UEFI to boot GRUB, which in turn will load Linux. We refer to this method as the UEFI + GRUB (GPT) method.

And yes, there are even more methods, some of which are documented on the Boot Methods page. We used to recommend a BIOS + GRUB (GPT) method but it is not consistently supported across a wide variety of hardware.

The big question is -- which boot method should you use? Here's how to tell.

Principle 1 - Old School
If you can reliably boot System Rescue CD and it shows you an initial light blue menu, you are booting the CD using the BIOS, and it's likely that you can thus boot Funtoo Linux using the BIOS. So, go old-school and use BIOS booting, unless you have some reason to use UEFI, such as having a >2.2TB system disk. In that case, see Principle 2, as your system may also support UEFI booting.
Principle 2 - New School
If you can reliably boot System Rescue CD and it shows you an initial black and white menu -- congratulations, your system is configured to support UEFI booting. This means that you are ready to install Funtoo Linux to boot via UEFI. Your system may still support BIOS booting, but just be trying UEFI first. You can poke around in your BIOS boot configuration and play with this.
What's the Big Difference between Old School and New School?
Here's the deal. If you go with old-school MBR partitions, your /boot partition will be an ext2 filesystem, and you'll use fdisk to create your MBR partitions. If you go with new-school GPT partitions and UEFI booting, your /boot partition will be a vfat filesystem, because this is what UEFI is able to read, and you will use gdisk to create your GPT partitions. And you'll install GRUB a bit differently. That's about all it comes down to, in case you were curious.
Also Note
To install Funtoo Linux to boot via the New School UEFI method, you must boot System Rescue CD using UEFI -- and see an initial black and white screen. Otherwise, UEFI will not be active and you will not be able to set it up!
   Note

Some motherboards may appear to support UEFI, but don't. Do your research. For example, the Award BIOS in my Gigabyte GA-990FXA-UD7 rev 1.1 has an option to enable UEFI boot for CD/DVD. This is not sufficient for enabling UEFI boot for hard drives and installing Funtoo Linux. UEFI must be supported for both removable media (so you can boot System Rescue CD using UEFI) as well as fixed media (so you can boot your new Funtoo Linux installation.) It turns out that later revisions of this board (rev 3.0) have a new BIOS that fully supports UEFI boot. This may point to a third principle -- know thy hardware.

Old-School (BIOS/MBR) Method

   Note

Use this method if you are booting using your BIOS, and if your System Rescue CD initial boot menu was light blue. If you're going to use the new-school method, click here to jump down to UEFI/GPT.

Preparation

First, it's a good idea to make sure that you've found the correct hard disk to partition. Try this command and verify that /dev/sda is the disk that you want to partition:

root # fdisk -l /dev/sda

Disk /dev/sda: 640.1 GB, 640135028736 bytes, 1250263728 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: gpt


root #         Start          End    Size  Type            Name
 1         2048   1250263694  596.2G  Linux filesyste Linux filesystem

Now, it's recommended that you erase any existing MBR or GPT partition tables on the disk, which could confuse the system's BIOS at boot time. We do this using sgdisk:

   Warning

This will make any existing partitions inaccessible! You are strongly cautioned and advised to backup any critical data before proceeding.

root # sgdisk --zap-all /dev/sda

Creating new GPT entries.
GPT data structures destroyed! You may now partition the disk using fdisk or
other utilities.

This output is also nothing to worry about, as the command still succeded:

***************************************************************
Found invalid GPT and valid MBR; converting MBR to GPT format
in memory. 
***************************************************************
Partitioning

Now we will use fdisk to create the MBR partition table and partitions:

root # fdisk /dev/sda

Within fdisk, follow these steps:

Empty the partition table:

Command (m for help): o ↵

Create Partition 1 (boot):

Command (m for help): n ↵
Partition type (default p): 
Partition number (1-4, default 1): 
First sector: 
Last sector: +128M ↵

Create Partition 2 (swap):

Command (m for help): n ↵
Partition type (default p): 
Partition number (2-4, default 2): 
First sector: 
Last sector: +2G ↵
Command (m for help): t ↵ 
Partition number (1,2, default 2): 
Hex code (type L to list all codes): 82 ↵

Create the root partition:

Command (m for help): n ↵
Partition type (default p): 
Partition number (3,4, default 3): 
First sector: 
Last sector: 

Verify the partition table:

Command (m for help): p

Disk /dev/sda: 298.1 GiB, 320072933376 bytes, 625142448 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x82abc9a6

Device    Boot     Start       End    Blocks  Id System
/dev/sda1           2048    264191    131072  83 Linux
/dev/sda2         264192   4458495   2097152  82 Linux swap / Solaris
/dev/sda3        4458496 625142447 310341976  83 Linux

Write the parition table to disk:

Command (m for help): w

Your new MBR partition table will now be written to your system disk.

   Note

You're done with partitioning! Now, jump over to Creating filesystems.

New-School (UEFI/GPT) Method

   Note

Use this method if you are booting using UEFI, and if your System Rescue CD initial boot menu was black and white. If it was light blue, this method will not work.

The gdisk commands to create a GPT partition table are as follows. Adapt sizes as necessary, although these defaults will work for most users. Start gdisk:

root # gdisk

Within gdisk, follow these steps:

Create a new empty partition table (This will erase all data on the disk when saved):

Command: o ↵
This option deletes all partitions and creates a new protective MBR.
Proceed? (Y/N): y ↵

Create Partition 1 (boot):

Command: n ↵
Partition Number: 1 ↵
First sector: 
Last sector: +500M ↵
Hex Code: 

Create Partition 2 (swap):

Command: n ↵
Partition Number: 2 ↵
First sector: 
Last sector: +4G ↵
Hex Code: 8200 ↵

Create Partition 3 (root):

Command: n ↵
Partition Number: 3 ↵
First sector: 
Last sector:  (for rest of disk)
Hex Code: 

Along the way, you can type "p" and hit Enter to view your current partition table. If you make a mistake, you can type "d" to delete an existing partition that you created. When you are satisfied with your partition setup, type "w" to write your configuration to disk:

Write Partition Table To Disk:

Command: w ↵
Do you want to proceed? (Y/N): Y ↵

The partition table will now be written to disk and gdisk will close.

Now, your GPT/GUID partitions have been created, and will show up as the following block devices under Linux:

  • /dev/sda1, which will be used to hold the /boot filesystem,
  • /dev/sda2, which will be used for swap space, and
  • /dev/sda3, which will hold your root filesystem.

Creating filesystems

   Note

This section covers both BIOS and UEFI installs. Don't skip it!

Before your newly-created partitions can be used, the block devices need to be initialized with filesystem metadata. This process is known as creating a filesystem on the block devices. After filesystems are created on the block devices, they can be mounted and used to store files.

Let's keep this simple. Are you using old-school MBR partitions? If so, let's create an ext2 filesystem on /dev/sda1:

root # mkfs.ext2 /dev/sda1

If you're using new-school GPT partitions for UEFI, you'll want to create a vfat filesystem on /dev/sda1, because this is what UEFI is able to read:

root # mkfs.vfat -F 32 /dev/sda1

Now, let's create a swap partition. This partition will be used as disk-based virtual memory for your Funtoo Linux system.

You will not create a filesystem on your swap partition, since it is not used to store files. But it is necessary to initialize it using the mkswap command. Then we'll run the swapon command to make your newly-initialized swap space immediately active within the live CD environment, in case it is needed during the rest of the install process:

root # mkswap /dev/sda2
root # swapon /dev/sda2

Now, we need to create a root filesystem. This is where Funtoo Linux will live. We generally recommend ext4 or XFS root filesystems. If you're not sure, choose ext4. Here's how to create a root ext4 filesystem:

root # mkfs.ext4 /dev/sda3

...and here's how to create an XFS root filesystem, if you choose to use XFS:

root # mkfs.xfs /dev/sda3

Your filesystems (and swap) have all now been initialized, so that that can be mounted (attached to your existing directory heirarchy) and used to store files. We are ready to begin installing Funtoo Linux on these brand-new filesystems.

   Warning

When deploying an OpenVZ host, please use ext4 exclusively. The Parallels development team tests extensively with ext4, and modern versions of openvz-rhel6-stable are not compatible with XFS, and you may experience kernel bugs.

Mounting filesystems

Mount the newly-created filesystems as follows, creating /mnt/funtoo as the installation mount point:

root # mkdir /mnt/funtoo
root # mount /dev/sda3 /mnt/funtoo
root # mkdir /mnt/funtoo/boot
root # mount /dev/sda1 /mnt/funtoo/boot

Optionally, if you have a separate filesystem for /home or anything else:

root # mkdir /mnt/funtoo/home
root # mount /dev/sda4 /mnt/funtoo/home

If you have /tmp or /var/tmp on a separate filesystem, be sure to change the permissions of the mount point to be globally-writeable after mounting, as follows:

root # chmod 1777 /mnt/funtoo/tmp