User:Sakaki/Sakaki's EFI Install Guide/Using Your New Gentoo System

In this (final) section, we'll consider a number of miscellaneous (but important) topics regarding your new system. Although this final part of the tutorial has no precise analogue in the Gentoo manual, it logically relates to Chapter 12.

The topics we'll briefly cover are:
 * recapping how to boot to Linux from Windows (and vice versa);
 * keeping your machine up to date;
 * migrating your kernel to the internal hard drive (optional);
 * and how to dispense with the USB key entirely (also optional);
 * tweaking GNOME; and
 * installing a firewall, and other applications.

Let's go!

Booting into Linux or Windows (Recap)
With the setup you have just carried out, you can easily boot your target PC into either Gentoo Linux or Windows 8, as desired. Here's a brief recap of how to go about it (with links back to the more detailed explanations in the body of the text, where relevant):
 * If you power up the machine without the boot USB key inserted, Windows will always load automatically. You can do this safely even if you hibernated your Linux session last time (assuming you had no Windows partitions mounted in Linux!).
 * All your Linux data is ultimately held within an encrypted LUKS partition, and so cannot be 'snooped' by malware running in Windows. Nor can Windows software read your gpg keyfile or kernel, as the boot USB key is not physically present when Windows is running.
 * Windows updates etc. should leave the LUKS partition entirely unaffected (and cannot access the boot USB key either, assuming you don't insert it mid-session).
 * If you are running Windows 8, and wish to reboot into Linux instead, be sure to restart the machine from Windows (not shut it down - unless you have disabled hybrid shutdown as was recommended at the start of the tutorial). Insert the boot USB key while the system is closing down prior to the reboot. Then, immediately the machine commences restarting, enter the BIOS (the key combination needed to do this varies from machine to machine, it is on the CF-AX3). If you set one earlier, you'll need to enter your BIOS password at this point. Then, choose "Gentoo Linux (USB Key)" as the highest priority EFI boot entry, save changes and restart (if the BIOS does not immediately recognize the USB key, you may need to do the 'save changes and restart' cycle twice). A more detailed exposition of how to do this on the CF-AX3 was presented earlier in the text. The machine should then restart into Linux as usual.
 * Now, if you are running Linux, and then power down the machine, then power it back up with the USB key inserted, it should start up Linux again automatically (you'll have to enter your LUKS keyfile gpg passphrase (the one you created earlier) to gain access of course). It is entirely safe to remove the boot USB key once you get to the GNOME login screen (and indeed, it is recommended that you do so, for security). You can do any work you like under Linux, power the machine down, suspend or hibernate it, without needing to re-insert the boot USB key. Then:
 * If you suspend (sleep) the machine from Linux, you can come back out of suspend without needing to re-insert the key (just slide the power button).
 * If you hibernate the machine from Linux, insert the boot USB key immediately before powering up again. Upon restart, you'll have to enter the GPG-encrypted LUKS keyfile passphrase, and should then be presented with a GNOME login prompt (as before, you can remove the boot USB key at this point). Log in, and you'll find your desktop the way you left it on hibernation.
 * If you power the machine off from Linux, simply remember to insert the USB key before sliding the power key again (otherwise you'll reboot into Windows, as above).
 * Similarly, if you have hibernated from Linux, and power back up without re-inserting the boot USB key, your machine will come up in Windows 8. This isn't a problem (unless you had any of the Windows partitions deliberately mounted in your Linux session!), because you can use Windows as necessary and then, when done, follow the process above to restart back into Linux again (it'll remember that you hibernated, and come back into your old session).

The whole process is easier to do in practice than it is to describe! It has the advantage of not requiring multiple EFI system partitions on the machine's main drive (something which Microsoft specifically cautions is unsupported under Windows ), nor a separate bootloader. Furthermore, Windows 8 will sometimes overwrite the EFI boot list anyway, even when a bootloader is used, so taking that approach doesn't necessary buy you anything.

If you would like to use Windows 8's EFI system partition (the one on the internal drive) to store your kernel (or even dispense with the need for a USB key during boot altogether), instructions for doing so will be provided later in this chapter.

Keeping Your Machine Up to Date
The genup tool makes it easy to keep your machine (kernel and packages) up to date. To perform a full update at any time, first open a root terminal in GNOME (if you don't already have one open): press the, and type 'terminal', then press. A standard-issue terminal window should open. Become root:

The password required here is the one you set up earlier in the tutorial (and have used when ssh-ing in).

Ensure that your boot USB key is inserted (this will be required if there is a kernel upgrade). Then, in this terminal, issue:

and the update will proceed automatically (the --dispatch-conf option means that, although not running in interactive mode per se, you will be prompted to resolve clashing changes to configuration files, should any arise, and the --deploy-from-staging</tt> will copy over any new kernel to the boot USB key, once built). When the process completes (you get the message "All done</tt>"), remove the boot USB key again, and close out the terminal.

If the output of genup</tt> informed you that a new kernel has been built, you should reboot your machine at this point to start using it.

<span id="automating_genup">Automating genup</tt> (Optional)
To ensure you don't forget updates, you can schedule genup</tt> to run automatically (this is entirely optional, of course). One simple approach is to use to have it executed every night (at around 3am on most systems; check  for details ).

To set this up, first open a root terminal in GNOME (if you don't already have one available): press the, and type 'terminal', then press. A standard-issue terminal window should open. Become root:

The password required here is the one you set up earlier in the tutorial (and have used when ssh</tt>-ing in).

Then issue:

Then <span id="genup_cron_file">put the following text in the file:

Save and exit the nano</tt> editor, and make the file executable:

(You can now close out the root terminal if you have no further use for it.)

<span id="overnight_genup">That's it! Your system will now attempt to update each night, without requiring any input from you. Also, because you have not specified --deploy-from-staging</tt> here, there's no need to have your boot USB key inserted when the process runs (any new kernel will still be built, but then simply retained in the staging area at, until you issue buildkernel --copy-from-staging</tt>, as described shortly).

Although this is automatic, you do need to do a bit of checking periodically that this worked OK (each morning, say). To do this, open a root terminal in GNOME (as just described), and issue:

If the tail of the log just printed contains text similar to the below:

then, as instructed, you need to run dispatch-conf</tt>; so do so now:

See the explanation earlier in this tutorial for how to use dispatch-conf</tt>.

<span id="deploy_batch_kernel">Next, if the tail of the log contains text similar to the below:

then you need to copy it across (it has already been built in the staging area). Insert your boot USB key, then issue:

When this completes (it shouldn't take long), remove the boot USB key, and close out the root terminal if you have no further use for it (or, alternatively, leave the key inserted and reboot, to start using your new kernel immediately).

<span id="switching_to_webrsync">Switching to emerge-webrsync</tt> for Security (Optional)
This is an entirely optional step, but you may choose to update your local portage tree with only signed snapshots, as opposed to using rsync</tt>. This is considerably less efficient in terms of bandwidth, but does provide protection against rogue rsync</tt> mirrors adding or changing code or packages.

To make use of this feature, follow the instructions under "Pulling Validated Portage Tree Snapshots" in the Gentoo Handbook (summarized again below for convenience).

First, open a root terminal in GNOME (if you don't already have one available): press the, and type 'terminal', then press. A standard-issue terminal window should open. Become root:

The password required here is the one you set up earlier in the tutorial (and have used when ssh</tt>-ing in).

Then make a directory to hold the necessary gpg</tt> public keys:

Next, download and accept the Gentoo release engineering keys, as specified on the Release Engineering page. You need at least the fingerprint of the key described as "Gentoo Portage Snapshot Signing Key (Automated Signing Key)":

You can set the key's trust at this point if you like. However, it isn't necessary (<tt>emerge-webrsync</tt> just looks at the exit value of <tt>gpg --verify</tt>). Next, edit, and enable support for validating the signed Portage tree snapshots. Issue:

and append:

Save and exit the <tt>nano</tt> editor.

There is no need to disable conventional <tt>rsync</tt> (pace the handbook), as it won't be used unless you explicitly call it (with <tt>emerge --sync</tt>). Note however that you must take care to use the <tt>-w</tt> option with <tt>eix-sync</tt> (so that it calls <tt>emerge-webrsync</tt>, rather than <tt>emerge --sync</tt>, internally). If you are using <tt>genup</tt> to manage your updates, this is taken care of for you automatically (it will notice that the <tt>webrsync-gpg</tt> feature has been set and act accordingly).

Try it out now, to make sure everything is still working:

Note that this will take quite a bit longer than before, as it has now to pull down the full Portage tree each time. However, if you have automated the process to run overnight, this shouldn't impact you too much.

When completed, close out the root terminal if you have no further use for it.

<span id="migrating_off_usb_key">Migrating Off the Boot USB Key (Optional)
Up until now, we have been using a boot USB key to hold your (stub EFI) kernel and GPG-encrypted LUKS keyfile. This approach has a number of advantages:
 * It let us get around the 'EFI chicken and egg' problem - namely that it is only possible to modify the EFI boot list when already booted under EFI - by exploiting the exception that most UEFI BIOSes will boot specially named EFI images on removable drives. Of course, now we have an EFI system running, this advantage is moot.
 * It provides dual factor security - you need both the keyfile and its passphrase to access the LUKS partition. This confers a degree of protection against hardware keyloggers etc., which a 'passphrase only' (or, indeed, 'keyfile only') LUKS approach would lack.
 * Similarly, if you physically destroy the USB key and all backups, your LUKS data will be gone forever. Even someone with your GPG passphrase would be unable to recover it. Of course, this is a double-edged sword!
 * If the system is booted without the key inserted, it will automatically come up in Windows 8.
 * When Windows is running, malware is unable to see your kernel image (assuming you leave the USB key unplugged) nor can it copy your GPG-encrypted keyfile.
 * Similarly, there is no risk of Windows accidentally (during an upgrade, for example) overwriting your kernel, or experiencing problems because your kernel has consumed too much space in the (internal hard drive) EFI system partition.
 * You can use a large-capacity USB key, with plenty of room for snapshot backups etc.

Nevertheless, some users may prefer to use their internal hard drive's EFI system partition to store the kernel (retaining the USB key for GPG-encrypted keyfile only, to preserve dual-factor security). Others may like to go even further, and remove the need for the USB key altogether on boot (relying on a passphrase only, Ubuntu-style ). While there are six logical possibilities here (and all are simple to achieve via <tt>buildkernel --easy-setup</tt>), not all make sense, as the table below demonstrates:

Accordingly, instructions are provided below for migration from option 1 (which you have now) to options 4 and 6, below.

<span id="option_4_migration">Using the Internal Drive EFI System Partition for the Kernel (Option 4)
This <span id="option_4_comments">is a somewhat attractive option. By using the (Windows) EFI system partition to store the kernel, boot times are reduced, and you can perform full upgrades (including any kernel deployment) without having to insert the USB key. However, you may experience issues due to the lack of space in the internal drive EFI system partition, particularly if you have not slimmed down your kernel configuration (as described earlier).

When using the internal drive EFI system partition, Windows malware can read your kernel (and configuration), although it is protected against tampering by its cryptographic signature (of course, malware with access to the Microsoft private keys could modify your kernel and resign it...).

A final point to bear in mind is that, whenever you wish to restart from Linux to Windows, you will have to change the EFI boot list explicitly, using the <tt>efibootmgr</tt> tool (the use of which was described previously). You can no longer simply restart the machine without the boot key present (as you can with 'option 1').

With all that in mind, if you still wish to migrate to an 'option 4' configuration, proceed as follows.

First, open a root terminal in GNOME (if you don't already have one available): press the, and type 'terminal', then press. A standard-issue terminal window should open. Become root:

The password required here is the one you set up earlier in the tutorial (and have used when <tt>ssh</tt>-ing in).

Next, use the <tt>buildkernel --easy-setup</tt> tool to make the necessary changes to.

Issue (the following session is an example only; the values output will obviously vary for your machine):

Now rebuild the kernel (it will attempt to save the result to the internal EFI system partition now, not to the boot USB key):

Once the build completes (make sure it works successfully, and that you get the prompt "<tt>All done!</tt>" at the end), ensure your USB (boot) key is inserted, and restart your machine (you can do this from within GNOME, by clicking on the 'power' icon (in the top right of the screen), clicking on the 'power' button in the dropdown menu that then appears, and then clicking on the 'Restart' button in the dialog).

The machine should then power cycle (you will be cleanly logged out of GNOME first). When it restarts, as before, you will need to enter your LUKS keyfile <tt>gpg</tt> passphrase (the one you created earlier), directly at the target machine keyboard to unlock the LUKS partition. You should then be able to log into GNOME as usual.

<span id="option_6_migration">Completely Removing the Need for a Boot USB Key (Option 6)
This is the most convenient option for everyday use, since no USB key is required at all: the backup LUKS passphrase is prompted for at boot time, and the kernel is contained on the internal drive (Windows) EFI system partition. However, dual-factor security is lost with this approach. It is otherwise similar to option 4 above, so please read through the comments there before continuing.

If you still wish to migrate to an 'option 6' configuration, proceed as follows.

First, open a root terminal in GNOME (if you don't already have one available): press the, and type 'terminal', then press. A standard-issue terminal window should open. Become root:

The password required here is the one you set up earlier in the tutorial (and have used when <tt>ssh</tt>-ing in).

Next, use the <tt>buildkernel --easy-setup</tt> tool to make the necessary changes to.

Issue (the following session is an example only; the values output will obviously vary for your machine):

Now rebuild the kernel (it will attempt to save the result to the internal EFI system partition now, not to the boot USB key):

Once the build completes (make sure it works successfully, and that you get the prompt "<tt>All done!</tt>" at the end), remove your USB (boot) key (you won't need it any more!), and restart your machine (you can do this from within GNOME, by clicking on the 'power' icon (in the top right of the screen), clicking on the 'power' button in the dropdown menu that then appears, and then clicking on the 'Restart' button in the dialog).

The machine should then power cycle (you will be cleanly logged out of GNOME first). When it restarts, as before, you will need to enter your LUKS fallback passphrase (the one you created earlier), directly at the target machine keyboard to unlock the LUKS partition. You should then be able to log into GNOME as usual.

<span id="tweaking_gnome">Tweaking GNOME
One of the saving graces of the GNOME 3 shell interface (the desktop GUI) is its extensibility. By using JavaScript-based plug-ins known as shell extensions, you can modify the behaviour of your system considerably (changing the way window placement works, adding things like weather and system performance applets, changing app search options etc.).

The simplest way to get plugins is via the <tt>Gnome Tweak Tool</tt> application. From within your GNOME desktop, press, then type <tt>tweak</tt> and press. The tool that appears allows you to change many of the default GNOME behaviours that you may find annoying (such as attached modal dialogs!), add startup applications, etc., so its well worth browsing through the options.

To install extensions, however, click on the 'Extensions' tab on the left side of the app, and then navigate to the extension you want on the right (simply move the slider to "ON" for any you wish to enable). If you scroll to the bottom of this list, you'll see a link entitled "<tt>Get more extensions</tt>". Click on this, and a web page will open with a list of downloadable plug-ins. You can search the list for topics of interest. Again, if you want to use a plug-in, simply click on it to open its detail page, move its slider to "ON", and it should download and start running automatically:



<span id="install_firewall_etc">Installing Other Applications, Including a Firewall etc.
As currently configured, your machine is not running a firewall - but I'd definitely recommend installing one! Configuring a firewall is beyond the scope of this tutorial, but a good place to start is Chapter 1 of Michael Rash's book Linux Firewalls. The ArchLinux wiki also has some useful information on using <tt>iptables</tt> (the Linux kernel firewall based on <tt>netfilter</tt>) under <tt>systemd</tt>.

Other than that, what you install on your machine is now up to you! It's worth reading this introduction in the Gentoo handbook regarding searching for and installing software. The basic process, of course, is straightforward. Suppose, for example, that you'd like to install the Firefox web browser...

To do this, first, open a root terminal in GNOME (if you don't already have one available): press the, and type 'terminal', then press. A standard-issue terminal window should open. Become root:

The password required here is the one you set up earlier in the tutorial (and have used when <tt>ssh</tt>-ing in).

Next, search for the application. You can use <tt>eix</tt> to do this: for example:

Reviewing <tt>eix</tt>'s output, you can see that the package you want is. To install it, use the familiar <tt>emerge</tt> rubric:

If there are any USE flag problems or license issues reported, edit or  accordingly (see text earlier for a description of these), then try again.

Sayonara ^-^
Well, that's it! You now have a fully operational Gentoo dual-boot system!

Enjoy!

(Click here to go back up to the top-level page.)

Acknowledgements
We would like to thank the following authors and editors for their contributions to this guide: