Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
UEFI on ASUS Sabertooth 990fx r2?
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Installing Gentoo
View previous topic :: View next topic  
Author Message
luckylinux
n00b
n00b


Joined: 17 Mar 2012
Posts: 33

PostPosted: Sun Oct 13, 2013 4:57 pm    Post subject: UEFI on ASUS Sabertooth 990fx r2? Reply with quote

I've tried to setup a liveUSB on that given platform which I could also use as a rescue media on other computers.
However, after having installed gentoo on that very platform, the USB key wouldn't boot on that computer anymore (UUID=... is not a valid root block device). In virtualbox it still booted fine ... (not sure if the secure boot setting in ASUS bios is causing some interference: I can either set it to Windows or Other OS, although I can't disable it). I'm using latest BIOS.

I've been told on Gentoo's IRC that I should create a EFI/ESI partition for it to work properly.



Now I have problems finding some good and clear documentation on how to create a liveUSB that would work on both UEFI and BIOS. This is as far as (I think) I understood it:
a) I partition my USB key (or SSD drive connected through USB 3.0 :D ) as GPT
Code:
parted --align=opt /dev/sda
mklabel GPT

b) I create a EFI partition (type EF00 formatted as FAT32, ~512MB), a BIOS boot partition (not formatted, ~1MB) and a boot partition containing kernels (/boot as ext2 or ext3, ~512MB) ???????????????? (not sure if BIOS boot and /boot should be the same)
c) I install GRUB 2 to both UEFI and BIOS boot partition (HOW exactly I don't know)
d) I configure the kernel to work in UEFI mode and integrate initramfs into the UEFI boot image since no external file is supported


I'm a bit lost. Do I really need UEFI in order to enjoy Gentoo :? ? Until now I never had any problems with GPT + Grub (legacy) + BIOS mode. My motherboard UEFI/BIOS settings tells it could also boot from "legacy first" which I assume is BIOS compatibility layer for boot devices.
UEFI is not very easy to setup. Setting up a UEFI/BIOS adaptive liveUSB setup seems to be even worse.

I took a look at http://wiki.gentoo.org/wiki/UEFI_Gentoo_Quick_Install_Guide but I'm not convinced this solution might work for BIOS-only computers.

Does anyone have any idea on how to go about this?
Back to top
View user's profile Send private message
DONAHUE
Watchman
Watchman


Joined: 09 Dec 2006
Posts: 6499
Location: Goose Creek SC

PostPosted: Sun Oct 13, 2013 5:20 pm    Post subject: Reply with quote

http://www.sysresccd.org/Sysresccd-manual-en_How_to_install_SystemRescueCd_on_an_USB-stick does what you want to do.
in a uefi/bios computer with secure boot disabled, the flash drive will appear twice in the boot list, one entry will be marked uefi, one not.
"Other os" is code for "disable secure boot".
_________________
Defund the FCC.
Back to top
View user's profile Send private message
luckylinux
n00b
n00b


Joined: 17 Mar 2012
Posts: 33

PostPosted: Sun Oct 13, 2013 5:25 pm    Post subject: Reply with quote

DONAHUE wrote:
http://www.sysresccd.org/Sysresccd-manual-en_How_to_install_SystemRescueCd_on_an_USB-stick does what you want to do.
in a uefi/bios computer with secure boot disabled, the flash drive will appear twice in the boot list, one entry will be marked uefi, one not.
"Other os" is code for "disable secure boot".

Thank you. This shows how to install SystemRescueCD on USB but it doesn't say anything about UEFI. Or you meant: "take this (which works with UEFI) instead of trying to build your own liveUSB"?

Since (as you said) I disabled secure boot, do I really need to create a UEFI bootable media?
I mean ... is UEFI needed at all in this case?
Back to top
View user's profile Send private message
DONAHUE
Watchman
Watchman


Joined: 09 Dec 2006
Posts: 6499
Location: Goose Creek SC

PostPosted: Sun Oct 13, 2013 6:23 pm    Post subject: Reply with quote

the sysresccd usb flash boots either uefi mode or legacy bios mode depending on which choice is made in bios on a uefi/bios equipped computer. I f the computer does not have uefi, it boots in legacy bios mode by default. If the computer has uefi but secure boot is enabled, sysrescd/usb boots in bios mode by default.
secure boot and uefi are not the same thing. uefi is needed for a standard secure boot installation to work, however uefi does not need secure boot.
_________________
Defund the FCC.
Back to top
View user's profile Send private message
luckylinux
n00b
n00b


Joined: 17 Mar 2012
Posts: 33

PostPosted: Sun Oct 13, 2013 7:47 pm    Post subject: Reply with quote

So for my install on HDD if I don't use UEFI at all would there be any problems (if the system supports BIOS mode)?
Back to top
View user's profile Send private message
DONAHUE
Watchman
Watchman


Joined: 09 Dec 2006
Posts: 6499
Location: Goose Creek SC

PostPosted: Sun Oct 13, 2013 8:56 pm    Post subject: Reply with quote

the machine I'm writing from has windows and gentoo in uefi mode and another gentoo that is legacy bios, not uefi; so the answer is yes, you can ignore uefi and use legacy BIOS .
_________________
Defund the FCC.
Back to top
View user's profile Send private message
srs5694
Guru
Guru


Joined: 08 Mar 2004
Posts: 432
Location: Woonsocket, RI

PostPosted: Tue Oct 15, 2013 4:52 pm    Post subject: Re: UEFI on ASUS Sabertooth 990fx r2? Reply with quote

luckylinux wrote:
I've tried to setup a liveUSB on that given platform which I could also use as a rescue media on other computers.


DONAHUE is giving you good practical advice concerning System Rescue CD. I'd like to address a couple of points, though, just in the interest of promoting understanding of the issues....

Quote:
However, after having installed gentoo on that very platform, the USB key wouldn't boot on that computer anymore (UUID=... is not a valid root block device).


This message implies that either the ability to mount via UUIDs was omitted from the kernel or initrd (I'm not sure exactly what provides that capability) or the UUID of the root (/) filesystem was not as specified. The latter situation can be corrected by either adjusting the UUID of the filesystem (using tune2fs or the like) or by adjusting the UUID references (in /etc/fstab and your boot loader configuration).

Quote:
In virtualbox it still booted fine ... (not sure if the secure boot setting in ASUS bios is causing some interference: I can either set it to Windows or Other OS, although I can't disable it). I'm using latest BIOS.


If Secure Boot were causing problems, you wouldn't even see a boot loader, much less messages about UUIDs not being right. In the event of a Secure Boot failure, most computers skip silently to the next boot loader in the boot list, so the computer would just quietly boot Windows (or whatever is set up as the previously-working OS). In the event that there is no such OS, you'd probably see your firmware setup utility.

Quote:
This is as far as (I think) I understood it:
a) I partition my USB key (or SSD drive connected through USB 3.0 :D ) as GPT
Code:
parted --align=opt /dev/sda
mklabel GPT

b) I create a EFI partition (type EF00 formatted as FAT32, ~512MB), a BIOS boot partition (not formatted, ~1MB) and a boot partition containing kernels (/boot as ext2 or ext3, ~512MB) ???????????????? (not sure if BIOS boot and /boot should be the same)


The "type EF00" is a GPT fdisk (gdisk, cgdisk, sgdisk) type code. GNU parted does not use these type codes. A gdisk type code of EF00 designates an EFI System Partition (ESP), which parted identifies as having its "boot flag" set. Similarly, a BIOS Boot Partition is identified in gdisk as having a type code of EF02, or in parted by having its "bios_grub" flag set.

The Linux /boot partition is a partition that holds the Linux kernel and associated files. Normally it's neither an ESP nor a BIOS Boot Partition, although it is possible to mount the ESP at /boot. This can simplify matters if you use gummiboot or ELILO as your boot manager/loader, but most distributions mount the ESP at /boot/efi, and some (not Gentoo) use symbolic links in /boot, so mounting a FAT32 ESP at /boot can cause problems.

Quote:
c) I install GRUB 2 to both UEFI and BIOS boot partition (HOW exactly I don't know)


Personally, I'd recommend using GRUB 2 for just one boot mode (BIOS or EFI). The reason is that there may be subtle differences in the grub.cfg file and other GRUB support files for BIOS vs. for EFI, so getting both BIOS and EFI versions of GRUB working on one installation could be tricky -- or at least, it might require two different GRUB configuration directories.

I'd probably use GRUB 2 for BIOS mode booting and then use something else for EFI-mode booting. See my Web page on EFI boot loaders for information on what's available. rEFInd is relatively easy to set up, but ELILO is OK if you're comfortable with LILO-style configuration files.

Quote:
d) I configure the kernel to work in UEFI mode and integrate initramfs into the UEFI boot image since no external file is supported


There are EFI kernel options, but most kernels get built with these options by default. (This is probably less true of locally-built Gentoo kernels than of the pre-built kernel binaries for Fedora, Ubuntu, etc.) The EFI boot process does support an external initramfs file, so there's no need to build it into the main kernel file, if you prefer using a separate initramfs.

Quote:
I'm a bit lost. Do I really need UEFI in order to enjoy Gentoo :? ? Until now I never had any problems with GPT + Grub (legacy) + BIOS mode.


Most modern EFIs include a Compatibility Support Module (CSM), which is to EFI as WINE is to Linux -- the CSM enables the EFI to boot using older BIOS boot loaders, just as WINE enables Linux to run Windows programs. Thus, it's usually possible to boot Linux in CSM/BIOS/legacy mode even on newer EFI-based computers. This support may be adequate for many uses of an emergency disk; however, there are some caveats:


  • You might have cause to disable legacy support on your computer -- say, because it slows the boot process (it often does), because you want to use Secure Boot (legacy mode is inherently insecure), or because legacy support is causing some subtle problem (on one of my systems, for instance, it restricts the video modes available early in the boot process). Thus, an emergency disk that boots only in BIOS/CSM/legacy mode might be inconvenient to use, since it might require toggling CSM/BIOS/legacy support on and off.
  • Some computers lack CSMs, and it's possible that they'll become less common in the future, as the need to boot older OSes fades. This might not affect you personally today, but it might be an issue if you want to distribute your disk to others or use your disk in the future.
  • When you boot Linux in BIOS/CSM/legacy mode, you won't be able to use certain EFI features. Most importantly, you won't be able to adjust the EFI's built-in boot manager, which you can do with the efibootmgr utility in Linux when you boot in EFI mode. This is a rather important deficit in an emergency disk, since one of the reasons for running such a disk may be to correct boot problems.
Back to top
View user's profile Send private message
luckylinux
n00b
n00b


Joined: 17 Mar 2012
Posts: 33

PostPosted: Thu Oct 17, 2013 8:57 am    Post subject: Re: UEFI on ASUS Sabertooth 990fx r2? Reply with quote

srs5694 wrote:
luckylinux wrote:
I've tried to setup a liveUSB on that given platform which I could also use as a rescue media on other computers.


DONAHUE is giving you good practical advice concerning System Rescue CD. I'd like to address a couple of points, though, just in the interest of promoting understanding of the issues....

Quote:
However, after having installed gentoo on that very platform, the USB key wouldn't boot on that computer anymore (UUID=... is not a valid root block device).


This message implies that either the ability to mount via UUIDs was omitted from the kernel or initrd (I'm not sure exactly what provides that capability) or the UUID of the root (/) filesystem was not as specified. The latter situation can be corrected by either adjusting the UUID of the filesystem (using tune2fs or the like) or by adjusting the UUID references (in /etc/fstab and your boot loader configuration).

Quote:
In virtualbox it still booted fine ... (not sure if the secure boot setting in ASUS bios is causing some interference: I can either set it to Windows or Other OS, although I can't disable it). I'm using latest BIOS.


If Secure Boot were causing problems, you wouldn't even see a boot loader, much less messages about UUIDs not being right. In the event of a Secure Boot failure, most computers skip silently to the next boot loader in the boot list, so the computer would just quietly boot Windows (or whatever is set up as the previously-working OS). In the event that there is no such OS, you'd probably see your firmware setup utility.

Quote:
This is as far as (I think) I understood it:
a) I partition my USB key (or SSD drive connected through USB 3.0 :D ) as GPT
Code:
parted --align=opt /dev/sda
mklabel GPT

b) I create a EFI partition (type EF00 formatted as FAT32, ~512MB), a BIOS boot partition (not formatted, ~1MB) and a boot partition containing kernels (/boot as ext2 or ext3, ~512MB) ???????????????? (not sure if BIOS boot and /boot should be the same)


The "type EF00" is a GPT fdisk (gdisk, cgdisk, sgdisk) type code. GNU parted does not use these type codes. A gdisk type code of EF00 designates an EFI System Partition (ESP), which parted identifies as having its "boot flag" set. Similarly, a BIOS Boot Partition is identified in gdisk as having a type code of EF02, or in parted by having its "bios_grub" flag set.

The Linux /boot partition is a partition that holds the Linux kernel and associated files. Normally it's neither an ESP nor a BIOS Boot Partition, although it is possible to mount the ESP at /boot. This can simplify matters if you use gummiboot or ELILO as your boot manager/loader, but most distributions mount the ESP at /boot/efi, and some (not Gentoo) use symbolic links in /boot, so mounting a FAT32 ESP at /boot can cause problems.

Quote:
c) I install GRUB 2 to both UEFI and BIOS boot partition (HOW exactly I don't know)


Personally, I'd recommend using GRUB 2 for just one boot mode (BIOS or EFI). The reason is that there may be subtle differences in the grub.cfg file and other GRUB support files for BIOS vs. for EFI, so getting both BIOS and EFI versions of GRUB working on one installation could be tricky -- or at least, it might require two different GRUB configuration directories.

I'd probably use GRUB 2 for BIOS mode booting and then use something else for EFI-mode booting. See my Web page on EFI boot loaders for information on what's available. rEFInd is relatively easy to set up, but ELILO is OK if you're comfortable with LILO-style configuration files.

Quote:
d) I configure the kernel to work in UEFI mode and integrate initramfs into the UEFI boot image since no external file is supported


There are EFI kernel options, but most kernels get built with these options by default. (This is probably less true of locally-built Gentoo kernels than of the pre-built kernel binaries for Fedora, Ubuntu, etc.) The EFI boot process does support an external initramfs file, so there's no need to build it into the main kernel file, if you prefer using a separate initramfs.

Quote:
I'm a bit lost. Do I really need UEFI in order to enjoy Gentoo :? ? Until now I never had any problems with GPT + Grub (legacy) + BIOS mode.


Most modern EFIs include a Compatibility Support Module (CSM), which is to EFI as WINE is to Linux -- the CSM enables the EFI to boot using older BIOS boot loaders, just as WINE enables Linux to run Windows programs. Thus, it's usually possible to boot Linux in CSM/BIOS/legacy mode even on newer EFI-based computers. This support may be adequate for many uses of an emergency disk; however, there are some caveats:


  • You might have cause to disable legacy support on your computer -- say, because it slows the boot process (it often does), because you want to use Secure Boot (legacy mode is inherently insecure), or because legacy support is causing some subtle problem (on one of my systems, for instance, it restricts the video modes available early in the boot process). Thus, an emergency disk that boots only in BIOS/CSM/legacy mode might be inconvenient to use, since it might require toggling CSM/BIOS/legacy support on and off.
  • Some computers lack CSMs, and it's possible that they'll become less common in the future, as the need to boot older OSes fades. This might not affect you personally today, but it might be an issue if you want to distribute your disk to others or use your disk in the future.
  • When you boot Linux in BIOS/CSM/legacy mode, you won't be able to use certain EFI features. Most importantly, you won't be able to adjust the EFI's built-in boot manager, which you can do with the efibootmgr utility in Linux when you boot in EFI mode. This is a rather important deficit in an emergency disk, since one of the reasons for running such a disk may be to correct boot problems.

So you'd struggle to get uefi working even in would take some days?
About the rescue disk i stile don't understand how to support both uefi and bios modes (except usino sysrescuecd directly). Could you elaborate on tris please?

Thank you for your reply. Sorry for the long quote but i am on a tablet and it is not so practical to write efficiently.

The HDd install wall only be uefi if i can get it to work. The recue disk should support both modes. Secure boot is disabled. It is no use in you know what you are doing, right?
Back to top
View user's profile Send private message
srs5694
Guru
Guru


Joined: 08 Mar 2004
Posts: 432
Location: Woonsocket, RI

PostPosted: Thu Oct 17, 2013 4:49 pm    Post subject: Re: UEFI on ASUS Sabertooth 990fx r2? Reply with quote

luckylinux wrote:
So you'd struggle to get uefi working even in would take some days?


It's impossible for me to answer that question, because it depends on the context.

Quote:
About the rescue disk i stile don't understand how to support both uefi and bios modes (except usino sysrescuecd directly). Could you elaborate on tris please?


All I can suggest is to read up on both the EFI-mode and BIOS-mode boot processes and boot loaders. Some references:



I know of no online references that explicitly describe getting the two boot modes to coexist on one medium. That said, the two processes don't compete for the same resources -- boot code goes in different places for the two boot modes, so there need be no real conflict. The greatest potential for conflict exists if the two boot loaders both rely on the same resource, but use it in competing ways -- for instance, if BIOS-mode and EFI-mode versions of GRUB require conflicting entries in the same grub.cfg file in order to work.

Quote:
The HDd install wall only be uefi if i can get it to work. The recue disk should support both modes. Secure boot is disabled. It is no use in you know what you are doing, right?


If by "it" in "it is no use" you're referring to Secure Boot, its advantage is implied by the name: Secure Boot. It prevents unauthorized code from being executed at the boot stage. Without Secure Boot, it's possible for malware to install any code that it likes in place of the standard boot loader. This code could then modify the in-memory kernel or run the kernel in a type of virtual environment, making the malware essentially impossible to detect from the running system. If you're confident that malware can't affect your rescue disk in this way, then Secure Boot would not be of any benefit; but if your rescue disk is on a writable USB medium, I wouldn't be very confident in such an assumption. In fact, even if you use a read-only medium, it's theoretically possible for malware to insert itself in your build environment, although that scenario is a bit on the paranoid side.
Back to top
View user's profile Send private message
luckylinux
n00b
n00b


Joined: 17 Mar 2012
Posts: 33

PostPosted: Thu Oct 17, 2013 5:13 pm    Post subject: Re: UEFI on ASUS Sabertooth 990fx r2? Reply with quote

srs5694 wrote:

If by "it" in "it is no use" you're referring to Secure Boot, its advantage is implied by the name: Secure Boot. It prevents unauthorized code from being executed at the boot stage. Without Secure Boot, it's possible for malware to install any code that it likes in place of the standard boot loader. This code could then modify the in-memory kernel or run the kernel in a type of virtual environment, making the malware essentially impossible to detect from the running system. If you're confident that malware can't affect your rescue disk in this way, then Secure Boot would not be of any benefit; but if your rescue disk is on a writable USB medium, I wouldn't be very confident in such an assumption. In fact, even if you use a read-only medium, it's theoretically possible for malware to insert itself in your build environment, although that scenario is a bit on the paranoid side.


Maybe I lost one or two episodes of the Secure Boot speech from Richard Stallman :D, but as far as I remembered only a few distros (SUSE?, Ubuntu?, Fedora?) admitted that they would support the Secure Boot feature.

Do you use Secure Boot? I think it would in most cases prevent any custom compiled kernel to be run (I suppose each and every kernel version and config has to be validated for Secure Boot). I think it may be a pain to set up (mailnly because I own two physically separated desktops: one for Win7, one for Gentoo and for the very few malware that GNU/Linux "has" we don't even need an antivirus so ...).

I agree on your comment about the USB stick though, in that case it may be useful.
Back to top
View user's profile Send private message
srs5694
Guru
Guru


Joined: 08 Mar 2004
Posts: 432
Location: Woonsocket, RI

PostPosted: Fri Oct 18, 2013 4:35 pm    Post subject: Re: UEFI on ASUS Sabertooth 990fx r2? Reply with quote

luckylinux wrote:
Maybe I lost one or two episodes of the Secure Boot speech from Richard Stallman :D, but as far as I remembered only a few distros (SUSE?, Ubuntu?, Fedora?) admitted that they would support the Secure Boot feature.


First, things change. At the moment, Fedora, SUSE, and Ubuntu all support Secure Boot with their own signed versions of shim, and several others (Arch, ALT, Mint, and others I don't recall offhand) support it via PreLoader or somebody else's signed shim. As a practical matter, any distribution that wants to be easy to install on a stock Windows 8 computer must support Secure Boot. Any distribution that does not support Secure Boot can be installed on a computer that shipped with Windows 8 only by having the user jump through extra hoops -- hoops that are essentially impossible to fully document, because they vary from one computer to another. Supporting Secure Boot is becoming something like supporting USB in the late 1990s -- it's something that's required if a distribution is not going to fall into irrelevance.

Second, users can add their own Secure Boot support to any distribution. This process is not easy by the standards of a Fedora or Ubuntu install, but it's well within the reach of an experienced Gentoo users.

Third, you're talking about setting up your own emergency disk. For that, you can do anything you want, no matter what Richard Stallman says, or what Fedora, Ubuntu, SUSE, or even Gentoo does. You have to decide what your needs are (and those of your users, if this is something you intend to distribute).

Quote:
Do you use Secure Boot?


Yes, but mainly for testing -- as I develop rEFInd, which explicitly supports shim, I need to be able to test rEFInd's Secure Boot features. I'm not too worried about boot-time malware on my own computers, but that could change -- and if I were managing computers that routinely dual-booted to Windows or that were particularly sensitive, I'd be more wary.

Quote:
I think it would in most cases prevent any custom compiled kernel to be run (I suppose each and every kernel version and config has to be validated for Secure Boot).


If you use shim, you can sign any EFI binary or kernel you want with your own key and add that key to shim's Machine Owner Key (MOK) list. If you use PreLoader, you can add any kernel hash you want to PreLoader's list of validated hashes. Either way, this enables you to use any kernel you want. That said, such a setup only validates the kernel; unless the kernel has been modified (as Fedora does) to limit follow-on kernel module loading and whatnot, the chain of trust ends at the kernel.

Quote:
I think it may be a pain to set up (mailnly because I own two physically separated desktops: one for Win7, one for Gentoo and for the very few malware that GNU/Linux "has" we don't even need an antivirus so ...).


You'll have to decide for yourself, of course. You can read my general page on Secure Boot and/or my rEFInd Secure Boot documentation to learn more about how it works in practice.
Back to top
View user's profile Send private message
djdunn
l33t
l33t


Joined: 26 Dec 2004
Posts: 689
Location: Arrakis

PostPosted: Sat Oct 19, 2013 2:28 am    Post subject: Reply with quote

about 2 boot modes on one disk, there is a MBR on a GPT disk, if you have the *.efi file with the default name in the default place in /boot/efi/boot you can have your mbr booting stuff in /boot/. so when the computer tries to boot uefi it looks in the default place for the default name, and boots the *.efi file using its config, else if it cant find or read that .efi file it looks at the MBR and continues on with the classical boot process.

secure boot isn't worth the time, its for keeping windows on windows machines,

UEFI is extremely simple, as long as your not using grub2....


All you need is 1 partition at the beginning of the drive fat32 GPT disk type code EF00, same partition can be used for /boot, when people are saying you have to boot a UEFI bootdisk to setup UEFI mode, they are just using the UEFI bootdisk in order to use efibootmgr to make a new UEFI boot option, which you dont have to do normally.

you need to then decide if you want old uefi support or new one

in the kernel you need EFI_PARTITION=y and one of the following "not both"

EFI_VARS=y or the newer EFIVAR_FS=y "not both"

personally id choose the newer EFIVAR FS, though efibootmgr doesnt work on it yet, like i said before you dont need efibootmgr

i suggest using syslinux to boot EFI, just emerge syslinux:6, note its version 6+ you need to boot UEFI

then copy the contents of /usr/share/syslinux/efi64 to /boot/efi/boot/ where /boot is mounted to your fat32 EFI partition

then rename syslinux.efi to bootx64.efi,

and as long as you have secureboot off you should be able to boot UEFI
_________________
"Yesterday is history, tomorrow is a mystery, but today is a gift. That is why it is called the present."

-Master Oogway
Back to top
View user's profile Send private message
luckylinux
n00b
n00b


Joined: 17 Mar 2012
Posts: 33

PostPosted: Sat Oct 19, 2013 3:41 pm    Post subject: Reply with quote

djdunn wrote:
secure boot isn't worth the time, its for keeping windows on windows machines,

Thank you for your answer. What about dual boot? Or you mean that it was a tool to avoir users installing other OSses on windows machines?


About UEFI: should the command line be embedded in the kernel or can syslinux call the kernel through the "standard" command line along with an initramfs?
Back to top
View user's profile Send private message
srs5694
Guru
Guru


Joined: 08 Mar 2004
Posts: 432
Location: Woonsocket, RI

PostPosted: Sat Oct 19, 2013 4:55 pm    Post subject: Reply with quote

djdunn wrote:
UEFI is extremely simple, as long as your not using grub2....


GRUB 2 certainly is a complication. Unfortunately, there are others, too, such as EFI bugs and the needs of a dual-boot setup....

Quote:
when people are saying you have to boot a UEFI bootdisk to setup UEFI mode, they are just using the UEFI bootdisk in order to use efibootmgr to make a new UEFI boot option, which you dont have to do normally.


This can work well in a single-boot environment, but when dual-booting with Windows, it becomes harder to work as you suggest. This is because Windows will create an EFI boot manager entry in NVRAM, which will then cause the computer to boot Windows, bypassing the fallback EFI/BOOT/bootx64.efi filename. (At least, if your firmware is not broken. With a broken firmware, this entry might be lost.) I've seen reports that at least some versions of Windows will look for a missing entry and re-create it, so deleting the entry won't do any good; you usually have to create your own entry for Linux using efibootmgr or some other tool when dual-booting. The main alternative is to "hijack" the Windows boot loader (EFI/Microsoft/Boot/bootmgfw.efi) with whatever you want to use.

Quote:
i suggest using syslinux to boot EFI, just emerge syslinux:6, note its version 6+ you need to boot UEFI


AFAIK, SYSLINUX has no ability to chainload to another EFI boot program. Thus, in a dual-boot configuration it's not ideal. To be sure, you can use it to boot Linux in such a situation, but you'll need another boot manager to select between Linux and Windows. Most EFIs include a built-in boot manager, but they're usually awkward and require hitting a function key to access at boot time. If you want something that pops up automatically, that gives you a choice of Fedora's patched GRUB Legacy, GRUB 2, rEFIt, rEFInd, and gummiboot. See my Web page on the topic for details. Note that rEFInd and gummiboot both boot the kernel via its EFI stub loader, so you must either include the CONFIG_EFI_STUB kernel option or use another boot loader (such as SYSLINUX, ELILO, or one of the GRUBs) to boot the kernel. rEFIt is very awkward for use with the EFI stub loader; as a practical matter, it requires another boot loader.
Back to top
View user's profile Send private message
luckylinux
n00b
n00b


Joined: 17 Mar 2012
Posts: 33

PostPosted: Sat Oct 19, 2013 5:26 pm    Post subject: Reply with quote

This is driving me crazy.
Now I moved my "live" installation from USB key to an SSD in a USB 3.0 enclosure and while it doesn't complain about the UUID anymore (I used PARTUUID this time), I do get many errors concerning the INIT process:

Code:

INIT: cannot execute "/sbin/rc"
INIT: cannot execute "/sbin/agetty"
(repeated many times)


However the files exist in /sbin/ and their permissions should be ok. Not sure what is wrong here ...
I don't know if doing a fresh install could be of any help.

cp -R myfolder /destination/ should preserve permissions and flags, right?
Back to top
View user's profile Send private message
jathlon
Tux's lil' helper
Tux's lil' helper


Joined: 26 Sep 2006
Posts: 89
Location: Canada

PostPosted: Sun Oct 20, 2013 12:04 am    Post subject: Reply with quote

luckylinux wrote:

cp -R myfolder /destination/ should preserve permissions and flags, right?


Anytime permissions/flags are important to me, I use;

Code:
~ $ cp -av <source> <destination>


From the man page;

-a, --archive same as -dR --preserve=all
-v, --verbose explain what is being done

Using just the -R may or may not get permissions and flags correct. You really need to specify -p -or --preserve.

--preserve[=ATTR_LIST] preserve the specified attributes (default: mode,ownership,timestamps), if possible additional attributes: context, links, xattr, all

hth,

joe
Back to top
View user's profile Send private message
luckylinux
n00b
n00b


Joined: 17 Mar 2012
Posts: 33

PostPosted: Sun Oct 20, 2013 3:29 pm    Post subject: Reply with quote

jathlon wrote:
luckylinux wrote:

cp -R myfolder /destination/ should preserve permissions and flags, right?


Anytime permissions/flags are important to me, I use;

Code:
~ $ cp -av <source> <destination>



Thank you for this precious information. I assumed everything was preserved by default.
Now I'm doing a clean stage3 install which is still driving me crazy.

Don't know what the problem with GRUB2 is. I tried the default generated entry (UUID) and a custom one (PARTUUID) but both say that they're not valid entries for root device. They do exist in /dev/disk/by-uuid/ and /dev/disk/by-partuuid/ though.

Quote:
With UUID (automatically generated entry)
<Scanning for modules>
iscsistart: transport class version 2.0-870. iscsid version 2.0-872
Could not get boot entry. // <-- What?
Determining root device ...
Could not find the root block device in UUID=MY_UUID.
Please specify another value or: press Enter for the same, type "shell" for a shell, or "q" to skip ...
root block device(UUID=MY_UUID) ::

(Frozen. No keyboard input is accepted. Possible kernel panic)


Quote:
With PARTUUID (manually generated entry)
<Scanning for modules>
iscsistart: transport class version 2.0-870. iscsid version 2.0-872
Could not get boot entry. // <-- What?
Determining root device ...
Block device PARTUUID=MY_PARTUUID is not a valid root device ...
Could not find the root block device in .
Please specify another value or: press Enter for the same, type "shell" for a shell, or "q" to skip ...
root block device() ::

(Frozen. No keyboard input is accepted. Possible kernel panic)


My SSD is partitioned as follows (GPT):
Quote:
Partition 1 (1 MiB) -> bios_grub (BIOS) , not formatted
Partition 2 (512MiB roughly) -> boot (EFI) , fat32
Partition 3 (512MiB roughly) -> /boot , ext3
Partition 4 (60GB roughly) -> / , ext4



Any idea what is going on?
I even tried GRUB legacy (0.97-r3 IIRC) but it wouldn't even load stage2 ...

(I'm setting this up is BIOS legacy mode at first. I'll try UEFI later on ...)
Back to top
View user's profile Send private message
_______0
Guru
Guru


Joined: 15 Oct 2012
Posts: 521

PostPosted: Sat Nov 02, 2013 8:39 pm    Post subject: Reply with quote

Are you still trying this?

Recomendation, use a compact $5 USB flash drive to do the uefi weirdeness.

F8
select UEFI <your usb flash drive>

When preparing for first time boot use /dev/sda format for root to make things uncomplicated.

By the way, blkid gets you the UUIDs necessary.

Oh wait, I AM booting with UUID. But that's just for the boot partition.

The whole operation is not that complicated.

Regarding the dual boot, my reccomendation is to give up. With that mobo you can set up a more modern solution. Your mobo supports GPU passthrough, use it with kvm or xen.

regards.
Back to top
View user's profile Send private message
luckylinux
n00b
n00b


Joined: 17 Mar 2012
Posts: 33

PostPosted: Sat Nov 23, 2013 6:56 pm    Post subject: Reply with quote

I now get a GRUB2 boot menu for UEFI. Using BIOS mode I get the menu and can boot.
I had however to give up on using the SSD through an USB adapter. Now it can boot at least :o

However, as soon as I get to the login prompt, it freezes. No action on the keyboard has any effect (not even CTRL + ALT + DEL).
No log is present at /var/log/messages. No idea what is going on.

I must say that I'm quite frustrated. A long time ago I didn't have all those issues with Gentoo (not so much effort to just make it boot anyway ...).

I really liked the option to choose which version of which package to install (main reason why I chose Gentoo).
But if this means that I can't even boot a minimal installation without freezing for an unknown reason, I fear I'll have to switch (back) to Debian which is not nearly as much as flexible as Gentoo.

It's really unfortunate, because Gentoo seemed to offer the flexibility I was looking for.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Installing Gentoo All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum