User:Sakaki/Sakaki's EFI Install Guide/Final Preparations and Reboot into EFI

In this section, we'll be following along with Chapter 8 of the Gentoo handbook. However, we'll defer some of the configuration tasks mentioned there until the next chapter, when you have rebooted (mainly to help out those users who have chosen systemd as their target init, since systemd configuration is most easily done from within a system actually running systemd). The steps we'll be undertaking are:

1. Setting up the mountpoint tables /etc/fstab and /etc/mtab;
2. Concluding preparations, viz.:
   1. Emerging some necessary packages (which it will be useful to have in place before a reboot);
   2. Taking note of networking information;
   3. Configuring networking for use post-reboot (OpenRC users only)
   4. Setting up a root password for the new system; then
3. Cleanly dismounting the chroot, and restarting;
4. Logging in to your new system as the root user, directly at the target machine's keyboard.

Instructions are also provided at the end of this chapter to recover back to a chroot environment, should things not go as planned.

Please note that at the conclusion of this chapter there is a parting of the ways, depending on your previous choice of init system:

• users targeting OpenRC should continue following the regular guide Chapters 10-14; however
• users targeting systemd should instead follow the 'alternative track' Chapters 10-14.

The division point is clearly marked.

So let's get started!

Setting up the Mountpoint Tables

Per the Gentoo handbook, we first need to setup /etc/fstab, so that the system knows the location, mount point, filesystem type and mount options for the key system partitions. There are three such partitions (which we created earlier):

1. the root partition, which holds the system software, configuration files, and the superuser's home directory (device file path /dev/mapper/vg1-root);
2. the swap partition, which is used to extend the system's available memory, and can also be used for hibernation (device file path /dev/mapper/vg1-swap); and
3. the home partition, which holds the home directories of normal users (device file path /dev/mapper/vg1-home).

We need to add entries for each of these to fstab; so issue:

(chroot) livecd / #nano -w /etc/fstab

and then edit the file, so that the only uncommented lines (those not starting with a # symbol), are as follows:

FILE /etc/fstabSet the following as the only uncommented lines

/dev/mapper/vg1-root    /           ext4    defaults,noatime,errors=remount-ro,discard   0 1
/dev/mapper/vg1-swap    none        swap    defaults,noatime,discard    0 0
/dev/mapper/vg1-home    /home       ext4    defaults,noatime,discard    0 2

If you have a cd- or dvd-rom drive on your machine (the Panasonic CF-AX3 does not), you can also add the following additional line:

FILE /etc/fstabAdd the following additional line, if you have a cd-rom or dvd-rom drive

/dev/cdrom/             /mnt/cdrom  auto    noauto,user,ro 0 0

Save and exit nano.

In the /etc/fstab file:

• The first field describes the path to the partition's device file (NB - when this file is referenced, the initramfs-based init script will already have unlocked the LUKS partition and activated the LVM logical volumes, so we can safely use the device-mapper paths, as above).
• The second field shows the mount point.
• The third field shows the filesystem type. I have assumed (per the tutorial instructions) that you have used ext4 for the root and home partitions; if you chose something different, make sure to reflect it here. The use of auto for the optional cd-rom makes the operating system guess the filesystem type, which is useful with removable media.
• The fourth field contains the mount options; these choices here are described in more detail below.
• The fifth field is used by the dump command to denote which filesystems require dumping. It's generally fine to leave this as 0 (do not dump) in all cases.
• The sixth field is used by fsck to determine the order filesystems are integrity checked at boot time. A 0 indicates no check. The root filesystem should have (as here) a 1 to force it to be checked first, and then all other persistent filesystems can have 2 specified (so they are checked together, but after the root filesystem).

Note
We don't need to mount /boot here, since this is a UEFI system and our /boot is simply a regular directory, used as a marshalling ground. Nor do we specify our /boot/efi mountpoint, since that will be dealt with explicitly by buildkernel (and the UEFI boot sequence), and we'll generally want to be able to remove the USB key once the machine has booted anyway (for security).

Note
There is no need to place entries for /proc and /dev into /etc/fstab; these will be mounted automatically.

Here are the specific mount options selected above, and their meaning:

Partition	Mount Option	Description
root	defaults	Specifies the baseline options: rw (mount the filesystem read/write); suid (allow set-user-identifier / set-group-identifier bits to take effect); dev (interpret character or block special device files on the filesystem); exec (permit execution of binaries); auto (automatically mount at boot); nouser (forbid non-root users to explicitly mount) and async (perform I/O to the filesystem asynchronously).
	noatime	This prevents file access times from being recorded; these are not generally needed, and this setting is particularly important for performance if you use a solid-state drive (SSD). Incidentially, noatime is a superset of nodiratime.
	errors=remount-ro	This causes the root system to be remounted read-only if errors are encountered, for safety.
	discard	This allows the TRIM command to work, provided that you have also allowed this in LUKS via the root_trim=yes kernel command-line flag (actually passed through to the init script) in /etc/buildkernel.conf, as described earlier. TRIM will improve performance on SSDs as they get full, but make sure you are comfortable with the possible security implications of turning it on.
swap	defaults	Sets baseline options as per the root partition, above. Note that you do not need sw or swap here, although they are commonly seen.
	noatime	See above.
	discard	See above.
home	defaults	Sets baseline options as per the root logical volume, above.
	noatime	See above.
	discard	See above.
cd-rom (optional)	noauto	Do not attempt to mount automatically at boot.
	user	Allow a non-root user to explicitly mount (desirable for removable media). Note that this implies: noexec (prevent execution of binaries on this filesystem); nosuid (prevent set-user-identifier / set-group-identifier bits from taking effect) and nodev (do not interpret character or block special device files on the filesystem). If any of that bothers you, be sure to override with a subsequent option.
	ro	Mount the filesystem read-only.

Per the Gentoo wiki article on systemd, the mounted file systems table (/etc/mtab) must be a symlink to /proc/self/mounts (this is now also required for OpenRC), so issue:

(chroot) livecd / #ln -vsf /proc/self/mounts /etc/mtab

Important
Please ensure you carry out the above step! Your system will not function correctly if you omit it.

Some Concluding Preparations

It will be useful to have the DHCP daemon, wpa_supplicant and screen software available immediately upon reboot. They're not yet installed on the chroot operating system, only on the 'outer' host, so let's emerge them now. Issue:

(chroot) livecd / #emerge --ask --verbose net-misc/dhcpcd net-wireless/wpa_supplicant app-misc/screen

... additional output suppressed ...
Would you like to merge these packages? [Yes/No] <press y, then press Enter>
... additional output suppressed ...

Next, take note of your current network interface name - this will be the same after a reboot, and knowing it will be useful during systemd/OpenRC configuration. Issue:

(chroot) livecd / #ifconfig

and look for a record name similar in format to enp0s25 (your system will most likely have a different name - in this particular case it refers to a ethernet card on PCI (p) bus 0, slot 25).

Note
If you are using a wireless adapter for the install, your identifier string will start with wl, not en. You will have made a note of the relevant name earlier.

Next, we must set up a root password. Yes, we did indeed set up a root password earlier, but that was for the host operating system on the target machine, and we are about to discard that and boot directly into the new (currently chroot-ed) one. As such, we need to set a fresh root password within the chroot. Issue:

(chroot) livecd / #passwd root

New password: <enter your new password>
Retype new password: <enter your new password again>
passwd: password updated successfully

Important
Be sure to write this password down somewhere safe! You will require it to log in shortly.

Similarly, we need to ensure that the sshd setup inside the chroot will allow root to log-in (while we complete our set-up, at any rate). Issue:

(chroot) livecd / #sed -i 's/^#PermitRootLogin.*$/PermitRootLogin yes/' /etc/ssh/sshd_config

Note
As you may recall (from when we edited the outer host's /etc/ssh/sshd_config file earlier), from release 7.0 of OpenSSH, the defaults have changed to prohibit password-based login as root, hence the reason for the above edit.

We also need to make sure that the app-editors/nano editor does not accidentally get removed later in the installation (as it is only 'held in place' by a virtual — virtual/editor — at the moment). Issue:

(chroot) livecd / #emerge --noreplace app-editors/nano

Note
The --noreplace option ensures that the package is not rebuilt if already installed. In any case, it will be added to the @world set (/var/lib/portage/world). It's a useful idiom to be aware of.

Configure Networking for Post-Reboot Use (OpenRC Users Only)

Note
If you selected systemd earlier as your target init system (the default now being OpenRC in this guide), you should click here to skip this section: the instructions contained herein are OpenRC-specific.

To make sure you have your network interface available after restart, be sure to add net-misc/dhcpcd to the default runlevel. Issue:

(chroot) livecd / #rc-update add dhcpcd default

Note
We will disable this service later, when net-misc/networkmanager takes over (with GNOME). However, we leave it enabled-on-boot for now for convenience.

You should also ensure that the sshd service will automatically start on boot, so you can log in remotely; issue:

(chroot) livecd / #rc-update add sshd default

Warning
As currently configured, sshd allows some rather insecure things, such as remote log-in as root. While this is useful at the moment (and relatively benign given the machine is on a subnet, presumably behind a firewall), do consider editing the /etc/ssh/sshd_config file once all configuration is complete, to disallow this. You should also consider moving to public key authentication for ssh login, once everything else is in place (at the end of the install).

Next, if you are performing this install over WiFi, we need to ensure that wpa_supplicant can be started by dhcpcd (NB: if using wired Ethernet for the install, you should skip these commands). Issue:

localhost ~ #mv -v /etc/wpa.conf /etc/wpa_supplicant/wpa_supplicant.conf

Note
The /etc/wpa.conf file was created earlier.

Now, we also need to prepend one line to that configuration file, so that dhcpcd can invoke wpa_supplicant directly. Issue:

(chroot) livecd / #nano -w /etc/wpa_supplicant/wpa_supplicant.conf

and prepend the following line to the file:

FILE /etc/wpa_supplicant/wpa_supplicant.confPrepend the following line, to allow dhcpcd invocation

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel

Leave the rest of the file as-is. Save, and exit nano.

Also, as of version 6.10.0 of net-misc/dhcpcd, you need to ensure that the appropriate 'hook' script is in place to start and stop net-wireless/wpa_supplicant on each wireless interface. So, to ensure that you have this file in place, issue:

(chroot) livecd / #if ! [ -s /lib/dhcpcd/dhcpcd-hooks/10-wpa_supplicant ]; then cp -vf /usr/share/dhcpcd/hooks/10-wpa_supplicant /lib/dhcpcd/dhcpcd-hooks/; fi

Note
This is a deliberately minimal setup, as we'll only use it until net-misc/networkmanager takes over (with GNOME); for more information on the ctrl_interface option, and others you may wish to set, see these notes.

Assuming you want to use DHCP on your interface (wired or wireless), that's all you need to do: pace the Gentoo Handbook, there's no need to add /etc/init.d/net.<ifname> symbolic links, edit /etc/conf.d/net etc.

However, if you have more complex networking requirements (static IP, proxies etc.) should consult the relevant section of the Handbook. Also, if you have more complex WiFi configuration requirements, you may also find these notes useful.

Cleanly Dismounting the chroot and Restarting

Almost there! Now we have to exit the chroot in both our screen virtual consoles, quit both of those consoles (thereby exiting screen), unmount the various logical volumes, deactivate the LVM volume group, and close out the LUKS partition. Issue:

(chroot) livecd / #exit

then:

livecd ~ #exit

The first exit exits the chroot in the first screen virtual console, the second exits that console itself. Now do the same for the second virtual console (which you'll automatically be dropped out to):

(chroot:2) livecd / #exit

then:

livecd ~ #exit

[screen is terminating]

Unmount everything (and turn off swap), deactivate LVM, and close LUKS:

livecd ~ #sync

livecd ~ #swapoff -v /dev/mapper/vg1-swap

livecd ~ #umount -lv /mnt/gentoo/home

livecd ~ #umount -lv /mnt/gentoo/dev{/shm,/pts,}

livecd ~ #umount -Rv /mnt/gentoo

livecd ~ #vgchange --available n

livecd ~ #cryptsetup luksClose gentoo

Note
In the unlikely event you are unable to execute the vgchange --available n command, perhaps due to some components reported as being still mounted from within the LVM logical volume, simply proceed with the following reboot anyway. Your system should still be in a consistent state due to the sync command. For avoidance of doubt, this point will not affect most users, who should find their system dismounts cleanly.

Now we're ready to restart. Ensure your boot USB key is still inserted into the target machine (as well as the minimal install USB key, at this point), and issue:

livecd ~ #reboot

Note
If you have been using your system in legacy (non-UEFI) boot mode up to this point — and, for avoidance of doubt, this won't apply to the majority of users, who should therfore simply ignore this note — then you will need to remove the boot USB key after rebooting; then, as your system starts to come back up, enter into your system's BIOS, enable UEFI mode (without secure boot enabled) and restart once more.

Your ssh session will exit. If all is well, shortly after this your target machine will restart, and, because buildkernel automatically placed your new, EFI-stub kernel at the top of the boot list, it should then proceed — without any further intervention required — to boot this kernel off of the boot USB key.

Logging in Directly to the New System

After some initialization, you should then be prompted for a passphrase to unlock the gpg keyfile for your LUKS partition (this is the passphrase you set up earlier). Type this in (directly at the target machine keyboard), and press Enter.

Shortly after this, assuming that your passphrase is correct, you'll be presented with a login prompt. Enter 'root' as the user (again, directly at the keyboard, without quotes), press Enter, and then type the root password you set up above, and press Enter again.

Note
On certain versions of systemd, you may be notified that the plymouth-start.service unit failed during boot. As we have not yet enabled plymouth using buildkernel, this is to be expected, and the error may be ignored at this point.
For avoidance of doubt, this (minor) issue does not impact OpenRC users.

With luck, you should now be logged in! If this is the case, congratulations, you have a encrypted system which boots from UEFI and uses (depending on your choice earlier) OpenRC or systemd. You should now remove the minimal install USB key, so that only the boot USB key (the smaller capacity one) remains inserted, then click here to complete the configuration of your init system (and other) settings.

Note
If you were able to successfully boot, then please note that the minimal install image USB key is no longer required for the remaining steps in this tutorial — as such, you may, at your option, either keep it around for 'fallback recovery' purposes (in case anything should go wrong later — the process for command-line recovery is detailed below), or, reformat it for other use.

If however, for some reason you weren't able to boot, then read on.

How to Recover if Things Go Wrong

Note
If you managed to reboot your new system and log in successfully, then you should skip this step, it is only necessary for those attempting to recover back to a chroot system after a failed boot.

The following are short-form instructions to get you back into a chroot environment again, so that you can attempt to fix whatever problem prevented you from booting under UEFI. I have included backlinks throughout, so you can hop up to where these steps were first taken, and read in more detail about what is involved - the style of what follows is rather telegraphic.

First, re-insert your minimal install USB key into the target machine (leaving the boot USB key inserted as well, since we'll need it to unlock the LUKS partition), and restart the system. As the machine comes up, re-enter the BIOS, and set (if it is not already) the (minimal install) USB key to be the top UEFI boot device (original instructions here). Save the BIOS settings and exit, thereby rebooting into the Gentoo minimal install system (original instructions here). As before, hit Enter at the GRUB screen, remember to select the correct keymap etc. Then, since the boot image itself has no persistence, issue (directly on the target machine's keyboard):

livecd ~ #passwd root

New password: <enter your (host system) root password>
Retype new password: <enter your (host system) root password again>
passwd: password updated successfully

Remember (original instructions here), you are setting up a password for the 'outer', host system here — root's password inside the chroot will be retained (and different), but we haven't remounted the chroot yet.

Next, ensure that your networking is up. Follow the appropriate instructions below.

If installing over wired Ethernet, simply wait for a little while (if necessary for address allocation to complete), and then note your IP address, using ifconfig (original instructions here):

livecd ~ #ifconfig

Then click here to skip to the next step. If, instead, you are installing over WiFi, you need to re-create your configuration file (original instructions here). Issue:

livecd ~ #wpa_passphrase "ESSID" > /etc/wpa.conf

<then type your WiFi access point passphrase (without quotes) and press Enter>

Note
As before, substitute the correct name for "ESSID" in the above.

Lock down the file's access permissions (to root only) and check that its contents look sane. Issue:

livecd ~ #chmod -v 600 /etc/wpa.conf

livecd ~ #cat /etc/wpa.conf

Assuming that looks OK, we can connect. Issue:

livecd ~ #wpa_supplicant -Dnl80211,wext -iwlp2s0 -c/etc/wpa.conf -B

Note
Substitute the wireless network interface name you wrote down previously for wlp2s0 in the above command.

Then note your IP address:

livecd ~ #ifconfig wlp2s0

Note
Again, substitute the wireless network interface name you wrote down previously for wlp2s0 in the above command.

Note
As before, if you need to use a fixed IP address, a proxy, IPv6, or an unencrypted WiFi connecction, please see Chapter 3 of the Gentoo handbook for more details.

Now start sshd (original instructions here):

livecd ~ #sed -i 's/^#PermitRootLogin.*$/PermitRootLogin yes/' /etc/ssh/sshd_config

livecd ~ #/etc/init.d/sshd start

This will generate a new set of keys, so take a note of the RSA and ED25519 fingerprints for the host key, as shown with:

livecd ~ #ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub

livecd ~ #ssh-keygen -l -f /etc/ssh/ssh_host_ed25519_key.pub

Now switch to your helper PC. Note that, if the target PC's IP address is the same as it was originally (quite likely, even with DHCP), then the helper will already have a note of its previous fingerprint, and will refuse to connect via ssh (since a mismatched fingerprint might suggest a man-in-the-middle attack). Therefore, we need to remove the old fingerprint record for the IP from ~/.ssh/known_hosts. Issue:

user@pc2 $sed -i '/^[^[:digit:]]*192.168.1.106[^[:digit:]]/d' ~/.ssh/known_hosts

Note
Substitute whatever IP address you got back from ifconfig for 192.168.1.106 in the above command.

and issue (original instructions here):

user@pc2 $ssh root@192.168.1.106

Check the key fingerprint and then, if it matches, continue as below:

... additional output suppressed ...
Are you sure you want to continue connecting (yes/no)? <type 'yes', then Enter>
... additional output suppressed ...
Password: <enter root password you just set>
... additional output suppressed ...

Note
Substitute whatever IP address you got back from ifconfig for 192.168.1.106 in the above command.

Once you are connected, we need to get screen running. Via the ssh connection on the helper PC (which is how you should enter all subsequent commands, unless otherwise specified), issue (original instructions here):

livecd ~ #screen

Next, we must mount the USB boot key's EFI system partition, so that we can use the keyfile on it to unlock the LUKS partition. Find out the device file name for the EFI partition on the USB boot key, by issuing (original instructions here):

livecd ~ #lsblk

We will refer to this as /dev/sdY1 in what follows, but of course on your machine it will be something like /dev/sdb1 or /dev/sdc1 (note that the initial /dev/ prefix is not shown in the lsblk output).

Next, create a temporary mountpoint, and mount it. Issue (original instructions here):

livecd ~ #mkdir -v /tmp/efiboot

livecd ~ #mount -v -t vfat /dev/sdY1 /tmp/efiboot

Note
Replace /dev/sdY1 in the above command with the path of first partition on the USB key, which you just located with lsblk, such as /dev/sdb1 or /dev/sdc1.

Now, we can open the LUKS volume. You'll need the passphrase (for the gpg keyfile) you set up earlier to do this:

livecd ~ #export GPG_TTY=$(tty)

livecd ~ #gpg --decrypt /tmp/efiboot/luks-key.gpg | cryptsetup --key-file - luksOpen /dev/sdZn gentoo

Enter passphrase
<type the passphrase for the gpg keyfile you setup earlier>
... additional output suppressed ...

Note
Replace /dev/sdZn in the above command with the device path for the LUKS partition, e.g., /dev/sda7. You can check this with lsblk (original instructions here).
Also, you may see some errors of the form device-mapper: remove ioctl on XXX failed: Device or resource busy; these can generally be ignored.

Note
You may get complaints about no LC_CTYPE known printed by pinentry; these can generally be ignored. See explanation in the original text.

Tip
Remember that if gpg gets stuck with a bad password in its cache for some reason, you can reset it by issuing:

livecd ~ #echo RELOADAGENT | gpg-connect-agent

Now we can bring up the LVM logical volumes, and mount them. Issue (original instructions here):

livecd ~ #vgchange --available y

livecd ~ #swapon -v /dev/mapper/vg1-swap

livecd ~ #mount -v -t ext4 /dev/mapper/vg1-root /mnt/gentoo

livecd ~ #mount -v -t ext4 /dev/mapper/vg1-home /mnt/gentoo/home

Next, unmount the USB boot key; issue (original instructions here):

livecd ~ #umount -v /tmp/efiboot

Ensure the date and time is set correctly. Issue:

livecd ~ #date

If necessary fix it by issuing (original instructions here):

livecd ~ #date MMDDhhmmYYYY

Note
Substitute MMDDhhmmYYYY in the above with the correct date/time string. For example, to set the UTC date/time to 5:12pm on February 9th 2017, you would issue

livecd ~ #date 020917122017

Next, make sure that the DNS information will still be valid after we chroot. Issue (original instructions here):

livecd ~ #cp -L /etc/resolv.conf /mnt/gentoo/etc/

cp: overwrite '/mnt/gentoo/etc/resolv.conf'? <type 'yes', then Enter>

Now, ensure that the various special files in /proc, /sys and /dev are available after a chroot. Issue (original instructions here):

livecd ~ #mount -v -t proc none /mnt/gentoo/proc

livecd ~ #mount -v --rbind /sys /mnt/gentoo/sys

livecd ~ #mount -v --rbind /dev /mnt/gentoo/dev

livecd ~ #mount -v --make-rslave /mnt/gentoo/sys

livecd ~ #mount -v --make-rslave /mnt/gentoo/dev

Now we can actually enter the chroot. Issue (original instructions here):

livecd ~ #chroot /mnt/gentoo /bin/bash

Remember to source our profile correctly and set a prompt hint. Issue (original instructions here):

livecd / #source /etc/profile

livecd / #export PS1="(chroot) $PS1"

Finally, we can setup a second virtual console inside screen (just as we did before), which will be useful to e.g., monitor the status of long emerges. Press Ctrla then c to start a new console. Then in that new console (which is back outside the chroot, to begin with) enter:

livecd ~ #chroot /mnt/gentoo /bin/bash

followed by

livecd / #source /etc/profile

livecd / #export PS1="(chroot:2) $PS1"

Now hit Ctrla then p to get back to the original console.

That's it! You can now proceed to edit your chroot-ed system (and hopefully, to fix it). It is impossible to be specific as to what may have caused a problem, but some likely candidates include:

• Incorrect kernel configuration. In this case, run buildkernel --ask --verbose, enter the graphical kernel configuration editor when prompted, change the appropriate kernel settings, and then save and exit the editor. The build will continue with your modified configuration. (A problem of this sort is most likely to occur if you have already started to dabble with the configuration, since the standard flow in this tutorial assumes you have used the /proc/config.gz config from the running minimal install system kernel - which is therefore to some extent 'known good' - as a basis).
  • In particular, if you elected to use OpenRC boot earlier (and not the default systemd), and received an error similar to The filesystem /dev/mapper/vg1-root <...> does not contain a valid init=<...>/systemd after entering your LUKS passphrase, then you have not correctly set up the INITSYSTEM variable in /etc/buildkernel.conf. Fix this (either by editing /etc/buildkernel.conf or using buildkernel --easy-setup and choosing option "7) set init system", then run buildkernel --ask --verbose again.
• Buggy version of buildkernel. Please note that buildkernel version 1.0.24 has a bug that affects booting and should not be used (earlier and later versions are not affected). Issue buildkernel --version to check, and if you do have the affected 1.0.24 version installed, update it (using emaint sync --repo sakaki-tools && emerge -av --update buildkernel), then rebuild your kernel and reboot.
• Missing packages. For example, you may have forgotten to install e.g., net-misc/dhcpcd prior to reboot, preventing you from accessing the network properly. If this is the case, simply emerge the required software within the chroot, and then try again. There is no need to re-run buildkernel in this case.
• Password not set for root. If for any reason you forgot to set a root password for the new system (as instructed above, when you were chroot-ed in originally), then your attempt to log in will have been rejected. This is easily fixed by using passwd root.
• Wrong keymapping causing mangled passwords. If the system would not accept your gpg keyfile passphrase on reboot, but you were able to successfully unlock it when re-entering the chroot above, or, if the system would not accept your root password after a restart, then you may have not setup the KEYMAP variable in /etc/buildkernel.conf correctly. See this earlier discussion for further details. (These issues can also generally be ameliorated (for most locales) through the use of only standard English letters in your passphrases, as mentioned previously.) Review, and if necessary, change your boot-time keymap by using buildkernel --easy-setup, and then re-run buildkernel --ask --verbose.
• Problems with UUIDs. The buildkernel script tries to ensure that the UUIDs you have passed it (in /etc/genkernel.conf above) are valid, but it is still possible to make a mistake (e.g. if you have more than one LUKS partition on your system, for example). Double check these values, and, if necessary, change them (by using buildkernel --easy-setup) and then re-run buildkernel --ask --verbose.
• BIOS configuration problems. A total failure of your new system to even try to start (or if you get Windows instead!) is likely to indicate some issue with your BIOS settings. Are you sure your USB boot key is at the top of the UEFI boot order (as it should be, if buildkernel has done its job)? And that secure boot is disabled at this point, and that fast boot is off? Double check these points, then try again — for hints about entering and modifying the UEFI BIOS settings, please refer to these earlier notes. (You should also double-check that the first (and only) partition on your USB boot key is marked as an EFI system partition and is formatted fat32; see this discussion.) A very few EFI systems also do not look for a boot executable under the standard /EFI/Boot/bootx64.efi path, but instead will use /EFI/Microsoft/Boot/bootmgfw.efi. If that's the case for your target machine, change the EFI boot file path using buildkernel --easy-setup, then re-run buildkernel --ask --verbose.

Note
If you try to fix things that involve using the graphical kernel configuration editor, and you are connected over ssh from your helper machine, be aware that you may get some pretty strange characters displayed. This can happen if your helper's locale is not present on the target (in the host operating system that is, not the chroot, since sshd is running in the former context). In this case, simply open up a chroot directly at the target's keyboard, and perform the buildkernel from there; i.e., directly at the machine, issue:

livecd ~ #chroot /mnt/gentoo /bin/bash

followed by:

livecd / #source /etc/profile

livecd / #export PS1="(chroot:direct) $PS1"

and then:

(chroot:direct) livecd / #buildkernel --ask --verbose

Once you have made your changes and are ready to have another go at rebooting, simply proceed from the section "Cleanly Dismounting the chroot and Restarting" in the main text. Good luck!

Next Steps (and Fork in the Road)

Now that you have successfully booted into Gentoo from UEFI, we can proceed to configure your system. At this point, you need to follow one of two tracks for the final set of chapters (10-14), depending on your earlier choice of init system:

• users targeting OpenRC (the default) should click here to go to the next chapter on the regular track, "Completing OpenRC Configuration and Installing Necessary Tools"; whereas
• users targeting systemd should instead click here to go to the next chapter on the alternative track, "Configuring systemd and Installing Necessary Tools".

Notes

< Previous	Home	Next (OpenRC) >
		Next (systemd) >