Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Wed, 13 Jun 2018 00:58:09 -0400
Michael Shell  wrote:

> 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 e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Tue, 12 Jun 2018 10:28:26 -0500
Bruce Dubbs  wrote:

> 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
Ken Moffat  wrote:

> 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



lilo_pass_root_as_is.patch
Description: Binary data
-- 
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

Re: [lfs-support] A Question about EFI Partition

[Ken Moffat]

On Tue, Jun 12, 2018 at 10:28:26AM -0500, Bruce Dubbs wrote:
> On 06/12/2018 12:43 AM, Michael Shell wrote:

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

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

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

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

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

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Bruce Dubbs]

On 06/12/2018 12:43 AM, Michael Shell wrote:

On Mon, 11 Jun 2018 23:20:51 -0500
Bruce Dubbs  wrote:


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.


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.



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.



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.



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.



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 

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Tue, 12 Jun 2018 14:25:48 +0800
Xi Ruoyao  wrote:

> 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


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 e-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Xi Ruoyao]

On 2018-06-11 20:21 -0400, Michael Shell wrote:
> On Mon, 11 Jun 2018 23:13:29 +0800
> Xi Ruoyao  wrote:
> > 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.

> 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

Yes.  Systemd mounts efivarfs automatically.  But with sysvinit we should mount
it manually, or in /etc/fstab.
-- 
Xi Ruoyao 
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/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Xi Ruoyao]

On 2018-06-12 01:43 -0400, Michael Shell wrote:
> 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 
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/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Mon, 11 Jun 2018 23:20:51 -0500
Bruce Dubbs  wrote:

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

> 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 

Re: [lfs-support] A Question about EFI Partition

[Bruce Dubbs]

On 06/11/2018 07:21 PM, Michael Shell wrote:

On Mon, 11 Jun 2018 21:24:08 +0800
niuneilneo  wrote:



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.


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.



On Mon, 11 Jun 2018 23:13:29 +0800
Xi Ruoyao  wrote:


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.



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.



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?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Mon, 11 Jun 2018 21:24:08 +0800
niuneilneo  wrote:

> 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
Xi Ruoyao  wrote:

> 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-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Xi Ruoyao]

On 2018-06-11 03:01 -0400, Michael Shell wrote:
> On Sun, 10 Jun 2018 07:27:53 -0500
> "Rob"  wrote:
> 
> > I just want to make sure this partition layout is correct before
> > doing grub.
> 
> .
> .
> > DeviceStart  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.

> 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-16@60
> 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.)

> 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   

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 
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/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Baho Utot]

On 06/10/2018 12:28 PM, Bruce Dubbs wrote:

On 06/10/2018 08:31 AM, Rob wrote:

Xi Ruoyao  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




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.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[niuneilneo]

Dear Michael,It is very nice of you by providing a very detailed instruction to install LFS on EFI booting environment. But I am afraid there is no need to re-invent the wheel, due to that there is a very complete guide for this purpose. This most updated UEFI installation guide is mainly contributed by Xi and already committed to LFS knowledge base. Please check the attachment for this guide.








Yours sincerely,Lei




On 6/11/2018 15:04，Michael Shell wrote： 


On Mon, 11 Jun 2018 03:01:00 -0400Michael Shell  wrote: 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-supportFAQ: http://www.linuxfromscratch.org/blfs/faq.htmlUnsubscribe: See the above information pageDo 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


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 

Re: [lfs-support] A Question about EFI Partition

[Michael Shell]

On Mon, 11 Jun 2018 03:01:00 -0400
Michael Shell  wrote:

> 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/Posting_style

Re: [lfs-support] A Question about EFI Partition

[lei niu]

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 邮箱：niuneil...@gmail.com 签名由 网易邮箱大师 定制 On 
06/11/2018 08:53, Rob wrote: Ken Moffat  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-- 
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

Re: [lfs-support] A Question about EFI Partition

[Rob]

Ken Moffat  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

Re: [lfs-support] A Question about EFI Partition

[Ken Moffat]

On Mon, Jun 11, 2018 at 08:29:50AM +0800, lei niu wrote:
> 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

Re: [lfs-support] A Question about EFI Partition

[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. niuneilneo 邮箱：niuneil...@gmail.com 
签名由 网易邮箱大师 定制 On 06/11/2018 00:28, Bruce Dubbs wrote: On 06/10/2018 08:31 AM, 
Rob wrote: > Xi Ruoyao  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-- 
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

Re: [lfs-support] A Question about EFI Partition

[Bruce Dubbs]

On 06/10/2018 08:31 AM, Rob wrote:

Xi Ruoyao  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  341987   977.0 KiB   EF02  grub
   21988  392612   190.7 MiB   8300  boot
   3  39261439455114   18.6 GiB8300  debian
   43945511578517615   18.6 GiB8302  home
   57851761682423871   1.9 GiB 8200  Linux swap
   682423872   124366911   20.0 GiB8300  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

Re: [lfs-support] A Question about EFI Partition

[Rob]

Xi Ruoyao  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-mail?

http://en.wikipedia.org/wiki/Posting_style

Re: [lfs-support] A Question about EFI Partition

[Xi Ruoyao]

On 2018-06-10 07:27 -0500, Rob wrote:
> I just want to make sure this partition layout is correct before
> doing grub.
> fdisk -l /dev/sdb
> Disk /dev/sdb: 37.3 GiB, 400 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
> 
> DeviceStart  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
.

BTW, why do you need a 16 GB swap?
-- 
Xi Ruoyao 
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/Posting_style