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

From Gentoo Wiki
Jump to: navigation, search


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. Before the OS boots, modifying the BIOS settings so that non-secure UEFI mode is used, then restarting again.

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 systemd should continue following the regular guide Chapters 10-14; however
  • users targeting OpenRC 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:[1]

  • 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).[2] Incidentially, noatime is a superset of nodiratime.[3]
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,[4] 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.[5]
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[6]), so issue:

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

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).[7]

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.[8]

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

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

Note
If you selected systemd earlier as your target init system (the default), 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[9] (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.[10] 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.[11]

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 ~ #swapoff -v /dev/mapper/vg1-swap
livecd ~ #umount -lv /mnt/gentoo/home
livecd ~ #umount -lv /mnt/gentoo/dev{/shm,/pts,}
livecd ~ #umount -lv /mnt/gentoo{/proc,/sys,}
livecd ~ #vgchange --available n
livecd ~ #cryptsetup luksClose gentoo

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

Your ssh session will exit. Immediately your target machine starts to come back up again, enter the BIOS setup screen.

Selecting UEFI Boot Mode in the BIOS and Restarting!

As mentioned earlier, the exact method of entering the BIOS varies greatly from machine to machine (as does the BIOS user interface itself). On the Panasonic CF-AX3, press F2 during startup (you may need to press it repeatedly, and you do this directly on the target machine's keyboard).

Once the BIOS setup screen comes up, remove the minimal install USB key, so that only the boot USB key (the smaller capacity one) remains inserted. Then, using the same navigation techniques as before, perform the following steps:

  1. disable legacy / CSM boot mode;
  2. enable EFI boot mode;
  3. ensure any 'fast boot' / 'ultra fast boot' options (if present) are disabled (as these may cause USB to be disabled until the operating system comes up);
  4. turn off secure boot (our kernel is currently unsigned, and we have not yet updated the machine's key database in any event);
  5. select the USB boot key as the highest priority UEFI boot device; and
  6. restart your machine (saving changes).

It's impossible to be precise about the GUI actions required to achieve the above, as they will vary from BIOS to BIOS. However, to give you some idea, here's how you go about it on the Panasonic CF-AX3 (which has an AMT BIOS).

Using the arrow keys, navigate across to the 'Boot' tab. Then, navigate down to the 'UEFI Boot' item, and press Enter. In the popup that appears, select 'Enabled' using the arrow keys, and press Enter. This switches the system out of legacy / CSM boot and into standard UEFI mode (steps 1 and 2 in the list above):

Switching Back to UEFI Boot
Important
If you have a 'Fast Boot' / 'Ultra Fast Boot' option in your BIOS, it's probably best to turn it off at this point (step 3 in the list); as this may cause USB devices to be disabled at boot time. The Panasonic has the choice of 'Normal' (as here) or 'Compatible' boot modes; 'Normal' does allow boot from USB and works with the USB keys I used, but if you have problems (and the same BIOS), you could try switching this to 'Compatible' instead).

Next (step 4), we'll turn off secure boot, since we haven't yet signed our kernel (or installed our own keys into the BIOS). On the CF-AX3, use the arrow keys to select the 'Security' tab, then navigate down to the 'Secure Boot' item, and select it by pressing Enter. This enters a 'Security' sub-page; navigate to the 'Secure Boot control' item, and press Enter. In the popup that appears, select 'Disabled' using the arrow keys, and press Enter:

(Temporarily) Disabling Secure Boot

Next, on the CF-AX3, it is necessary to restart the machine at this point (as it will not pick up valid UEFI boot devices immediately upon switching into UEFI boot mode). Press F10 to restart, and confirm if prompted.

Tip
Many BIOSes behave in this manner, and must be restarted when changing from CSM/legacy to UEFI boot (and vice versa), before all BIOS boot options relevant to that new mode can be specified.

When the machine restarts, hit F2 again, to re-enter BIOS setup. Now we can select a boot device (step 5). Using the arrow keys, navigate to the 'Boot' tab, and then down to the 'UEFI Priorities' item. Press Enter, and a sub-page is displayed. Ensure the item 'UEFI Boot from USB' is enabled (if it isn't, enable it now, and then press F10 to restart (confirming if prompted), and come back to this point). Navigate down to 'Boot Option #1' and press Enter. In the pop-up menu that appears, select your (boot) USB key, and press Enter to select it:

Making Our Boot USB Key the First Boot Option
Note
The item that you need to select from this menu will of course depend the make and model of your boot USB key.
Note
With some BIOSes you will also have to specify the specific file on the chosen USB device to boot - if so, you should enter (or select) /EFI/Boot/bootx64.efi (most BIOSes however will not require this, as this path is the EFI default).

That's it! Now press F10 to restart (step 6), and confirm if prompted.

If all that worked, your target system should restart, and boot the UEFI stub kernel off the boot USB key. After some initialization, you should 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, 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), and then type the root password you set up above.

If all goes well, 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) systemd or OpenRC. You can now click here to complete the configuration of your init system (and other) settings.

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 re-activate legacy / CSM booting, and set (if it is not already) the USB key to be the top boot priority 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 when it beeps at you, 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? And that secure boot is disabled at this point? Run through the steps in the "Selecting UEFI Boot Mode in the BIOS and Restarting!" section once more, then try again. (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.[12] 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).[13] 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 systemd (the default) should click here to go to the next chapter on the regular track, "Configuring systemd and Installing Necessary Tools"; whereas
  • users targeting OpenRC should instead click here to go to the next chapter on the alternative track, "Completing OpenRC Configuration and Installing Necessary Tools".

Notes

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