On 06/11/2018 07:21 PM, Michael Shell wrote:
On Mon, 11 Jun 2018 21:24:08 +0800
niuneilneo <niuneil...@gmail.com> 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 <r...@stu.xidian.edu.cn> 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
