Discussion:
[lfs-support] A Question about EFI Partition
Rob
2018-06-10 12:27:53 UTC
Permalink
I just want to make sure this partition layout is correct before
doing grub.
fdisk -l /dev/sdb
Disk /dev/sdb: 37.3 GiB, 40000000000 bytes, 78125000 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: gpt
Disk identifier: 3423800A-F837-4BAA-9B7A-416EE111C386

Device Start End Sectors Size Type
/dev/sdb1 2048 1050623 1048576 512M EFI System
/dev/sdb2 1050624 32507903 31457280 15G Linux filesystem
/dev/sdb3 32507904 66062335 33554432 16G Linux swap
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipe
Xi Ruoyao
2018-06-10 13:29:07 UTC
Permalink
Post by Rob
I just want to make sure this partition layout is correct before
doing grub.
fdisk -l /dev/sdb
Disk /dev/sdb: 37.3 GiB, 40000000000 bytes, 78125000 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: gpt
Disk identifier: 3423800A-F837-4BAA-9B7A-416EE111C386
Device Start End Sectors Size Type
/dev/sdb1 2048 1050623 1048576 512M EFI System
/dev/sdb2 1050624 32507903 31457280 15G Linux filesystem
/dev/sdb3 32507904 66062335 33554432 16G Linux swap
LFS book does *not* support EFI. If you followed the book, you should
use "legacy boot" instead of EFI. And, since the partition table is
GPT, you should create a "BIOS boot partition" (in section 2.4.1.3 of
LFS book) for it.

If you want to use EFI, follow the hint
<https://linux.xidian.edu.cn/git/xry111/LFS-book/wiki/lfs-uefi>.

BTW, why do you need a 16 GB swap?
--
Xi Ruoyao <***@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e
Rob
2018-06-10 13:31:30 UTC
Permalink
Xi Ruoyao <***@stu.xidian.edu.cn> wrote:
LFS book does *not* support EFI. If you followed the book, you should
use "legacy boot" instead of EFI. And, since the partition table is
GPT, you should create a "BIOS boot partition" (in section 2.4.1.3 of
LFS book) for it.

There is no such thing as legacy boot on this machine.
So I have to follow the UEFI hint and hope it actually works.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-
Bruce Dubbs
2018-06-10 16:28:49 UTC
Permalink
Post by Xi Ruoyao
LFS book does *not* support EFI. If you followed the book, you should
use "legacy boot" instead of EFI. And, since the partition table is
GPT, you should create a "BIOS boot partition" (in section 2.4.1.3 of
LFS book) for it.
There is no such thing as legacy boot on this machine.
So I have to follow the UEFI hint and hope it actually works.
Most systems do have a way to do a legacy boot. It may be labelled
differently though. Look closely at the different bios screens. If it
can boot from a CD/DVD or USB drive, it can boot without EFI.

Since there is no need for a gui on this system, I suggest a standard
(not systemd) build. This is what I have for my laptop:

Number Start (sector) End (sector) Size Code Name
1 34 1987 977.0 KiB EF02 grub
2 1988 392612 190.7 MiB 8300 boot
3 392614 39455114 18.6 GiB 8300 debian
4 39455115 78517615 18.6 GiB 8302 home
5 78517616 82423871 1.9 GiB 8200 Linux swap
6 82423872 124366911 20.0 GiB 8300 lfs-8.2

...
23 :)

Of course you can skip the debian partition I have if you are going to
install from a live CD/DVD. Since you will only have one OS on the
system, you do not need a separate partition for home, but I still
recommend a separate /boot partition for future flexibility.

Notes:

1. When I set this up, I was using an old version of fdisk. The
initial sector for the grub partition should have been 2048 which is now
the default for both gdisk and fdisk.

2. Without a gui, the partition size for lfs can be quite a bit
smaller. A size of 8 GiB would be plenty and ensure lots of room for
building glibc and gcc. My last basic LFS installed size was 3.1 GiB,
including 525 MiB for the sources (gcc build size was 3702.500 MB).

-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_
lei niu
2018-06-11 00:29:50 UTC
Permalink
I do not quite agree with Bruce on LFS main partition size. I give / about 50GB, and due to my laziness during LFS + BLFS installation process, this amount of partition is easily consumed after the gnome compilation. So my suggestion is: give as much space as you can to home partition, this will save you a lot of time to clean disks for space. niuneilneo 邮箱***@gmail.com 筟名由 眑易邮箱倧垈 定制 On 06/11/2018 00:28, Bruce Dubbs wrote: On 06/10/2018 08:31 AM, Rob wrote: > Xi Ruoyao <***@stu.xidian.edu.cn> wrote: > LFS book does *not* support EFI.  If you followed the book, you should > use "legacy boot" instead of EFI.  And, since the partition table is > GPT, you should create a "BIOS boot partition" (in section 2.4.1.3 of > LFS book) for it. > > There is no such thing as legacy boot on this machine. > So I have to follow the UEFI hint and hope it actually works. Most systems do have a way to do a legacy boot.  It may be labelled differently though.  Look closely at the different bios screens.  If it can boot from a CD/DVD or USB drive, it can boot without EFI. Since there is no need for a gui on this system, I suggest a standard (not systemd) build.  This is what I have for my laptop: Number  Start (sector)    End (sector)  Size       Code  Name    1              34            1987   977.0 KiB   EF02  grub    2            1988          392612   190.7 MiB   8300  boot    3          392614        39455114   18.6 GiB    8300  debian    4        39455115        78517615   18.6 GiB    8302  home    5        78517616        82423871   1.9 GiB     8200  Linux swap    6        82423872       124366911   20.0 GiB    8300  lfs-8.2    ...    23   :) Of course you can skip the debian partition I have if you are going to install from a live CD/DVD.  Since you will only have one OS on the system, you do not need a separate partition for home, but I still recommend a separate /boot partition for future flexibility. Notes: 1.  When I set this up, I was using an old version of fdisk.  The initial sector for the grub partition should have been 2048 which is now the default for both gdisk and fdisk. 2.  Without a gui, the partition size for lfs can be quite a bit smaller.  A size of 8 GiB would be plenty and ensure lots of room for building glibc and gcc.  My last basic LFS installed size was 3.1 GiB, including 525 MiB for the sources (gcc build size was 3702.500 MB).   -- Bruce -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Ken Moffat
2018-06-11 00:43:11 UTC
Permalink
Post by lei niu
I do not quite agree with Bruce on LFS main partition size. I give / about 50GB, and due to my laziness during LFS + BLFS installation process, this amount of partition is easily consumed after the gnome compilation. So my suggestion is: give as much space as you can to home partition, this will save you a lot of time to clean disks for space.
You are ignoring one important fact from Rob's original post - the
disk is only 37.3GB. To be honest, to me that looks barely usable
for storage (even with only one, probably never updated, system).

Also, please do not top-post. And your mailer is horrible! The
html part appears to be formatted, but the text/plain part put
everything on one line, which made replying painful.

ĸen
--
Keyboard not found, Press F1 to continue
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Posting_style
Rob
2018-06-11 00:53:14 UTC
Permalink
Ken Moffat <***@ntlworld.com> wrote:
You are ignoring one important fact from Rob's original post - the
disk is only 37.3GB. To be honest, to me that looks barely usable
for storage (even with only one, probably never updated, system).


It works fine to run the system. And the system is CLI only.
The /home is on a different disk so it can be migrated around.
And, all of my important data storage is in esata boxes.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wi
lei niu
2018-06-11 00:59:04 UTC
Permalink
Quite interesting to store data on mobile esata box. Please remember to backup important data periodically, because I have terrible experience for losing crucial data on usb medias. niuneilneo 邮箱***@gmail.com 筟名由 眑易邮箱倧垈 定制 On 06/11/2018 08:53, Rob wrote: Ken Moffat <***@ntlworld.com> wrote: >>You are ignoring one important fact from Rob's original post - the disk is only 37.3GB.  To be honest, to me that looks barely usable for storage (even with only one, probably never updated, system). >It works fine to run the system. And the system is CLI only. The /home is on a different disk so it can be migrated around. And, all of my important data storage is in esata boxes. -- http://lists.linuxfromscratch.org/listinfo/lfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page Do not top post on this list. A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? http://en.wikipedia.org/wiki/Posting_style
Baho Utot
2018-06-11 14:35:29 UTC
Permalink
LFS book does *not* support EFI.  If you followed the book, you should
use "legacy boot" instead of EFI.  And, since the partition table is
GPT, you should create a "BIOS boot partition" (in section 2.4.1.3 of
LFS book) for it.
There is no such thing as legacy boot on this machine.
So I have to follow the UEFI hint and hope it actually works.
Most systems do have a way to do a legacy boot.  It may be labelled
differently though.  Look closely at the different bios screens.  If
it can boot from a CD/DVD or USB drive, it can boot without EFI.
Since there is no need for a gui on this system, I suggest a standard
Number  Start (sector)    End (sector)  Size       Code  Name
   1              34            1987   977.0 KiB   EF02  grub
   2            1988          392612   190.7 MiB   8300  boot
   3          392614        39455114   18.6 GiB    8300  debian
   4        39455115        78517615   18.6 GiB    8302  home
   5        78517616        82423871   1.9 GiB     8200  Linux swap
   6        82423872       124366911   20.0 GiB    8300  lfs-8.2
   ...
   23   :)
Of course you can skip the debian partition I have if you are going to
install from a live CD/DVD.  Since you will only have one OS on the
system, you do not need a separate partition for home, but I still
recommend a separate /boot partition for future flexibility.
1.  When I set this up, I was using an old version of fdisk.  The
initial sector for the grub partition should have been 2048 which is
now the default for both gdisk and fdisk.
2.  Without a gui, the partition size for lfs can be quite a bit
smaller.  A size of 8 GiB would be plenty and ensure lots of room for
building glibc and gcc.  My last basic LFS installed size was 3.1 GiB,
including 525 MiB for the sources (gcc build size was 3702.500 MB).
  -- Bruce
I have always used BIOS boot method in the past,  If I setup a disk with
EFI boot with grub will it still boot on an older machine that only
boots using the BIOS method?

I am looking to setup a disk for someone that has a newer computer than
mine and I need to set this up using my older computer.
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.
Michael Shell
2018-06-11 07:01:00 UTC
Permalink
On Sun, 10 Jun 2018 07:27:53 -0500
Post by Rob
I just want to make sure this partition layout is correct before
doing grub.
.
.
Post by Rob
Device Start End Sectors Size Type
/dev/sdb1 2048 1050623 1048576 512M EFI System
/dev/sdb2 1050624 32507903 31457280 15G Linux filesystem
/dev/sdb3 32507904 66062335 33554432 16G Linux swap
Rob,

With grub, you should have a grub, aka BIOS boot, partition of about
128.0 MiB, code EF02, after the first, EFI (code EF00) partition. It
is always a good idea to have the BIOS boot partition in case you
ever need grub. IIRC, the grub partition does not need to be
formatted.

The EFI partition, the very first one, is FAT32 and is usually mounted
on /boot/efi when servicing.

Your kernel will have to be compiled with an EFI stub. Under the kernel
menuconfig setup, in "Processor type and features" enable:

[*] EFI runtime service support
[*] EFI stub support

You should not enable mixed mode support:

[ ] EFI mixed-mode support


For the Built-in kernel command line (also under "Processor type and
features", you should specify the PARTUUID of your linux filesystem
that is to become /root when booted,
e.g.,
root=PARTUUID=1234567a-af67-4c97-8154-438376dc7113 ro log_buf_len=262144 video=DVI-I-1:1024x768-***@60 fbcon=font:VGA8x16

You can get the PARTUUID of the target partition via blkid, e.g.,

blkid /dev/sdb1

The kernel builtin settings can be overridden at load time by another
specification of these kernel parameters, say, from the boot loader
or loader command prompt. This is helpful in emergencies when the
kernel has to be told to use a different partition for /root.

To allow such an override, do not select the kernel config option
[ ] Built-in command line overrides boot loader arguments
under "Processor type and features"


In the kernel config under "Firmware Drivers", enable:
EFI (Extensible Firmware Interface) Support
<*> EFI Variable Support via sysfs
<*> Register efivars backend for pstore

Note, you may also need a kernel with EFI variable support on the
*host* system to be able to run efibootmgr to configure the EFI
setup - there is a potential catch-22 here.

After compilation, copy your new kernel arch/x86/boot/bzImage
to the EFI partition, e.g., (I use some additional subdirs here)

cp arch/x86/boot/bzImage /boot/efi/EFI/Linux/linux-x86_64.efi

Now use efibootmgr

https://github.com/rhboot/efibootmgr

to create an EFI entry to your boot kernel which has an EFI stub loader:

efibootmgr --create --disk /dev/sdb --part 1 --label "UEFI: Linux-x86_64.efi" --loader '\EFI\Linux\linux-x86_64.efi'

beware that the --loader option (that points to a kernel with EFI stub
loader) uses the \ as a dir separator as it is on a FAT32 filesystem.
You can use the -u option to add/override kernel command line arguments.
e.g., (here I use the short form of the options, -c = --create,
-d = --disk, -p = --partition, -L = --label, -l = --loader, etc.)

efibootmgr -c -d /dev/sda -p 1 -L "Mylabel" -l \vmlinuz-linux -u "root=PARTUUID=1234567a-af67-4c97-8154-438376dc7113 rw initrd=\initramfs-linux.img"

Now call

efibootmgr

to see the list of boot entries. The

BootOrder: 0003,0000,0001,0002,0005

line shows their order. Careful, the order is as shown on the
BootOrder line, *not* the order the entries appear later below
it. You can use the --bootorder (-o) option to change their order:

efibootmgr -o 2,0,1,5,3

Your EFI stub kernel should be the first one listed if you want
that to be the default. Of course, you will also want an entry
for the current host/alternate system. Your EFI system is supposed
to have a boot menu that can be accessed by pressing a certain
function key (usually its F11) at boot. That will allow you to
select something other than the default as needed.

If you get a kernel panic:

"Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)"

there is a problem with the root= setting. You have to use the
PARTUUID form and any boot loader root= specification that overrides
the specification that is builtin the kernel must also be correct.

For more info, see:
https://wiki.gentoo.org/wiki/EFI_stub_kernel#Configuration
https://wiki.gentoo.org/wiki/Efibootmgr


Using the EFI stub approach, any BIOS compatibility modes can be
disabled in the EFI/BIOS (making the system a pure EFI-only system)
and no other boot loaders whatsoever are required, other than the
EFI boot loader provided by the EFI/BIOS. efibootmgr is used to
manage these EFI/BIOS boot loader settings and pressing F11 on
boot can allow you to make a manual boot selection.



Cheers,

Mike Shell
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wik
Michael Shell
2018-06-11 07:06:03 UTC
Permalink
On Mon, 11 Jun 2018 03:01:00 -0400
Post by Michael Shell
Your kernel will have to be compiled with an EFI stub.
I should have also stated here:

"*if* you want to boot directly using the EFI system and bypassing any
need for grub or other bootloader".


Mike
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Post
niuneilneo
2018-06-11 13:24:08 UTC
Permalink
USING GRUB ON UEFI

AUTHOR: Dan McGhee, Kevin M. Buckley, and Xi Ruoyao

DATE: 2018-04-09

LICENSE: GNU Free Documentation License Version 1.2

SYNOPSIS: Boot LFS by default in a UEFI Environment using GRUB

PRIMARY URI: https://linux.xidian.edu.cn/git/xry111/LFS-book/wiki/lfs-uefi
(Markdown formatted, update once the author has built a new LFS version)

DESCRIPTION:
This hint contains the information to direct the OS Boot Manager to default
to the GRUB in a UEFI environment employing EFI Mode. This hint applies to
only x86_64 machines.

This version, hereafter referred to as "the 2018-04-09 hint", updates Dan
McGhee and Kevin M. Buckley's original, dated 2017-02-07.

The 2018-04-09 hint saw the UEFI packages built against an LFS 8.2 systemd
installation that was already being booted using the existing host system's
bootloaders.

Where possible, changes to the 2018-04-09 hint have been made so that it
should be obvious where the the 2018-04-09 and 2017-02-07 hint's differ.

ATTACHMENTS:
* None

PREREQUISITES:
* Base LFS system before or after Ch. 8
* Basic understanding of obtaining and building packages

HINT:

DISCLAIMER: The recipes in this hint neither supplant nor supersede the
build instructions in a stable version of either the LFS or BLFS books.
They merely augment them for newer firmware. If conflicts arise between
this hint and the instructions in the book, take the issue to the mailing
lists. Additionally, this hint applies to only x86_64 machines packaged
with Windows 7 or Windows 8. The recipes here can be used on Mac OS, but
have not been investigated at the initial writing of this hint.

The 2018-04-09 hint refers to an LFS 8.2 system, built onto an x86_64
machine from within a LFS 7.9 host, that had had never had a version of
windows installed on it, indeed the host contained one EFI directories
below `/boot/efi/EFI/`, namely `boot`, that having been installed by
the vendor of the computer.

USE OF TERMS: The following is a use of terms in this hint. Further
information for and amplification of them can be found in References 1-3.

* BIOS Settings: A firmware interface accessed by the keyboard after power
is applied. In it a user can change the order and way of how the computer
boots.

* BIOS System: Firmware with an MBR

* EFI Mode: A condition of the booted system in which the EFI partition is
mounted and the uefi (efi) variable support in the kernel is working
properly. It results from enabling UEFI Mode in BIOS Settings.

* EFI Mount Point: A user defined mount point for the EFI Partition. In
this hint, and in most distros, it is `/boot/efi`.

* EFI Partition: A small partition, usually before any other partitions;
i.e., `/dev/sda1` of 200-250 Mb, formatted in FAT32 with the `boot` flag, in
parted, or `ef00` (EF00) partition type in gdisk. (NOTE: The `boot` flag has a
different function and meaning in MBR partitioned disks.)

* efi variables (synonymous: uefi variables): variables through which the
operating system can interact with the firmware.

* Legacy Boot Option (Legacy Boot): A boot process in BIOS Settings that
disables UEFI booting and uses CIM.

* GUID Partition Table (GPT): A partitioning scheme that uses UUID's instead
of cylinders to identify partitions.


PRELIMINARY DISCUSSION: Additional information and more in depth
discussion of the following concepts can be found using References 1-3.

Booting LFS is no longer as simple as `grub-install /dev/sda`. There are
more options and more considerations. With the advent and proliferation of
UEFI firmware, a user's knowledge and philosophy of the boot
process requires expansion:

1. GPT partitioning is different from MBR partitioning. The tool fdisk
is not able to manipulate GPT partitions. Parted and gdisk (from
gptfdisk) are the tools to use. Each has their pros and cons,
supporters and detractors. Either one or both can be used.
2. UEFI firmware uses Boot Managers to select Boot Loaders like GRUB or
LILO. They, themselves do not boot the machine.
3. The Boot Loaders are placed on the EFI partition rather than the
MBR. This concept is similar and parallel to the LFS procedures of
using a separate `/boot` partition.
4. There are additional tools that LFS needs in order to accomplish
this mode of booting.
5. LFS can be built and booted as the instructions are written up to
and including LFS-8.2. To do this on UEFI firmware, the BIOS
Settings must be changed to Legacy Options from UEFI Options.

One of the hugely discussed issues surrounding UEFI is Secure Boot. It is
necessary to understand that the terms "UEFI" and "Secure Boot" are NOT
synonymous. UEFI is firmware. Secure Boot is a process of using "keys" to
"guarantee" the safety and authenticity of a Boot Loader. NOTE: To use
the recipes in this hint, Secure Boot must be disabled in the BIOS Boot
Settings.

Please note that the recommended order for implementing these recipes is a
departure from the build order in LFS. The most convenient, and arguably
the most practical way, to implement the recipes here is to use them in the
of build of an LFS System at the end of Ch. 6. Building the BLFS and
non-BLFS packages has been tested both inside and outside of the chroot
environment. Then, following the book, proceed through Ch. 7, returning to
the recipes in Ch. 8. The recipes are presented in that order.

The most inconvenient way to implement these recipes is in a completely
functional LFS-8.2, or earlier, system. This involves uninstalling
`GRUB-2.02`, removing it from its location as a result of `grub-install` and
implementing the recipes. Migrating from Legacy Boot to UEFI boot is
possible. At the initial writing of this hint, however, it is not
included. References 1-3 contain more information on this subject.

The last consideration in implementing the recipes here is GRUB's graphical
terminal. In UEFI systems, if the GRUB video mode is not initialized, no
kernel boot messages will appear until the kernel video takes over. The
GRUB package does not supply fonts, and GRUB defaults to `unicode.pf2`.
There are two ways to supply this font. The first is to copy `unicode.pf2`
from the host system to `/boot/grub` on the LFS system. The second method
involves configuring grub to build grub-mkfont, and this creates a build
dependency of `FreeType` for GRUB. This hint addresses both situations.

Finally, as of the initial writing of this hint, there is no standard for
the use of UEFI and the implementation of Secure Boot. These are hugely
manufacturer dependent. This hint uses terms used in the original author's
hardware. They may be different in other manufacturers' implementations.
However, the capabilities to do the boot setup operations contained in this
hint will exist on each machine. The terms may differ, and more than one
operation might be needed to achieve a desired goal. For example, someone
may need to disable Secure Boot and remove Secure Keys.

RECIPES:
[NOTE] The recipes are written with the assumption that the packages are
being built in the chroot environment before the end of Ch. 8. They can be
modified, with little difficulty, to be used in a functional system.

CHECKING EFI-MODE
Before entering the chroot environment, check that the host booted in
EFI Mode.

ls /sys/firmware/efi

If this directory exists and is populated, the host booted in EFI Mode.

MOUNT EFI PARTITION
Determine which device is the EFI partition using gdisk or parted,
enter the chroot environment, create `/boot/efi` if needed, and

mount -vt vfat /dev/sda(x) /boot/efi

where sda(x) is the device containing the EFI partition.

BUILD DEPENDENCIES:

Install the following BLFS packages, using the instructions in the book:
`dosfstools`, `popt` and `pciutils`. Build and install `FreeType`
if building grub with `grub-mkfont` enabled.

The BLFS 8.2 `FreeType` instructions recommend that it be built after
`which` and `libpng` have been installed, so it was, however, as the
recommendation for "HarfBuzz" notes that one builds `FreeType` without
it first, and then do a re-install, it wasn't thought necessary to do
the re-install.

The `libpng` install did include the "apng" patch.

The 2017-02-07 hint suggests we need static library of popt. But
now `efivar` no longer needs it. So we can just follow BLFS
instruction to build these packages.

The 2017-02-07 hint gives instruction to build `dosfstools`, now we can
just follow BLFS instruction.

EFIVAR-34

The 2017-02-07 hint uses `efivar-30`, but it's known to cause some issues.
So we update to `efivar-34`.

Dependencies:
* Required: popt

Download:
* https://github.com/rhboot/efivar/releases/download/34/efivar-34.tar.bz2

Compile the package:

make libdir=/usr/lib

The meaning of the make parameter:

* `libdir=/usr/lib`: This option overrides the default library directory
of the package (`/usr/lib64`).

Despite the Makefile having a `test` target, albeit one which isn't run
by default, you SHOULD NOT run that `make test`, as it has been found
to cause firmware bugs. Here are the thoughts on, and the exhortation
not to do, this from the `efivar` community:
https://github.com/rhboot/efivar/issues/78 .

Install the package:

Now as the `root` user:

make libdir=/usr/lib install

EFIBOOTMGR-14

Dependencies:
* Required: `pciutils` and `efivars`
* Required (runtime): `dosfstools`

Download:
* https://github.com/rhinstaller/efibootmgr/releases/download/14/efibootmgr-14.tar.bz2

Compile the package:

make

Install the package:

Now as the `root` user:

install -v -D -m0755 src/efibootmgr /usr/sbin/efibootmgr &&
install -v -D -m0644 src/efibootmgr.8 \
/usr/share/man/man8/efibootmgr.8

UNIFONT-10.0.07

Download:
* http://unifoundry.com/pub/unifont-10.0.07/font-builds/unifont-10.0.07.pcf.gz

Install the package:

[NOTE] This package is not a tarball. So DON'T (and you can't)
`tar -xf` it and change to the unzipped directory like normal LFS/BLFS
packages.

As the `root` user:

mkdir -pv /usr/share/fonts/unifont &&
gunzip -c unifont-10.0.07.pcf.gz > \
/usr/share/fonts/unifont/unifont.pcf

GRUB-2.02

Dependencies:
* Optional: `FreeType` (for `grub-mkfont` and `unicode.pf2`)
* Optional: `unifont` (for `unicode.pf2`)

[NOTE] The 2017-02-07 hint installs `unicode.pf2` manually.
However, if `freetype` and `unifont` are both installed, GRUB
will build `unicode.pf2`, and `grub-install` will install the
file automatically. This is recommended in 2018-04-09 hint.

Download:
* https://ftp.gnu.org/gnu/grub/grub-2.02.tar.xz

Prepare for compilation:

[NOTE] Some options in 2017-02-07 hint are no longer necessary.

./configure --prefix=/usr \
--sbindir=/sbin \
--sysconfdir=/etc \
--disable-efiemu \
--enable-grub-mkfont \
--with-platform=efi \
--disable-werror

The meaning of configure options:

* `--enable-grub-mkfont`: This ensures `grub-mkfont` to be built.
If `Freetype` is not installed, remove this option and then you
have to get `unicode.pf2` from other sources (either the host or
Internet).

* `--with-platform=efi`: This ensures `grub` to be built for EFI.

If the optional dependencies are installed, `configure` should
output the following information at last:

grub-mkfont: Yes
Build-time grub-mkfont: Yes
With unifont from /usr/share/fonts/unifont/unifont.pcf

That means `unicode.pf2` would be built and used.

Compile the package:

make

Install the package:

Now as the `root` user:

make install

MODIFICATION OF /etc/fstab

When constructing `/etc/fstab` in LFS chapter 8, add a line to
mount EFI partition:

/dev/<name of EFI partition> /boot/efi vfat defaults 0 1

Systemd would mount `efivarfs` automatically. If using sysvinit,
add another line to mount `efivarfs`:

efivarfs /sys/firmware/efi/efivars efivarfs defaults 0 1

Notes:

a) If you are going to be booting your UEFI-aware LFS system using a
non-LFS GRUB from your host AND if that GRUB is one (eg Fedora)
that allows for the kernel to be specified using that GRUB's
`linuxefi` attribute, so

linuxefi /path/to/kernel root=/path/to/root ro

then you don't appear to need the `/etc/fstab` line, and indeed,
you'll get told during the boot that the mounter knows nothing
about the efivars filesystem type. However, LFS's efibootmgr will
still be capable of interrogating your UEFI environment.

b) If the LFS system is booted from the LFS+Hint's grub, which doesn't
appear to know about the "linuxefi" attribute so using

linux /path/to/kernel root=/path/to/root ro

then, unless you have the efivars filesystem mounted, and you are
able to, then LFS's efibootmgr will be **not** capable of interrogating
your UEFI environment, and you'll be told that there is no `efivars`
filesystem.

KERNEL CONFIGURATION OPTIONS FOR EFI

The LFS 8.2 kernel build's `make defconfig` populated a good number of
the EFI-related options on my UEFI-enabled hardware, however, so as to
make the 2014-10-16 hint's list of settings easier to find when coming
to alter/set things, here is the list of the options along with the
location of the various checkboxes and the settings they should have,
as seen when starting from a `make menuconfig`:

## CONFIG_EFI_PARTITION=y

Location:
-> Enable the block layer
-> Partition Types
[*] Advanced partition selection
...
[*] EFI GUID Partition support

## CONFIG_EFI=y
## CONFIG_EFI_STUB=y

Location:
-> Processor type and features
[*] EFI runtime service support
[*] EFI stub support

## CONFIG_FB_EFI=y

Location:
-> Device Drivers
-> Graphics support
-> Frame buffer Devices
[*] EFI-based Framebuffer Support

## CONFIG_FRAMEBUFFER_CONSOLE=y

Location:
-> Device Drivers
-> Graphics support
-> Console display driver support
Framebuffer Console support (Not available on mine)

## CONFIG_EFI_VARS is not set
## CONFIG_EFI_RUNTIME_MAP=y

Location:
-> Firmware Drivers
-> EFI (Extensible Firmware Interface) Support
< > EFI Variable Support via sysfs
[*] Export efi runtime maps to sysfs


## CONFIG_EFIVAR_FS=y/m

Location:
-> File systems
-> Pseudo filesystems
[*] EFI Variable filesystem

Note:

The only Kernel Config setting that a `make defconfig` didn't set on
the UEFI-enabled host was this one:

## CONFIG_EFI_STUB=y

and without that setting in the kernel, attempts to boot the LFS system
tell you that:

Kernel doesn't support EFI handover

however, adding just that one Kernel Config setting sees you able to
boot into the LFS system using the host system's Grub.

`CONFIG_FB_EFI=y` seems not necessary if you have other FB devices
avaliable. But without it you will lose some boot messages along
with the Tux logos on the FB.

USING GRUB TO SET UP THE BOOT PROCESS

INSTALLING GRUB TO THE EFI PARTITION

Installing GRUB to the EFI partition and creating an OS Boot Manager
entry is the major difference between the recipes in this hint and the
procedures in the LFS book. In concept, it is not actually a divergence
from the concepts of the book. The instructions there install GRUB to
the MBR, the MBR protected layer of a GPT disk or to a dedicated /boot
partition. The recipes here install GRUB to the EFI partition and
generate an entry in the system's Boot Manager. It is for the single
command here that this hint was written and for which all the non-LFS
packages were installed.

grub-install --bootloader-id=LFS --recheck --debug &> grub.log

`--bootloader-id=<some name>` is the directory on the EFI partition to
which the GRUB image is written.

Running this command generates lots of output (redirected to `grub.log`).
But at the end it will indicate that it was successful. This command
installs the GRUB image to `/boot/efi/EFI/LFS/grubx64.efi` and creates
the entry `LFS` in the system's Boot Manager.

To check it, inspect the contents of `/boot/efi/EFI/LFS` and, as root, run
`efibootmgr`. The results of this command will list the Boot Order and
all the Boot Entries. If the entry "LFS" does not appear, read the
efibootmgr man page, create an entry and change the Boot Order to what is
desired.

If GRUB was built with `freetype` and `unifont`, `unicode.pf2` should be
installed automatically now. Issue:

grep "unicode.pf2" grub.log

You should see something like

copying `/usr/share/grub/unicode.pf2' -> `/boot/grub/fonts/unicode.pf2'

If not, you should get `unicode.pf2` from the host system or Internet,
and install it into `/boot/grub/fonts`.

CONFIGURING GRUB

Generate `grub.cfg`:

cat > /boot/grub/grub.cfg << "EOF"
# Begin /boot/grub/grub.cfg
set default=0
set timeout=5

insmod gzio
insmod part_gpt
insmod ext2
set root=(hd[x], gpt[y])
# hd[x] is the drive of the LFS partion and gpt[y] is the partition

insmod efi_gop
insmod efi_uga
insmod font
if loadfont /boot/grub/fonts/unicode.pf2; then
loadfont /boot/grub/fonts/unicode.pf2
set gfxmode=auto
insmod gfxterm
set gfxpayload=keep
terminal_output gfxterm
fi

menuentry "GNU/Linux, Linux <kernel name>" {
linux /boot/vmlinuz-<kernel name>; root=/dev/sda[x] ro
}
EOF

Note that in `menuentry`, `/dev/sda[x]` is the device of the LFS
partition.

[NOTE] From GRUB's perspective, the kernel files are relative
to the partition used. If you used a separate `/boot` partition,
remove `/boot` from the above linux line and path of `unicode.pf2`.
You will also need to change the `set root` line to point to the
boot partition.

FINAL DISCUSSION:

As stated before, the implementation of UEFI firmware and its manipulation
depends hugely on the manufacturer. As of the initial writing of this
hint, there is no standard approach. Therefore, while the recipes here all
do what is advertised, regrettably the system may not default to the grub
boot loader "out of the box." In that case, reviewing References 1-3, will
provide information that will lead users to a solution to the situation.
As always, one of the best resources is the {,B}LFS mailing lists.

At this point, it is worth stating that there are other helpful tools:
gummiboot and rEFInd are two of them. They are described as Boot Managers,
but in fact are a user space layer between the OS Boot Manager and the Boot
Loader. Information about both is in the references.

REFERENCES:

1. Rod's Books - A collection of web page articles that goes into great
detail about the concepts of UEFI booting, partitioning and tools.
The below URL goes right to the efi information. www.rodsbooks.com is
the main page and has many, many good articles.
URL: http://www.rodsbooks.com/efi-bootloaders/index.html

2. "Unified Extensible Firmware Interface - ArchWiki"
URL: https://wiki.archlinux.org/index.php/Unified_Extensible_Firmware_Interface

3. "GRUB - ArchWiki"
URL: https://wiki.archlinux.org/index.php/GRUB

4. Google. URL: https://google.com


ACKNOWLEDGEMENTS:
* Craig Magee for comments and testing.
* Pierre Labastie for testing, font manipulation and comments.
* Lei Niu for comments on efivar and grub.cfg issues.

TODO:
* Add paragraph and section numbers and TOC to make searchable
* Add appendix for migration from Legacy Boot to UEFI boot
* Add appendix for more options to default to GRUB
* Add appendix for LVM
* Add appendix for "standalone" GRUB on EFI partition independent
from distro

CHANGELOG:
[2018-04-09]
Updated for LFS 8.2
Use BLFS-like format for package dependency list
Use package name in BLFS (FreeType instead of Freetype2)
Deleted dosfstools-3.0.28 (replaced by dosfstools-4.1 in BLFS)
Updated efivar-30 to efivar-34
Updated unifont-9.0.06 to unifont-10.0.07
Updated GRUB-2.02~beta3 to GRUB-2.02
Modified the hint to let GRUB install unicode.pf2 automatically
Removed some options not necessary now
Fixed path to unicode.pf2 in grub.cfg for those without /boot partition
Copied note about seperated /boot partition for grub.cfg from LFS book
Removed incorrect personal email addresses (they are LFS mail lists)
Added URL of Google
Adapted for checkHint script (AUTHORS to AUTHOR)

[2017-01-22]
Updated for LFS 7.10 and "extra package" updates
dosfstools-3.0.26 -> dosfstools-3.0.28
efivar-0.12 -> efivar-30
efibootmgr-0.9.0 -> efibootmgr-14
unifont-7.0.05 -> unifont-9.0.06

[2014-10-16]
Initial hint.
Michael Shell
2018-06-12 00:21:45 UTC
Permalink
On Mon, 11 Jun 2018 21:24:08 +0800
This most updated UEFI installation guide is mainly contributed by Xi
and already committed to LFS knowledge base.
That is a good one. I missed the importance of the earlier post to it.
Thanks for the tip!

But, my post was not about using grub under EFI, but rather about doing away
with grub entirely. What advantage is there to retaining the use of grub
when the EFI system and efibootmgr does not need it?

If I were going to use a bootloader under EFI, I would use Rod Smith's
rEFInd:

http://www.rodsbooks.com/efi-bootloaders/refind.html

As you might guess, I'm not a big fan of grub. There is a reason it has been
said of grub by the gummiboot developers:

"gummiboot is intended to be a minimal alternative to GNU GRUB that
'just works'"
https://en.wikipedia.org/wiki/Gummiboot_(software)

I went from BIOS-lilo to pure-EFI without ever using anything in between.


On Mon, 11 Jun 2018 23:13:29 +0800
If EFI is used, the BIOS boot partition is unnecessary. It is
used to workaround issues caused by GPT with Legacy Boot.
OK, but if they ever need to boot in BIOS mode under a GPT disk, they will
need that partition to hold grub's second stage loader. In Rob's case, I
can now see he definitely does not need it because his system does not even
support booting using BIOS mode.

Nevertheless, it's good to know that grub won't complain if it does not
find that partition as long as it does not actually need the second stage
loader.
Using /dev/sd* works, but your computer may refused to boot
with a USB stick.
Yes, and there was something else that trips up /dev/sd* specifiers before
udev can become active - IIRC, I think if a multicore machine has more than
one SATA controller/card/chip, the order of the device detection/naming can
vary between boots. So, for anything prior to udev's control, we have to use
persistant device naming for it to be reliable. FWIW, I dislike this design
choice of the linux kernel.
Now we use CONFIG_EFIVAR_FS (y or m), instead of CONFIG_EFI_VARS,
Do you know if efibootmgr will autodetect (at run time) between the two kernel
interfaces (and if this is a recent feature, what version starting supporting
that)? AFAIK, they both can be enabled at the same time.

As you mentioned, EFIVAR_FS is a more modern interface, but it does
require that a special efivarfs filesystem be (re)mounted r/w:

mount -o rw -t efivarfs efivarfs /sys/firmware/efi/efivars

So, Rob will have to add that to his start scripts - maybe mount it read-only
and then manually remount r/w as needed:

mount -o remount,rw -t efivarfs efivarfs /sys/firmware/efi/efivars

Thanks for the tips and info!


Cheers,

Mike
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-
Bruce Dubbs
2018-06-12 04:20:51 UTC
Permalink
Post by Michael Shell
On Mon, 11 Jun 2018 21:24:08 +0800
As you might guess, I'm not a big fan of grub. There is a reason it has been
"gummiboot is intended to be a minimal alternative to GNU GRUB that
'just works'"
https://en.wikipedia.org/wiki/Gummiboot_(software)
I went from BIOS-lilo to pure-EFI without ever using anything in between.
Actually, I think grub works pretty well for booting. What is broken is
the automatic generation of grub.cfg. There are tons of complicated
stuff happening to make for pretty screens when those screens are
typically up for 5 seconds or less. If you manually maintain grub.cfg,
it is really quite easy. My grub.cfg is 88 lines long with 20 menuentry
lines. A default grub.cfg for Debian with one OS installed is 200
lines. That's a distro problem/bloat.

Most users only have one OS on their system. Some have two. Very few
have more than that. For that later group, editing grub.cfg should be easy.
Post by Michael Shell
On Mon, 11 Jun 2018 23:13:29 +0800
If EFI is used, the BIOS boot partition is unnecessary. It is
used to workaround issues caused by GPT with Legacy Boot.
What issues with GPT and legacy boot? Grub needs some space for it's
code that is OS independent. A separate small partition makes sense.
Putting the boot code in firmware is what does not make sense. And you
still need a custom EFI partition even then.
Post by Michael Shell
OK, but if they ever need to boot in BIOS mode under a GPT disk, they will
need that partition to hold grub's second stage loader. In Rob's case, I
can now see he definitely does not need it because his system does not even
support booting using BIOS mode.
Nevertheless, it's good to know that grub won't complain if it does not
find that partition as long as it does not actually need the second stage
loader.
Talking about a second stage loader is really about grub legacy. The
current grub doesn't work like that. The old way of using a fat
partition table and loading code in sectors 2-32 was really a kludge.
Post by Michael Shell
Using /dev/sd* works, but your computer may refused to boot
with a USB stick.
Yes, and there was something else that trips up /dev/sd* specifiers before
udev can become active - IIRC, I think if a multicore machine has more than
one SATA controller/card/chip, the order of the device detection/naming can
vary between boots. So, for anything prior to udev's control, we have to use
persistant device naming for it to be reliable. FWIW, I dislike this design
choice of the linux kernel.
I believe the slots the sata drives are plugged into have priorities.
I've never seen the disks reverse identification. that would really be
a bad race condition. If it was happening, we would certainly have
heard about it.

-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?
Michael Shell
2018-06-12 05:43:34 UTC
Permalink
On Mon, 11 Jun 2018 23:20:51 -0500
Post by Bruce Dubbs
What issues with GPT and legacy boot? Grub needs some space for it's
code that is OS independent. A separate small partition makes sense.
Putting the boot code in firmware is what does not make sense. And you
still need a custom EFI partition even then.
Talking about a second stage loader is really about grub legacy. The
current grub doesn't work like that. The old way of using a fat
partition table and loading code in sectors 2-32 was really a kludge.
Well, according to:

https://en.wikipedia.org/wiki/BIOS_boot_partition

"When used, the BIOS boot partition contains the second stage of the boot
loader program, such as the GRUB 2; the first stage is the code that is
contained within the Master Boot Record (MBR). Use of this partition is
not the only way BIOS-based boot can be performed while using
GPT-partitioned hard drives; however, complex boot loaders such as GRUB 2
cannot fit entirely within the confines of the MBR's 398 to 446 bytes of
space, thus they need an ancillary storage space. On MBR disks, such
boot loaders typically use the sectors immediately following the MBR for
this storage; that space is usually known as the "MBR gap". No equivalent
unused space exists on GPT disks, and the BIOS boot partition is a way to
officially allocate such space for use by the boot loader."


So, with GPT disks under BIOS systems, there is no way to initially load a
boot loader complex enough to be able to read a filesystem. Lilo worked
by requesting the sector numbers that corresponded to its second stage
(and in turn, it's second stage requested the sector numbers of the
kernel image to boot). That is why lilo had to be rerun every time a
kernel image file was moved.

So, when grub is running on a BIOS system with a GPT disk, it works a
bit like lilo, except the second stage loader is contained in its own
partition (where it can't be touched by mv, rm and friends) and that
second stage is smart enough to be able to read files on FAT and EXTx
filesystems without relying on fixed sector numbers. In this way, there
is no need to "rerun" grub if a kernel image file is relocated as is
the case with lilo.

BTW, IIRC, anyone using a BIOS-based initial load, either grub, lilo,
etc., must ensure that the (second stage) boot loader as well as any
kernel image files are located within the first 2 TB of the drive
because the BIOS calls can't handle sector numbers beyond that.
Post by Bruce Dubbs
I believe the slots the sata drives are plugged into have priorities.
I've never seen the disks reverse identification. that would really be
a bad race condition. If it was happening, we would certainly have
heard about it.
I can't remember exactly how I was bitten by it, but it wasn't via USB.
It might have been from the use of a removable rack or SD card to SATA
adapter (as a "rescue" boot) that sometimes would have media in it and
sometimes not.

In any case, according to
https://wiki.archlinux.org/index.php/persistent_block_device_naming

"If your machine has more than one SATA, SCSI or IDE disk controller, the
order in which their corresponding device nodes are added is arbitrary."

As I understand it, that is the policy of the kernel developers - a system
might work in many cases, but it is not guaranteed and a future kernel
update could break systems that rely on any fixed /dev/sd* naming. To me,
this means that, until udev becomes active and we can control things as we
wish, any /dev/sd* specifiers are to be considered worthless.

I do not like that policy. Unless countermanded by a kernel option,
on-motherboard controllers should be enumerated before those of any add-on
card or USB device. Also, SATA slots for a given controller should be
enumerated in a fixed order, and IMHO, a SATA/PATA/SCSI slot should be
enumerated regardless of whether a drive has been plugged into it. I would
go so far as to make it that an initial, say, half a dozen drive names would
be reserved for each USB controller regardless of whether a USB mass storage
device was actually present at boot. I would also not enumerate USB drives
in the /dev/sdx sequence, they would get their own sequence /dev/usbdx,
because those do not have known/fixed slots as SATA controllers do.

In a more complex arrangement, controllers could be enumerated like the
devices they carry - /dev/sdAb1 - controller A, drive b, partition 1
with motherboard controllers being enumerated first, and then those on
PCI, etc., slots, in the order of the slots they are plugged into.

In short, I would try hard to avoid changing existing device names, most
especially for devices on controllers on the motherboard, if later
something is merely added-to/plugged-into the system.


Cheers,

Mike
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wik
Xi Ruoyao
2018-06-12 06:16:39 UTC
Permalink
Post by Michael Shell
As I understand it, that is the policy of the kernel developers - a system
might work in many cases, but it is not guaranteed and a future kernel
update could break systems that rely on any fixed /dev/sd* naming. To me,
this means that, until udev becomes active and we can control things as we
wish, any /dev/sd* specifiers are to be considered worthless.
I do not like that policy. Unless countermanded by a kernel option,
on-motherboard controllers should be enumerated before those of any add-on
card or USB device. Also, SATA slots for a given controller should be
enumerated in a fixed order, and IMHO, a SATA/PATA/SCSI slot should be
enumerated regardless of whether a drive has been plugged into it. I would
go so far as to make it that an initial, say, half a dozen drive names would
be reserved for each USB controller regardless of whether a USB mass storage
device was actually present at boot. I would also not enumerate USB drives
in the /dev/sdx sequence, they would get their own sequence /dev/usbdx,
because those do not have known/fixed slots as SATA controllers do.
In a more complex arrangement, controllers could be enumerated like the
devices they carry - /dev/sdAb1 - controller A, drive b, partition 1
with motherboard controllers being enumerated first, and then those on
PCI, etc., slots, in the order of the slots they are plugged into.
That's why devtmpfs and udev are here. Differnet people have different
tastes of naming policy. Now they can just modify udev rules to provide
a custom naming convention.

But udev is not in early boot stage... If I have to use a persistant
naming policy at early boot, I'll write a script to implement it and
create an initrd.
--
Xi Ruoyao <***@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wikipedia.org/wiki/Po
Bruce Dubbs
2018-06-12 15:28:26 UTC
Permalink
Post by Michael Shell
On Mon, 11 Jun 2018 23:20:51 -0500
Post by Bruce Dubbs
What issues with GPT and legacy boot? Grub needs some space for it's
code that is OS independent. A separate small partition makes sense.
Putting the boot code in firmware is what does not make sense. And you
still need a custom EFI partition even then.
Talking about a second stage loader is really about grub legacy. The
current grub doesn't work like that. The old way of using a fat
partition table and loading code in sectors 2-32 was really a kludge.
https://en.wikipedia.org/wiki/BIOS_boot_partition
"When used, the BIOS boot partition contains the second stage of the boot
loader program, such as the GRUB 2; the first stage is the code that is
contained within the Master Boot Record (MBR). Use of this partition is
not the only way BIOS-based boot can be performed while using
GPT-partitioned hard drives; however, complex boot loaders such as GRUB 2
cannot fit entirely within the confines of the MBR's 398 to 446 bytes of
space, thus they need an ancillary storage space. On MBR disks, such
boot loaders typically use the sectors immediately following the MBR for
this storage; that space is usually known as the "MBR gap". No equivalent
unused space exists on GPT disks, and the BIOS boot partition is a way to
officially allocate such space for use by the boot loader."
So, with GPT disks under BIOS systems, there is no way to initially load a
boot loader complex enough to be able to read a filesystem. Lilo worked
by requesting the sector numbers that corresponded to its second stage
(and in turn, it's second stage requested the sector numbers of the
kernel image to boot). That is why lilo had to be rerun every time a
kernel image file was moved.
There are a lot of things that can go wrong when disk sector numbers are
embedded into the code like lilo does. I do not know anything about the
internals of elilo though.
Post by Michael Shell
So, when grub is running on a BIOS system with a GPT disk, it works a
bit like lilo, except the second stage loader is contained in its own
partition (where it can't be touched by mv, rm and friends) and that
second stage is smart enough to be able to read files on FAT and EXTx
filesystems without relying on fixed sector numbers. In this way, there
is no need to "rerun" grub if a kernel image file is relocated as is
the case with lilo.
The code on the boot sector is very short (448 bytes as I recall). That
does have enough to find the grub partition and read from there. In
grub legacy the boot sector (sector 0) read exactly one sector (sector
1) and that loaded the other sectors up through sector 31. The sector 1
code was referred to stage 1 and the sectors 2-31 were stage 2.

Sometimes this mechanism interfered with other programs. Autocad, for
instance, wrote some data to the same area.
Post by Michael Shell
BTW, IIRC, anyone using a BIOS-based initial load, either grub, lilo,
etc., must ensure that the (second stage) boot loader as well as any
kernel image files are located within the first 2 TB of the drive
because the BIOS calls can't handle sector numbers beyond that.
I don't think you can say that for all BIOS firmware, but it is
certainly true for some. Personally, I always make the grub partition sda1.
Post by Michael Shell
Post by Bruce Dubbs
I believe the slots the sata drives are plugged into have priorities.
I've never seen the disks reverse identification. that would really be
a bad race condition. If it was happening, we would certainly have
heard about it.
I can't remember exactly how I was bitten by it, but it wasn't via USB.
It might have been from the use of a removable rack or SD card to SATA
adapter (as a "rescue" boot) that sometimes would have media in it and
sometimes not.
In any case, according to
https://wiki.archlinux.org/index.php/persistent_block_device_naming
"If your machine has more than one SATA, SCSI or IDE disk controller, the
order in which their corresponding device nodes are added is arbitrary."
As I understand it, that is the policy of the kernel developers - a system
might work in many cases, but it is not guaranteed and a future kernel
update could break systems that rely on any fixed /dev/sd* naming. To me,
this means that, until udev becomes active and we can control things as we
wish, any /dev/sd* specifiers are to be considered worthless.
I see. I guess I've never had a system with multiple disk controllers.
My development system has six sata drives, but they are all plugged into
the motherboard so that is one controller. I think that multiple
controllers are rare outside of large organizations.
Post by Michael Shell
I do not like that policy. Unless countermanded by a kernel option,
on-motherboard controllers should be enumerated before those of any add-on
card or USB device.
USB is separate as is a CD/DVD device. At least it is in any BIOS that
I have worked with. Perhaps it is a problem if multiple USB drives are
plugged in at boot. I have not tried that.

Also, SATA slots for a given controller should be
Post by Michael Shell
enumerated in a fixed order, and IMHO, a SATA/PATA/SCSI slot should be
enumerated regardless of whether a drive has been plugged into it. I would
go so far as to make it that an initial, say, half a dozen drive names would
be reserved for each USB controller regardless of whether a USB mass storage
device was actually present at boot. I would also not enumerate USB drives
in the /dev/sdx sequence, they would get their own sequence /dev/usbdx,
because those do not have known/fixed slots as SATA controllers do.
That comes down to HW design, don't you think?
Post by Michael Shell
In a more complex arrangement, controllers could be enumerated like the
devices they carry - /dev/sdAb1 - controller A, drive b, partition 1
with motherboard controllers being enumerated first, and then those on
PCI, etc., slots, in the order of the slots they are plugged into.
In short, I would try hard to avoid changing existing device names, most
especially for devices on controllers on the motherboard, if later
something is merely added-to/plugged-into the system.
I would think that the MB would always be first. The issue would then
be between multiple plugin controllers.

-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mai
Ken Moffat
2018-06-12 19:42:05 UTC
Permalink
Post by Bruce Dubbs
There are a lot of things that can go wrong when disk sector numbers are
embedded into the code like lilo does. I do not know anything about the
internals of elilo though.
(Just a few comments, not related to EFI) -

I liked lilo, and I deviated from the book to use it on most of my
machines - perhaps only one had grub-legacy at that time, and that
was just for testing the book. Hell, on pure64 (cross-lfs) we
couldn't even build grub-legacy at first.

And then /dev/hda became /dev/sda - I never managed to get lilo to
work with /dev/sd if the machine was currently booting from /dev/hd.
Post by Bruce Dubbs
Post by Michael Shell
BTW, IIRC, anyone using a BIOS-based initial load, either grub, lilo,
etc., must ensure that the (second stage) boot loader as well as any
kernel image files are located within the first 2 TB of the drive
because the BIOS calls can't handle sector numbers beyond that.
I don't think you can say that for all BIOS firmware, but it is certainly
true for some. Personally, I always make the grub partition sda1.
My only machine with drives bigger than 2TB uses them for RAID-1 not
for booting. ISTR that I had to use GPT on them to be able to use
the whole drive.

For msdos partitioning, I've got /boot all over the place - sda14 on
one machine which is towards the end of a nominally 500GB drive.
Post by Bruce Dubbs
Post by Michael Shell
Post by Bruce Dubbs
I believe the slots the sata drives are plugged into have priorities.
I've never seen the disks reverse identification. that would really be
a bad race condition. If it was happening, we would certainly have
heard about it.
I can't remember exactly how I was bitten by it, but it wasn't via USB.
It might have been from the use of a removable rack or SD card to SATA
adapter (as a "rescue" boot) that sometimes would have media in it and
sometimes not.
On my oldest machine (very old) the drive devices move around according
to which connectors have a drive attached. I think I've also seen that
on other machines over the years : plug in only to the first connector,
it is sda, but add another drive on a "later" connector and sda
became sdc. Not all connectors on some consumer-grade motherboards
use the same SATA driver.
Post by Bruce Dubbs
Post by Michael Shell
In any case, according to
https://wiki.archlinux.org/index.php/persistent_block_device_naming
"If your machine has more than one SATA, SCSI or IDE disk controller, the
order in which their corresponding device nodes are added is arbitrary."
Yes. I recall using e2label for consistent naming (I think on that
machine, even with the exact same connections, a newer kernel could
also move them around - and that is, of course, with the drivers
built-in.
Post by Bruce Dubbs
Post by Michael Shell
As I understand it, that is the policy of the kernel developers - a system
might work in many cases, but it is not guaranteed and a future kernel
update could break systems that rely on any fixed /dev/sd* naming. To me,
this means that, until udev becomes active and we can control things as we
wish, any /dev/sd* specifiers are to be considered worthless.
I see. I guess I've never had a system with multiple disk controllers. My
development system has six sata drives, but they are all plugged into the
motherboard so that is one controller. I think that multiple controllers
are rare outside of large organizations.
Post by Michael Shell
I do not like that policy. Unless countermanded by a kernel option,
on-motherboard controllers should be enumerated before those of any add-on
card or USB device.
USB is separate as is a CD/DVD device. At least it is in any BIOS that I
have worked with. Perhaps it is a problem if multiple USB drives are
plugged in at boot. I have not tried that.
Plugging in a usb drive before power on often used to give problems.

ĸen
--
Keyboard not found, Press F1 to continue
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

ht
Michael Shell
2018-06-13 04:58:09 UTC
Permalink
On Tue, 12 Jun 2018 10:28:26 -0500
Post by Bruce Dubbs
I don't think you can say that for all BIOS firmware, but it is
certainly true for some.
I'm surprised by this, but you are correct here! According to

t13.org/Documents/UploadedDocuments/project/d1386r0-EDD.pdf

since 1999 BIOes have had "Enhanced disk drive (EDD)" support for an
Int 13h extension than can address up to "16 mega-tera" sectors (2^64)
in size. It is just a question of upgrading any boot loader to use
this call (and hope the BIOS creator did it correctly).

With the older BIOS call, the sector number is specified as a 32bit
number and drives have historically used 512 bytes per sector.
So, the upper limit with the legacy call is 2^32 * 512 = 2.199 TB


On Tue, 12 Jun 2018 20:42:05 +0100
Post by Bruce Dubbs
And then /dev/hda became /dev/sda - I never managed to get lilo to
work with /dev/sd if the machine was currently booting from /dev/hd.
IMHO, lilo had one particularly awful design decision and the resulting
unexpected behavior was never explained to us as it should have been -
lilo would *reinterpret* whatever the user specified for root= in terms
of device numbers of the current running system and then pass the
resulting device *number* as the value of root= to the kernel to be
booted. The only exceptions allowed were for LABEL= and UUID=, but even
there what we really needed was PARTUUID=. In short, lilo should have
just kept root= exactly as the user gave it in the lilo.conf and passed
that string as-is to the kernel when booting.

I was working on one of my (really) old machines back in November and
wrote a patch for lilo to do just that. I've attached it to this post.
Once the patch has been applied and lilo rebuilt, you can put anything
you want for root= and it will be passed-on as-is. That means you can
do things like:

root="PARTUUID=1234567a-af67-4c97-8154-438376dc7113"
or
root="/dev/sda1"

and it will work as you expect - root= will be interpreted only at
boot by the booting kernel. And lilo will also work with GPT partitioned
disks just fine! (because lilo only cares about sector numbers, not
partitions).

The main lilo limitations would then be:

1. The EFI/BIOS must provide the legacy BIOS "compatibility" (CSM)
calls.
2. Lilo's second stage boot loader and any kernel images to be
loaded must be within the first 2TB boundary. (I think.)
3. The drive must be using a 512 byte sector size. (I think.)
4. As always, if lilo's second stage boot loader or a kernel image
file is moved, lilo must be rerun to get the correct sector
number locations of those files.

If they really are problems, both #2 and #3 should also be fixable in
code, well, as long as the BIOS call of the machine supports it.

I suppose my "pass root as-is" patch would have really been helpful
to some folks ... 5 years ago. Oh well.


Mike
Michael Shell
2018-06-13 06:45:37 UTC
Permalink
On Wed, 13 Jun 2018 00:58:09 -0400
Post by Michael Shell
IMHO, lilo had one particularly awful design decision and the resulting
unexpected behavior was never explained to us as it should have been -
lilo would *reinterpret* whatever the user specified for root= in terms
of device numbers of the current running system and then pass the
resulting device *number* as the value of root= to the kernel to be
booted.
FWIW, there once ago was a valid reason for doing this - a long time ago,
kernels only recognized major/minor device numbers for root directory
specifiers:

root=0x803

However, at some point kernels became able to recognize (at least the
common) /dev forms (e.g., root=/dev/sda3) and convert that at boot
to the major/minor form used internally even though there was not yet
a functioning /dev directory.

In any case, the lilo man page should have done a better job explaining
what exactly was actually passed to the kernel for root= in the
lilo.conf.


Mike
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in
Xi Ruoyao
2018-06-12 06:25:48 UTC
Permalink
Post by Michael Shell
On Mon, 11 Jun 2018 23:13:29 +0800
Now we use CONFIG_EFIVAR_FS (y or m), instead of CONFIG_EFI_VARS,
Do you know if efibootmgr will autodetect (at run time) between the two kernel
interfaces (and if this is a recent feature, what version starting supporting
that)? AFAIK, they both can be enabled at the same time.
efibootmgr uses the library from efivar for /sys/firmware/efi/efivars.
I searched "efivarfs" in the Github repo and found the commit to add efivarfs
support:
https://github.com/rhboot/efivar/commit/5b175a55d53c5d0f44e3636802fc7dc3fe7549a6

It was released in efivarfs-0.4.
Post by Michael Shell
As you mentioned, EFIVAR_FS is a more modern interface, but it does
mount -o rw -t efivarfs efivarfs /sys/firmware/efi/efivars
Yes. Systemd mounts efivarfs automatically. But with sysvinit we should mount
it manually, or in /etc/fstab.
--
Xi Ruoyao <***@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

http://en.wik
Michael Shell
2018-06-12 07:19:01 UTC
Permalink
On Tue, 12 Jun 2018 14:25:48 +0800
Post by Xi Ruoyao
efibootmgr uses the library from efivar for /sys/firmware/efi/efivars.
I searched "efivarfs" in the Github repo and found the commit to add
https://github.com/rhboot/efivar/commit/5b175a55d53c5d0f44e3636802fc7dc3fe7549a6
Thanks Xi! Yeah, that ability was added already in mid-2013. And so
efibootmgr will auto select between efivarfs and the sysfs interface
depending on what is available.

So, any post-2013 efibootmgr will be able to use either interface.

From
https://www.kernel.org/doc/Documentation/filesystems/efivarfs.txt.

"The efivarfs filesystem was created to address the shortcomings of
using entries in sysfs to maintain EFI variables. The old sysfs EFI
variables code only supported variables of up to 1024 bytes. This
limitation existed in version 0.99 of the EFI specification, but was
removed before any full releases. Since variables can now be larger
than a single page, sysfs isn't the best interface for this.
"


So, the EFI spec itself changed and that is why we have the new interface.


Mike
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in
Xi Ruoyao
2018-06-11 15:13:29 UTC
Permalink
Post by Michael Shell
On Sun, 10 Jun 2018 07:27:53 -0500
Post by Rob
I just want to make sure this partition layout is correct before
doing grub.
.
.
Post by Rob
Device Start End Sectors Size Type
/dev/sdb1 2048 1050623 1048576 512M EFI System
/dev/sdb2 1050624 32507903 31457280 15G Linux filesystem
/dev/sdb3 32507904 66062335 33554432 16G Linux swap
Rob,
With grub, you should have a grub, aka BIOS boot, partition of about
128.0 MiB, code EF02, after the first, EFI (code EF00) partition. It
is always a good idea to have the BIOS boot partition in case you
ever need grub. IIRC, the grub partition does not need to be
formatted.
Nope. If EFI is used, the BIOS boot partition is unnecessary. It is
used to workaround issues caused by GPT with Legacy Boot.
Post by Michael Shell
The EFI partition, the very first one, is FAT32 and is usually mounted
on /boot/efi when servicing.
Your kernel will have to be compiled with an EFI stub. Under the kernel
[*] EFI runtime service support
[*] EFI stub support
[ ] EFI mixed-mode support
For the Built-in kernel command line (also under "Processor type and
features", you should specify the PARTUUID of your linux filesystem
that is to become /root when booted,
e.g.,
fbcon=font:VGA8x16
Using /dev/sd* works, but your computer may refused to boot with a
USB stick. (My laptop make USB stick /dev/sda if it's detected
on boot.)
Post by Michael Shell
You can get the PARTUUID of the target partition via blkid, e.g.,
blkid /dev/sdb1
The kernel builtin settings can be overridden at load time by another
specification of these kernel parameters, say, from the boot loader
or loader command prompt. This is helpful in emergencies when the
kernel has to be told to use a different partition for /root.
To allow such an override, do not select the kernel config option
[ ] Built-in command line overrides boot loader arguments
under "Processor type and features"
EFI (Extensible Firmware Interface) Support
<*> EFI Variable Support via sysfs
<*> Register efivars backend for pstore
Nope. Now we use CONFIG_EFIVAR_FS (y or m),
instead of CONFIG_EFI_VARS, as the kernel config interface says:

│ efivarfs is a replacement filesystem for the old EFI │
│ variable support via sysfs, as it doesn't suffer from the │
│ same 1024-byte variable size limit. │
--
Xi Ruoyao <***@stu.xidian.edu.cn>
School of Aerospace Science and Technology, Xidian University
--
http://lists.linuxfromscratch.org/listinfo/lfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Do not top post on this list.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-
Continue reading on narkive:
Loading...