Gentoo won't boot after successful GRUB install

[pietinger]

I've already solved the issue. For whatever reason, when I installed GRUB into /Efi instead of /Boot it booted straight up.

Thats great. "Efi" is the correct folder-name.

Have fun with gentoo,
Peter


P.S. Please edit your first post of this thread and add something like SOLVED into the headline.

[Tony0945]

Notice that you don't need a /seperate boot either unless grub2 needs it.

This is not correct.

Yes it is. The simple two partition layout that I posted is my actual working layout from my Ryzen box, booting refind UEFI. No grub2. Note that I said "unless grub2 needs it". Separating /boot from / was an artifice caused by old BIOS boots not being able to read a big disk past some point that I don't remember. It doesn't apply to newer mobos. In any case, the UEFI BIOS only has to read the esp sector. From there, refind or the Linux stub kernel are capable of reading anything. So, unless grub2 is so crippled that it needs to boot from a restricted seperate partition, you don't need one.

I don't have a swap from personal preference. People with less memory or who drive their CPUs to the brink of melting, may want a swap. I had one on that computer (32G RAM) originally, but I noticed it was never used. High water mark for RAM was 16G. So, when I bought a larger disk, I didn't partition one.

[pietinger]

Yes it is. The simple two partition layout that I posted is my actual working layout from my Ryzen box, booting refind UEFI. No grub2. Note that I said "unless grub2 needs it". Separating /boot from / was an artifice caused by old BIOS boots not being able to read a big disk past some point that I don't remember. It doesn't apply to newer mobos. In any case, the UEFI BIOS only has to read the esp sector. From there, refind or the Linux stub kernel are capable of reading anything. So, unless grub2 is so crippled that it needs to boot from a restricted seperate partition, you don't need one.

I don't have a swap from personal preference. People with less memory or who drive their CPUs to the brink of melting, may want a swap. I had one on that computer (32G RAM) originally, but I noticed it was never used. High water mark for RAM was 16G. So, when I bought a larger disk, I didn't partition one.

Now its more clear to me what you meant. Thanks.

Today GRUB2 (for UEFI) doesnt need an extra partition and it is not crippled in more parts (like it is when using MBR-boot).
Today, GRUB2 is only one program (like your refind) which is named "grubx64.efi" and it is installed into the /efi-folder like any other UEFI-boot-capable program too.

Greetings,
Peter

[Tony0945]

I found out another situation in which a separate /boot is required. If your root partition is encrypted it stymies your loader. So you need a separate unencrypted /boot for your boot loader to load. That makes sense. OTOH, since your unencrypted kernel knows how to read your encrypted partition, isn't that a security hole in itself?
Also RAID and LVM that some people like or an exotic filesystem that the boot-loader can't read. However, for most people with a PC and ext4 or btrfs file system. It is no longer needed.

EDIT:
IMHO, the manual shouldn't suggest the separate /boot for the common case. Rather it should point out when you need one.

[Hu]

OTOH, since your unencrypted kernel knows how to read your encrypted partition, isn't that a security hole in itself?

If the system can be started unattended, then yes. Typically, people who use an encrypted root will either require a keyfile from an external USB device that they keep safe, or will require a passphrase that the operator must enter.

[pietinger]

OTOH, since your unencrypted kernel knows how to read your encrypted partition, isn't that a security hole in itself?

It would be a securitiy hole if you would store the encryption key also in this unencrypted partition - nobody does this. Therefore working with an encrypted root partition needs one of two main solutions:
1) Working with a password (building a hash and using the result as key) asked before the kernel mounts the root partition, or
2) Working with a key outside the unencrypted partition:
2a) Inside the TPM, or
2b) Inside an external (and removable) storage like an USB-stick
(of course for both solutions the kernel must be able to access this key also before it mounts the root partition).

(Instead of 2b you can "outsource" your kernel also to the usb-stick (with the key) and have only ONE encrypted root-partition on your ssd (root with home) if you dont need a swap partition. This is my notebook; yes, the only ESP is on my stick; described here: https://forums.gentoo.org/viewtopic-t-1 ... ight-.html)

[pietinger]

[...]IMHO, the manual shouldn't suggest the separate /boot for the common case. Rather it should point out when you need one.

IMHO it would be the best to split the description in two parts: One part for MBR and the other for UEFI in two different documents (and not trying to explain both in ONE page).

[Tony0945]

IMHO it would be the best to split the description in two parts: One part for MBR and the other for UEFI in two different documents (and not trying to explain both in ONE page).

Absolutely!

And thanks to Hu and yourself for the explanations. I had assumed that the key would be in kernel. You see I have no experience with encrypted files.


EDIT:
Since UEFI is the most common now, it should present that first with a "see this link for older MBR". But the most important is to state right out front that there are two standards and they are incompatible.

[pietinger]

Since UEFI is the most common now, it should present that first with a "see this link for older MBR". But the most important is to state right out front that there are two standards and they are incompatible.

Totally agree.

[Goverp]

... Don't use grub. Grub has outlived it's usefullness. Use either refind or stub kernel.
Grub was designed for MBR then extended. New system, use new tools. ...

Tony, that's unfair to grub2, which was a complete rewrite and handles UEFI booting well.
There are advantages and disadvantages for each solution in {grub,refind,stub}. Horses for courses:

• Grub has a scripting language and a command-line shell which IMHO makes it useful if you have several different setups (eg: Windows, Gentoo, Gentoo-testing and FreeBSD) on the same box - just build your grub.cfg from the scripting language, and steer well clear of the rubbish grub-mkconfig except to provide a starting point.
• rEFInd does a pretty good job of finding kernels across different systems, but IMHO it's default of the latest dated file is wrong; and it doesn't understand vmlinuz.old if you like having a simple kernel installation mechanism.
• The kernel's UEFI bootloader stub mechanism is fine if you can fit all your boot needs into whatever boot device selection menu your BIOS supports, and then it gives you the fastest and easiest boot. It's a real pain if you need to change the boot command line options, and then you have to fight both your BIOS and efibootmgr, which don't appear to talk to each other like they should.

[pietinger]

• The kernel's UEFI bootloader stub mechanism is fine if [...] It's a real pain if you need to change the boot command line options, [...]

Yes, you are right. But for security reasons booting with UEFI is the best solution if you dont want someone is beeing able to change the command line (I am using the kernel-LSM IMA and therefore it shall not be possible to change the built-in command line with "ima_appraise=enforce")

[Tony0945]

Goverp, that's a pretty fair assessment. However, grub-legacy had a simple script syntax and I found it impossible to even change the kernel version with grub2. Very difficult to read also. I quickly went back to grub-legacy from overlay. The Horse and buggy was an alternative to the <odel A, but even redisgned from the ground up with an aluminum chassis, no competitor to a modern car.

This is Gentoo. This is choice. I would like to see grub-legacy still in the tree, but neither grub should be the default choice. IMO

[NeddySeagoon]

Tony0945,

Grub-legacy does not play well with GPT. It works on some systems but it has the lilo weakness of stage 0, in the MBR loading stage 2 using a block list.
If you have every forgotten to run /sbin/lilo after a kernel update, you know what that means. :)

Without GPT, you are limited to booting from drives smaller than 2TiB. Well there is a horrible hack to make MSDOS partition tables work up to 16TiB but if you need to ask, you really don't want to know about it.

grub-legacy is not generally useful on newer hardware. BIOS mode support is as broken on newer hardware now as UEFI was when it was new.

-- edit --

I don't like grub2 but grub-legacy is in general not the way forward either.

[Tony0945]

If you have every forgotten to run /sbin/lilo after a kernel update, you know what that means.

Oh Yes!

I use grub-legacy on old mobos that don't support UEFI and refind on UEFI hardware.

I recently created a rescue partition on my Phenom II Velociraptor system. I did emerge grub2 because I wanted nothing from overlay, not even my favorite browser (installed Firefox-bin instead).
I used a mid-December portage. I searched the internet for nearly two hours until I found instructions on how to do a partition install. Everything said you can't do that with grub2. I knew that wasn't true because the drive already has an Ubuntu partition with a grub2 partition boot that works. I am successfully chain loading both grub2 partitions from grub-legacy.
I used to use a sysrescuecd but the DVD drive died. I have a sysrescuecd USB stick that boots on the two newer PC's, but the old Gigabyte BIOS doesn't see it. Gentoo does, but not the BIOS.
More googling reveals that Gigabyte in general has problems with USB boot and only sees USB .0 and small sticks at that.

I see lots and lots of threads with problems with Grub 2 on UEFI.

[Goverp]

... grub-legacy had a simple script syntax and I found it impossible to even change the kernel version with grub2. ...

Tony, you might find my grub2 menu script interesting.

[Tony0945]

Tony, you might find my grub2 menu script interesting.

Whoa! That must have been quite a coding job! Thanks.

[Goverp]

One thing I couldn't do was sort the kernels by version number - there's no sort options in the grub scripting language.

[guitou]

Hi there.

One thing I couldn't do was sort the kernels by version number - there's no sort options in the grub scripting language.

Are you sure your "grub" scripting is not simply shell scripting?.. I would just try and use sort.

Code: Select all

- for kernel in /boot/vmlinuz*
+ for kernel in /boot/vmlinuz*|sort -Vr

Edit: looks like I was a little overconfident, just forget this (but leaving it anyway) ^^

++
Gi)

[Goverp]

... Are you sure your "grub" scripting is not simply shell scripting?.. I would just try and use sort. ...

Sadly it isn't. Getting an existing scripting language (e.g. ksh, dash) requires something equivalent to glib and kernel functions, and there's nowhere near that much from pure BIOS, which is where we have to start. Even busybox requires getting something like that. There is an (Intel produced?) efi script engine, and the efi spec defines a byte-code machine (like a baby Java vm), but grub use neither.

In fact, the grub scripting language has some weird quirks - its command line parsing is handled within each command, and is too simple-minded. The regex module confuses parameters with options given the slightest provokation. But it's useable

[Goverp]

FWIW, I worked out how to sort the kernels by version number in my static grub.cfg menu.
I've updated the copy on my wiki page