Installing Gentoo on a secondary disk, with UEFI

Message

wemb · Post by **wemb** » Fri Apr 17, 2020 5:19 pm

Hi guys, I'm hoping someone can give me some advice about what I'm either missing or doing wrong. This inital post is deliberately light on technical data such as partiion layouts as I'm hoping to get the fundamental concepts straight in my head before I go down the route of detailed troubleshooting as it may e that I've simply misunderstood some fundametnal concept rather then have made a specific technical mistake.

I have a Windows 10 system that use UEFI to boot a M.2 SSD. This is working fine.

Due to the current world situation and I'm wanting to temporarily install an Gentoo system onto a secondary HDD that I've attached via SATA to this system. As this is unlikely to be a permanent situation, I do not want to make any changes to the primary SSD (aka. C: drive) - I'm happy to select the boot device in the BIOS to override the default and use the gentoo disk instead of the Windows disk.

I've followed the hardbook as several times how - I'm able to boot, via UEFI, to a USB stick containing the latest Gentoo installation media.

Installation of AMD64 system goes fine, but whatever I do I'm unable to get the system to be able to boot into the new installation. Whatever I've tried so far in terms of making a /boot partition, I see no messages or anything else on the screen other than a blank screen with a underscore at the top left when I select the HDD via the BIOS's boot menu. I can hear the HDD spinning at this point, but can't seem to interact with the system in any way.

I've tried using the partition layout as described in the handbook - ensuring the boot partition is vfat (fat32) and also without a sda1 partition. The effect was the same.

i've tried using genkernel and using a compiled kernel with all the options described in various EFI pages set. Same result.

I've only tried, as far as bootloaders are concerned, following the instructions for configuring GRUB2.

What's fundamentally unclear to me is what I need to be able to get the system to boot by selecting the EFI partition on the HDD via the BIOS boot menu, rather than doing some sort of dual-boot system

It appears to me that my BIOS is detecting the disk, but possibly isn't detecting that it's UEFI configured disk - the USB stick with the installation media gets listed twice - one with [UEFI] prefixed. But my HDD is only ever listed wiht UEFI.

Any advice on where to start trouble shooting with this would be welcome, as I'm not at a blank as where to proceed.

Thanks
Dave

Ant P. · Post by **Ant P.** » Fri Apr 17, 2020 5:34 pm

That doesn't sound correct. An EFI boot menu should detect bootloader programs in the vfat partition, not present a list of partitions.

What does `blkid /dev/sda*` say?

wemb · Post by **wemb** » Fri Apr 17, 2020 6:18 pm

Ah - I misspoke - the BIOS is listing disks, not partitions.

To clarify, I mentioned sda in my original post to not confuse people. The disk in question is sdb.

The output of blkid is

Code: Select all

livecd ~ # blkid /dev/sdb*
/dev/sdb: PTUUID="f5353fa2-700c-4ac3-a878-c7d4af6bf87a" PTTYPE="gpt"
/dev/sdb1: UUID="391C-39D6" TYPE="vfat" PARTLABEL="boot" PARTUUID="e0b82535-d651-4cba-bd57-d550edb71d9d"
/dev/sdb2: UUID="ee705eed-4448-4d28-bd61-348f0211046f" TYPE="swap" PARTLABEL="swap" PARTUUID="3f52b36b-abfb-499b-8e0e-317eea5e4ad2"
/dev/sdb3: UUID="5de936e3-cc43-409b-bfb6-2118932db43c" TYPE="ext4" PARTLABEL="rootfs" PARTUUID="503d1a66-16a1-4cba-8303-6f04e50baf65"

Jaglover · Post by **Jaglover** » Fri Apr 17, 2020 7:19 pm

I personally like easy solutions, I'd use the existing ESP partition in M.2 drive and copy the EFI stub kernel there. Then you can use UEFI boot menu to choose which OS to boot.

jfp · Post by **jfp** » Fri Apr 17, 2020 7:47 pm

I am not 100% sure I am understanding your question, but that is probably my fault not yours...
Please provide the output of

Code: Select all

parted -a optimal /dev/sdb print

Also need to see the directory structure of /boot/efi with both your boot partition and esp partition mounted

Code: Select all

tree /boot/efi

(the tree command is provided by app-text/tree)

wemb · Post by **wemb** » Sat Apr 18, 2020 10:56 pm

Jaglover wrote:I personally like easy solutions, I'd use the existing ESP partition in M.2 drive and copy the EFI stub kernel there. Then you can use UEFI boot menu to choose which OS to boot.

Given I've not been able to get Gentoo installed on an entire disk to be detected by the BIOS, i'm loath to attempt editing the ESP partition on the Windows disk, given at least I still have one working OS. I really don't want a PC with two non-working OS on it,

Thanks

wemb · Post by **wemb** » Sat Apr 18, 2020 11:06 pm

So - thanks to everyone who's replied so far.

I've managed to establish that certainly one of the problems I have is the shonky BIOS in my motherboard - it's a relatively modern Gigabyte B360M DS3H updated to the latest revision.

After attempting to install Gentoo, I noticed several blank entries on the list of bootable devices - none appeared to do anything when selected except immediately drop straight back to the list of bootable devices. However after installing EasyUEFI in windows I observed these were indeed my gentoo entries. All of which were marked as 'disabled'.

Back in the BIOS, in 'classic' mode (i.e. advanced mode), the entries still appeared blank If I switch to 'easy mode', they're listed with their names.

Booting again from the intallation media, chrooting into the disk, re-installing Grub and then installing refind did, eventually, give me a way to boot the system - going into to the BIOS, switching to Easy Mode, changing the order of the boot devices (this is apparently ignored in terms of boot device order, but appeared necessary to make the bios 'see' the ESP properly), save the BIOS settings. Reboot, select the reFind (this time the ESP names appear), and then boot the gentoo system from refind.

In short, the Gigabyte B360M DS3H appears to be a lemon.

Thanks
Dave

charles17 · Post by **charles17** » Sun Apr 19, 2020 6:35 am

wemb wrote:In short, the Gigabyte B360M DS3H appears to be a lemon.

But you are ...?

wemb wrote:... able to boot, via UEFI, to a USB stick containing the latest Gentoo installation media.

Will you try again?
Start with https://wiki.gentoo.org/wiki/EFI_System_Partition. Ensure the computer is booted in UEFI mode when creating the partition. Of cause, Your secondary SSD needs its own ESP.
Proceed with https://wiki.gentoo.org/wiki/EFI_stub_kernel and be sure to copy/move the bzImage to the correct directory. Eventually you need to also copy to /boot/EFI/boot/bootx64.efi (no experience, I never did).
There should be no need at all for having rEFInd or grub.

wemb · Post by **wemb** » Sun Apr 19, 2020 11:39 am

charles17 wrote:
wemb wrote:In short, the Gigabyte B360M DS3H appears to be a lemon.
But you are ...?
wemb wrote:... able to boot, via UEFI, to a USB stick containing the latest Gentoo installation media.

Indeed. As I said, it's a lemon. The BIOS appears to be marking the HD related EFI entries as either 'hidden' (according to EasyUEFI), which appear as empty/blank entries in the 'classic' BIOS page of boot devices, and the F12 'select boot device' menu. But as their expected names in the 'Easy' menu. Selecting the order in the easy menu has no apparently effect on the boot order, which always boots to the Windows disk, and the order is reset back to Windows first everytime I go back into the BIOS. This occurred the first two times I installed Gentoo on this system, as well as this time - so I'm not really convinced that trying a fourth time without doing anything different would be beneficial. My OP was me trying to fill in the blanks to work out if I'd done anything different - but this post

https://www.reddit.com/r/gigabyte/comme ... and_linux/

Has suggested to me I wasn't - these symptoms are exactly the same as mine.

Some random order of rebooting, hitting F12 and switching between 'easy' and 'classic' BIOS mode got me as far as getting into refind, and then into Gentoo last night and I left it overnight emerging kde-plasma.

This morning, after rebooting, I couldn't get back in. Till I moved the SATA cable to the SATA port 0. This had the side effect (not surprisingly) of swapping my sda and sdb arround, but it did cause the BIOS to list the gentoo EFS entries correctly, and booted into the OS again. I've not had time to reboot it more than once, so cannot comment on whether or not this is a fix or a temporary success.

charles17 · Post by **charles17** » Sun Apr 19, 2020 11:47 am

Does that lemon provide an option for setting SATA to AHCI mode?

Jaglover · Post by **Jaglover** » Sun Apr 19, 2020 11:56 am

There is UEFI standard. Motherboard manufacturers try and comply with it. Some may not do the best job.
Adding more than one ESP partition and switching primary drives is a great way to confuse such UEFI firmware.
As I said, the easy way is to put your bootable images in one place - where UEFI expects them to be - ESP partition. It is possible UEFI finds them there and lists them in boot menu without any further action from you. If not, then efibootmgr is the utility which lets you add entries. For example, mine below:

Code: Select all

# efibootmgr 
BootCurrent: 0001
Timeout: 1 seconds
BootOrder: 0001,0000,0002
Boot0000* Gentoo Backup
Boot0001* UEFI OS
Boot0002* Hard Drive

Two latter entries were created by UEFI firmware, automatically. "Boot0001* UEFI OS" is my Gentoo kernel it found. I added "Boot0000* Gentoo Backup" by hand, this is my backup kernel, in case I upgrade and something goes wrong with new kernel. I probably could delete "Boot0002* Hard Drive", but it looks harmless so I left it there.

Anon-E-moose · Post by **Anon-E-moose** » Sun Apr 19, 2020 12:03 pm

Are you running straight uefi (bios) or are you using the compatibility layer (old bios style booting)? You need to pick one and use it exclusively.

If you're in compatibility mode and you set the bios for uefi only how do things work?

Jaglover · Post by **Jaglover** » Sun Apr 19, 2020 12:17 pm

You need to pick one and use it exclusively.

As I read there was Windows installed in EFI mode. Thus, for dual boot sake compatibility mode should not be used.
With Linux setups it does not matter, I have a box here which will boot using syslinux in compatibility mode and since the kernel is EFI stub kernel it will boot straight up in UEFI mode, too.

Anon-E-moose · Post by **Anon-E-moose** » Sun Apr 19, 2020 12:31 pm

I certainly wouldn't go flipping back and forth between uefi and csm modes.

If you have windows installed uefi, then I would recommend shutting off csm mode completely.
With a proper efi boot loader, you could select which disk to boot from, all without touching the bios (once set up properly)

Jaglover · Post by **Jaglover** » Sun Apr 19, 2020 12:36 pm

I certainly wouldn't go flipping back and forth between uefi and csm modes.

Why not? I can do it and my box boots in both modes.

Our OP is refusing to take control of boot and is pushing his UEFI beyond what it was designed for instead. Computers do what we command them to do, not what we want them to do.

Anon-E-moose · Post by **Anon-E-moose** » Sun Apr 19, 2020 2:08 pm

Jaglover wrote:
I certainly wouldn't go flipping back and forth between uefi and csm modes.
Why not? I can do it and my box boots in both modes.

I meant as far as enabling/disabling csm in bios.

Jaglover · Post by **Jaglover** » Sun Apr 19, 2020 2:18 pm

Yes, that's exactly what I meant, too. In CSM mode it boots using syslinux and boot sector from primary hard drive. In UEFI mode it boots the same kernel directly.

wemb · Post by **wemb** » Wed Apr 22, 2020 9:05 pm

charles17 wrote:Does that lemon provide an option for setting SATA to AHCI mode?

Yes it did. The disk was in ahci mode. I've not changed it since moving it to the first sata port.

Dave

wemb · Post by **wemb** » Wed Apr 22, 2020 9:21 pm

Changing between having CSM turned on and turned off had no apparent impact on the issues I was seeing. The only thing has worked was moving the HDD to the first sata port.

This could of course indicate a faulty port or loose cable - but that disk never had any issues before I installed an OS onto it when I accessed it from within Windows. Neither did I have any problems writing data to it, etc. So I feel that's unlikely.

The issue with the BIOS 'losing' the names of the EFI ESPs it's detecting when the system boots has now stopped since moving the SATA port. I can only conclude this is some compatibility issue going on.

As I said, I've found a reference to exactly the issues I had from someone else on reddit using a different Gigabyte board, so my guess is that there's some weird bug or compatibility issue going on.

I've now going a working system - it's far more complex now than it needs to be - what with having refind installed on the gentoo disk - I only put that on as I was getting desperate to try different approaches in case I was missing some subtly in the handbook.

Nonetheless, it's now working, so I'm happy to put this thread to bed.

Thanks everyone for the advice Now in the long slow process of emerging software onto it.

That and wondering why having my iPod shuffle plugged it completely obliterates the entire USB stack if it's plugged in when I boot. Fairly sure the ipod is buggered, so I don't need to troubleshoot that.

Dave

Ant P. · Post by **Ant P.** » Wed Apr 22, 2020 9:42 pm

I wouldn't blame the ipod too much there; nearly every PC I've owned has had problems with the firmware USB stack like that. BIOS coders are an incompetent bunch.

Tony0945 · Post by **Tony0945** » Wed Apr 22, 2020 11:37 pm

If refind is working, refind can give you a enu showing Windows and Linux. You set the timeout before the default boots.

Documentation is here. read the whole thing until you understand it.
Forget grub and syslinux. All you need is refind or stub kernel. I prefer refind for flexibility. With stub kernel, every time you rebuild the kernel you have to copy it to the efi partition. With refind, once it's installed you never touch the EFI partition again. It will give you the choice of old and new kernels until you delete the old kernel.
Edit: with the proper settings in refind.conf it should give you windows as a choice also. no need to fiddle with your bios agin.

BTW, I appreciate the comments on Gigabyte BIOS. I'm an old Gigabyte man but I have an MSI mobo for my ryzen and I like it. BIOS upgrades are easy and the menus are pretty straight forward. For Intel, I don't know. my last Intel was an i486-DX100. great chip but I've been AMD since then.

Vulgar · Post by **Vulgar** » Thu Apr 23, 2020 7:23 pm

On my game machine, which I have always had winblows & linux installed on. When uefi/efi came out fiddled with uefi/efi with linux. But simply bios boot linux. I partition so I can switch latter on if ever desired. Set first partition type bios, then linux, lvm, raid, what ever you want to do. Grub don't care what partition you put the kernel in.

Yea, you have go into bios or use the select drive to switch between the two when you boot. But it always boots, updating has no affect. Since windblows has to be rebooted so often, I usually have bios set to boot that automatically.

Use winblows stuff with windblows, use linux stuff with linux. Keep it simple as simple is safer. Any unnecessary included code can be taken advantage of.

https://uefi.org/sites/default/files/re ... ctices.pdf

ununu · Post by **ununu** » Mon May 11, 2020 4:20 pm

wemb wrote:In short, the Gigabyte B360M DS3H appears to be a lemon.

With such a modern mobo perhaps a solution to have both m$$$ and linux seamlessly would be putting winblows into a VM with hardware passthrough.

I cannot think of any other clean solution with such a m$$$/efi mess.

dual boot is so 2000's