| View previous topic :: View next topic |
| Installed Gentoo on EFI yet? |
| Yes/x86* Macintosh |
|
3% |
[ 2 ] |
| Yes/x86_64 PC |
|
60% |
[ 38 ] |
| Yes/i386 PC/Tablet |
|
0% |
[ 0 ] |
| Yes/ARM, ia64, other |
|
1% |
[ 1 ] |
| Yes, multiple architectures. |
|
4% |
[ 3 ] |
| No, MBR forever/EFI is devil spawn |
|
4% |
[ 3 ] |
| No, no EFI capable machines |
|
25% |
[ 16 ] |
| I've never installed Gentoo... |
|
0% |
[ 0 ] |
|
| Total Votes : 63 |
|
| Author |
Message |
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
 Posted: Thu Dec 25, 2014 2:23 am Post subject: |
 |
|
Nope, no options whatsoever. I was expecting it to die when it can't find init (because I did not even specify root=... ) but I don't even get that far...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
 |
Progman3K
l33t
Joined: 03 Jan 2004
Posts: 773
|
| Posted: Thu Dec 25, 2014 7:46 am Post subject: |
|
|
Do you have these values set in your kernel .config ?
| Quote: | CONFIG_EFI_PARTITION=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_EFI_MIXED=y
CONFIG_FB_EFI=y
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
CONFIG_EFI_VARS=y
CONFIG_EFI_RUNTIME_MAP=y
CONFIG_EFIVAR_FS=y
CONFIG_EARLY_PRINTK_EFI=y
|
I think the highlited ones are important for debug output.
I'm not using an initrd, are you? I compiled everything statically, set
| Quote: | | CONFIG_INITRAMFS_SOURCE="/usr/share/v86d/initramfs" |
and emerged v86d. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Thu Dec 25, 2014 5:14 pm Post subject: |
|
|
All my EFI config:
| Code: | CONFIG_EFI_PARTITION=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_FB_EFI=y
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
CONFIG_EFI_VARS=y
CONFIG_EFI_RUNTIME_MAP=y
CONFIG_EFI_RUNTIME_WRAPPERS=y
CONFIG_UEFI_CPER=y
CONFIG_EFIVAR_FS=y
CONFIG_EARLY_PRINTK_EFI=y
|
I have an initrd that I prepared for my other boxes but not using it yet...
Hmm... wonder what EFI_MIXED does... but might not exist in this kernel... (3.18.1)
[edit]
Oh well, can't use EFI_MIXED anyway:
| Code: | | Depends on: EFI_STUB [=y] && X86_64 [=n] |
Defining X86_64 would make it even less likely to boot (since it's in UEFI32 mode)...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
james.h.bates
n00b
Joined: 11 Jul 2013
Posts: 12
|
| Posted: Thu Dec 25, 2014 6:16 pm Post subject: |
|
|
| khayyam wrote: | | james.h.bates wrote: | | I use elilo since I use OS X's "bless" to set it as the default bootloader. This way I don't need need to boot OSX and rebless every time I do a kernel upgrade (which is what would be necessary if I used EFI stub). |
james ... actually, "blessing" is only necessary for HFS+ filesystems, you can use efi stub on vfat (ESP) as the EFI standard requires that the firmware supports loading efi executables from the ESP and that this filesystem is vfat. The standard also states a default loader of {ESP}/efi/boot/boot{ia32,x64}.efi (dependent on architecture) so this can be used without having to change anything in NVRAM/efivars (though the Apple EFI firmware doesn't automatically boot from this, the "alt" key needs to be pressed, as for some reason the Apple doesn't use the ESP at all for booting OSX, the efi executable on the OSX install, if it exists, is given precedence). Suffice to say, booting without OSX and/or a HFS+ partition is in fact possible.
| james.h.bates wrote: | | [...] conf and kernels must reside on a HFS+ partition though (so mac firmware can boot it), so basically my /boot is HFS+. |
No, in fact you could probably setup elilo and your kernels on the ESP. If you look at your partition scheme you will see a 200mb partition (code "EF00") which is the ESP (EFI System Partition) this is part of the EFI specification, and Apple's EFI firmware will boot from it if you provide an entry in NVRAM/efivars (ie, with efibootmgr).
best ... khay |
Thanks for those pointers. Yes I did actually know about the ESP, which OS X installs and uses for Firmware updates. But to be honest, I couldn't care less if my /boot is HFS+ or vfat. So whether I put the boot stuff on the "official standards-compliant ESP" or the blessed HFS+ partition really makes no difference to me  I keep OS X around because I use it sometimes (about twice a year or so) anyway.
But thanks anyway. I might try out the ESP just for the fun of it one of these days... |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Thu Dec 25, 2014 6:30 pm Post subject: |
|
|
You know, after reading what CONFIG_EFI_MIXED does,it might be worth to try anyway... Though it looks like I can't use the direct boot anymore and have to rely on grub2 or something.
Hmm...
Time to try building a 64-bit kernel, this Atom should run 64-bit binaries!!!
[EDIT]
Gah...still dead, no output to the screen.
| Code: |
grub> linuxefi /efi/bzImage-3264multi.efi
grub> boot
<<<HANG...>>>
|
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Progman3K
l33t
Joined: 03 Jan 2004
Posts: 773
|
| Posted: Fri Dec 26, 2014 12:57 am Post subject: |
|
|
The initramfs might help you, if you are not using a required initrd.
I believe it is the first thing done? Compiling it into the kernel might work.
How many modules do you have compiled non-statically?
grep "\=m" .config |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Fri Dec 26, 2014 1:11 am Post subject: |
|
|
It's mostly drivers that are set as modules, and I don't think there are way too many (virtualization, etc.). However this is during initialization or handover that it fails, initrd would fail the same way because its "init" would never run, either.
The theory is that any compiled module kernel have enough to at least print something to the screen... but it doesn't.
The only possible thing I can think of now is perhaps I should statically build intel+KMS into the kernel as maybe EFI FB is completely useless on this machine...
I may have to start pulling apart what RH did to get their kernel to run. Just that now I need another USB media big enough to hold it, after I used my only one to build a Gentoo install...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Progman3K
l33t
Joined: 03 Jan 2004
Posts: 773
|
| Posted: Fri Dec 26, 2014 2:53 am Post subject: |
|
|
| eccerr0r wrote: | The theory is that any compiled module kernel have enough to at least print something to the screen... but it doesn't.
The only possible thing I can think of now is perhaps I should statically build intel+KMS into the kernel as maybe EFI FB is completely useless on this machine... |
You may be on to something, I have progressed to where I have the GUI running.
The thing is, while I used either the EFI framebuffer or nouveaufb, like in your case, it would never perform the handoff correctly or simply hang.
In the best case, using CONFIG_FB_EFI seems to permit the kernel printk and console 0 login, but no X.
Instead, I have switched the kernel to FB_VESA and VIDEO-CARD="vesa" in make.conf after trying efi, nouveaufb and the nvidia proprietary drivers.
The kernel command-line is
CONFIG_CMDLINE="root=/dev/sda2 init=/usr/lib/systemd/systemd video=vesafb:mtrr:3,ywrap vga=0x0318"
So now, when the kernel boots, the screen is black, no printk output appears but a fraction of a second later, the GDM chooser prompts me for my login. It's very odd. From the moment the Firmware logo appears and loads the kernel, it's like X and GDM start in less than a second.
Of course I suspect video is NOT accelerated like this. |
|
| Back to top |
|
|
Progman3K
l33t
Joined: 03 Jan 2004
Posts: 773
|
| Posted: Fri Dec 26, 2014 2:55 am Post subject: |
|
|
And even when I set the vesa mode, at first it still would not start X because I had an old
/lib64/modules/3.16.5-gentoo/video/nvidia.ko
laying around.
Deleting it is what made vesa start the graphical mode.
The downside is that none of the text-mode ttys display anything, but X and Gnome work. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Fri Dec 26, 2014 6:58 am Post subject: |
|
|
Hmm!
Some data is better than no data:
When I removed FB_EFI and put in Intel KMS, the screen at least blanks when run "boot" where it would just hang before...
Progress I say! Alas still very hard to tell what it's doing when the screen is blank...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Progman3K
l33t
Joined: 03 Jan 2004
Posts: 773
|
| Posted: Sat Dec 27, 2014 3:38 am Post subject: |
|
|
| eccerr0r wrote: | It's mostly drivers that are set as modules, and I don't think there are way too many (virtualization, etc.). However this is during initialization or handover that it fails, initrd would fail the same way because its "init" would never run, either.
The theory is that any compiled module kernel have enough to at least print something to the screen... but it doesn't.
The only possible thing I can think of now is perhaps I should statically build intel+KMS into the kernel as maybe EFI FB is completely useless on this machine... |
So you have never seen any kernel emit a trace. Maybe the kernel's init is not even being run because there are files missing.
I believe you should enable the initramfs. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sat Dec 27, 2014 1:11 pm Post subject: |
|
|
| genstorm wrote: | | Why back to BIOS when you could have coreboot? |
Because it worked and had everything a field technician really needed. AIUI from mira, there's no real technical reason a BIOS would not work with larger disks and 64-bit kernels, since the kernel does all the heavy-lifting once it's started, and it doesn't matter whether the BIOS is in 32-bit or 64-bit mode when the kernel starts up, since it always reinitialises in any case.
Personally I'd much rather buy a BIOS-based board for the freedom from the Wintel monopoly; and I think quite a few other people running Free systems would opt for it, given the choice, simply so that they didn't have to go through all these hoops, and worse have to get their bootloader ultimately-signed by M$.
From the manufacturer side, it's less expense, since most of them had licenses for eg Award or whomever's BIOS that entitled them to keep patching and releasing; and it appeals to the "niche" market that happens to run the internet. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Dec 27, 2014 2:24 pm Post subject: |
|
|
| steveL wrote: | | Personally I'd much rather buy a BIOS-based board for the freedom from the Wintel monopoly; and I think quite a few other people running Free systems would opt for it, given the choice, simply so that they didn't have to go through all these hoops, and worse have to get their bootloader ultimately-signed by M$. |
steve ... you are repeating oft heard misrepresentations of UEFI. Firstly UEFI is a standard, its only relation to MS is that MS is part of the UEFI Forum ... but so is AMD, Intel, Apple, Redhat, and practically every other major hardware/software vendor. Secondly, UEFI isn't secureboot, that is an "extension" to UEFI, its not required and where provided can be disabled, so there is no requirement that the loader is signed by MS.
Now, whats so great about "bios"? It too is non-free, has numerous implementations (with all that entails), uses MBR (with its inherent issues/limitations), etc. UEFI is far better, when using EFI/GPT all that is needed is an efi executable and the firmware to be told where on the filesystem that efi executable resides (there is even a default location in the specification). UEFI is also more generic with regard to hardware (and so, unlike "bios" isn't specifically for IBM PC compatible computers). The issue as I see it is that vendors (the same vendors who provided 'bios', like American Megatrends and Phoenix Technologies) are the ones making the actual implementation, and so you get varying interpretations (or implementations) of the standard (similar to bios in that regard) which means that you end up with all of these essentially different firmwares going by the same name, with each implementation bringing with it one or other variation, or 'fix', for some or other reason (like hybrid-mbr so that win* would boot via efi even though the OS didn't support it). All this leads where you'd expect, but I'm not sure we should blame the standard for this.
best ... khay |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Dec 27, 2014 2:46 pm Post subject: |
|
|
| eccerr0r wrote: | | When I removed FB_EFI and put in Intel KMS, the screen at least blanks when run "boot" where it would just hang before... Progress I say! Alas still very hard to tell what it's doing when the screen is blank... |
eccerr0r ... have you tried using an older kernel as I suggested? Something like 3.12.35 would probably be a good choice as it would have been somewhere 3.14.x where I saw a similar dead screen (I suspect that some issue in relation to 32bit efi was introduced as I wasn't able to work around the issue and so went back to a known working kernel).
As far as KMS is concerned I wouldn't enable any other framebuffer, inteldrmfb has had issues when this is the case. BTW, you do have CONFIG_RELOCATABLE=y enabled? The following config should be all that's needed:
CONFIG_EFI=y
CONFIG_RELOCATABLE=y
CONFIG_FB_EFI=y
CONFIG_EFI_PARTITION=y
CONFIG_EFI_VARS=m
CONFIG_EFI_STUB=y
HTH & best ... khay |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Sat Dec 27, 2014 6:24 pm Post subject: |
|
|
Yeah, 3.12.35, 3.16.5, and 3.18.1 all seemed to behave the same (where did I post that, oops, guess not in this thread.) I suppose I'm trying to focus on 3.18.1 because that's the kernel that Fedlet uses and appears to get farthest along - though there are their own patches in that kernel.
It looks like CONFIG_RELOCATABLE is automatically set when CONFIG_EFI is set.
I'm fairly certain now with that bit of evidence collected earlier that UEFI did its job and now it's just cracking the whip at Linux... Or possibly at this tablet...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
Maffblaster
Developer
Joined: 01 May 2007
Posts: 70
Location: Spokane, Washington, USA
|
| Posted: Sat Dec 27, 2014 10:01 pm Post subject: |
|
|
I have successfully gotten EFI to work using Grub2 on both a MacBook Pro (2005) (without rEFInd; just using Grub2) and a ThinkPad W530. Both great for me! Hardest thing to remember is that you need need the "GRUB_PLATFORMS" variable set in /etc/portage/make.conf when using Grub2.
_________________
Lets make Gentoo better together!
wiki: https://wiki.gentoo.org/wiki/User:Maffblaster
blog: http://dev.gentoo.org/~maffblaster/ |
|
| Back to top |
|
|
NeddySeagoon
Administrator
Joined: 05 Jul 2003
Posts: 54236
Location: 56N 3W
|
| Posted: Sat Dec 27, 2014 10:20 pm Post subject: |
|
|
Being old and cynical, I am quite happy with the mixture of BIOS and GPT.
An MSDOS disk label replacement was needed. The MSDOS version has been extended/reinvented several times.
It even started life as a hack. GPT is really no more than the MSDOS disk label done properly.
There is really no connection between the BIOS and the disk label but some broken BIOSes check for the boot flag in the MSDOS disk label.
_________________
Regards,
NeddySeagoon
Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Sun Dec 28, 2014 9:23 pm Post subject: |
|
|
| steveL wrote: | | Personally I'd much rather buy a BIOS-based board for the freedom from the Wintel monopoly; and I think quite a few other people running Free systems would opt for it, given the choice, simply so that they didn't have to go through all these hoops, and worse have to get their bootloader ultimately-signed by M$. |
| khayyam wrote: | | steve ... you are repeating oft heard misrepresentations of UEFI. Firstly UEFI is a standard, its only relation to MS is that MS is part of the UEFI Forum ... but so is AMD, Intel, Apple, Redhat, and practically every other major hardware/software vendor. Secondly, UEFI isn't secureboot, that is an "extension" to UEFI, its not required and where provided can be disabled, so there is no requirement that the loader is signed by MS. |
Your first point is like claiming OoO.xml didn't get suborned by MS, and in effect lead to a binary standard allowing whatever the hell MS wants to stuff in there to lock people into Word. As well as seeming to appeal to a claim to authority, as if corporations hadn't clearly shown time and again, that they have zero interest in our welfare.
The second begs the question "then why not just a BIOS?" (apart from the point about GPT partitioning, which doesn't require UEFI by any means.) And misses the point that people are still being sold a lie of security, much like basically everything on Windows to do with security (which seems rather intended to keep everyone in a make-work job, slowing us all down, and more broadly to keep us under control rather than secure as most of us understand the term.)
| Quote: | | Now, whats so great about "bios"? It too is non-free, has numerous implementations (with all that entails), uses MBR (with its inherent issues/limitations), etc. UEFI is far better, when using EFI/GPT |
If GPT were not seen as somehow "requiring" UEFI then we wouldn't be having this discussion, imo. BIOS based can be done with another partitioning scheme, from what I've been told; it's only about the code accessing the drive, not the rest of the UI bloat. ISTR being told it doesn't matter at all if it's just going to look at the first part of the disk in any case. But I'm not claiming expertise here, and could well be mistaken as to the latter. But this is the nub of the point: if we had BIOS with GPT support for 64-bit kernels, as a choice in the vast panoply of consumer-choice we supposedly have, I reckon many would prefer that.
I've chopped out the part about a default location as I don't see any difference, and as for "generic hardware" that seems another pretext to me. Either way it doesn't add anything, when it comes to getting a result; though it sounds like it could. It's just a deflection from all the other crap put in there.
| Quote: | | All this leads where you'd expect, but I'm not sure we should blame the standard for this. |
It's perfectly possible for a standard to have some valid points in it, yet still be inescapably a creature of its sponsors. The best liars always weave truth into the cloth, and at some point you have to get things done. It's at that point, when we're actually discussing what needs to be done, that we tend to see the difference between what is necessary and what is political.
All the negatives you raise about BIOS development, seem to apply even more to UEFI implementations, and personally I believe the whole thing is a waste of time, more about turning users into consumers than anything else. I'd rather just use the simpler setup, with less code that has been through several cycles of iterative development, does what we need and no more; since pre-boot is an irrelevance, once it happens.
I'm not tilting at windmills: I have no expectation that everyone's going to go back to BIOS. I'd just like the choice. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Mon Dec 29, 2014 12:27 am Post subject: |
|
|
| steveL wrote: | | steveL wrote: | | Personally I'd much rather buy a BIOS-based board for the freedom from the Wintel monopoly; and I think quite a few other people running Free systems would opt for it, given the choice, simply so that they didn't have to go through all these hoops, and worse have to get their bootloader ultimately-signed by M$. |
| khayyam wrote: | | steve ... you are repeating oft heard misrepresentations of UEFI. Firstly UEFI is a standard, its only relation to MS is that MS is part of the UEFI Forum ... but so is AMD, Intel, Apple, Redhat, and practically every other major hardware/software vendor. Secondly, UEFI isn't secureboot, that is an "extension" to UEFI, its not required and where provided can be disabled, so there is no requirement that the loader is signed by MS. |
Your first point is like claiming OoO.xml didn't get suborned by MS, and in effect lead to a binary standard allowing whatever the hell MS wants to stuff in there to lock people into Word. As well as seeming to appeal to a claim to authority, as if corporations hadn't clearly shown time and again, that they have zero interest in our welfare. |
steve ... my first point was a direct counter to your "freedom from the Wintel monopoly", of course MS, et al, are going to leverage whatever they can to suit their own agendas, but this is *also* true for bios (unless you think that bios manufacturers don't also bend to pressure from the big players). As I pointed out the UEFI Forum has practically all the various, and competing, hardware/software manufactures, even the big names in 'bios', so its not, as you suggest, a "monopoly" (at least a monopoly any different from that of 'bios'). Now, am I to argue, counter to your strawman, that no, its all about "freedom" or what-have-you ... that would be silly, and I shouldn't have to because that wasn't my point.
| steveL wrote: | | The second begs the question "then why not just a BIOS?" (apart from the point about GPT partitioning, which doesn't require UEFI by any means.) And misses the point that people are still being sold a lie of security, much like basically everything on Windows to do with security (which seems rather intended to keep everyone in a make-work job, slowing us all down, and more broadly to keep us under control rather than secure as most of us understand the term.) |
These terms, 'bios' and 'uefi', just refer to 'firmware', so unless there is something you think specifically wrong with UEFI (other than "all these hoops", or the misrepresentation of having to have the loader "signed by MS") then I don't see what you are arguing, in fact by your focusing on "security" you seem to be talking about something other than EFI (my firmware doesn't have secureboot, but yet, oddly enough, its EFI). IMO there are advantages to EFI, I think the separation of the firmware (which is not a pre-boot UI to set/enable/disable one or other feature but simply vars in NVRAM) and the loader is a good idea. If there is anything wrong with it its in the area of implementation (but as I said, this is mainly due to 'bios' manufactures making a bios-clone).
| steveL wrote: | | khayyam wrote: | | Now, whats so great about "bios"? It too is non-free, has numerous implementations (with all that entails), uses MBR (with its inherent issues/limitations), etc. UEFI is far better, when using EFI/GPT |
If GPT were not seen as somehow "requiring" UEFI then we wouldn't be having this discussion, imo. BIOS based can be done with another partitioning scheme, from what I've been told; it's only about the code accessing the drive, not the rest of the UI bloat. ISTR being told it doesn't matter at all if it's just going to look at the first part of the disk in any case. But I'm not claiming expertise here, and could well be mistaken as to the latter. But this is the nub of the point: if we had BIOS with GPT support for 64-bit kernels, as a choice in the vast panoply of consumer-choice we supposedly have, I reckon many would prefer that. |
My EFI firmware doesn't have a "UI" so you seem to be confusing EFI with something else, probably the implementations brought to you by 'bios' manufactures. That was my point, and so I'm not sure what discussion we are having, I merely countered your misrepresentations. [edit: I see now you were talking about bios UI ... but anyhow, sure, but the kind of firmware you seem to be describing ... ie, sans-UI, sans-bloat ... is exactly what the efi standard provides, so the argument against it seems weak ... other than both are often implimented badly].
| steveL wrote: | | [...] and as for "generic hardware" that seems another pretext to me. Either way it doesn't add anything, when it comes to getting a result; though it sounds like it could. It's just a deflection from all the other crap put in there. |
No, not really, by having a "generic" firmware all of the action, so to speak, can be shifted to the loader, this loader can be a shell (like efi-shell), or a bootmanager (like rEFInd) or a bootloader (like grub2, elilio, gumiboot, etc) or, as in the case of efi stub, the kernel itself. These, like other binaries, can be coded/compiled for the specific target, and that does "add" something because it means that your less tied to the firmware, one efi executable can be replaced with another. All that the firmware need do is know where this loader is on the filesystem, and run it.
| steveL wrote: | | Quote: | | All this leads where you'd expect, but I'm not sure we should blame the standard for this. |
It's perfectly possible for a standard to have some valid points in it, yet still be inescapably a creature of its sponsors. The best liars always weave truth into the cloth, and at some point you have to get things done. It's at that point, when we're actually discussing what needs to be done, that we tend to see the difference between what is necessary and what is political. |
Fair enough, but now you have to make this statement consistent with a "BIOS-based board for the freedom from the Wintel monopoly" otherwise this "creature" is that same "creature".
| steveL wrote: | | All the negatives you raise about BIOS development, seem to apply even more to UEFI implementations, and personally I believe the whole thing is a waste of time, more about turning users into consumers than anything else. I'd rather just use the simpler setup, with less code that has been through several cycles of iterative development, does what we need and no more; since pre-boot is an irrelevance, once it happens. |
The point I made about bios development was that its the same entities who are creating the uefi implementations.
| steveL wrote: | | I'm not tilting at windmills: I have no expectation that everyone's going to go back to BIOS. I'd just like the choice. |
Well, for the honourable Don Quixote those windmills are not windmills ... they are in fact giants :)
best ... khay |
|
| Back to top |
|
|
krinn
Watchman
Joined: 02 May 2003
Posts: 7470
|
| Posted: Mon Dec 29, 2014 9:48 am Post subject: |
|
|
never install one yet on EFI ; but the real poll should be "how easy/documented it is".
like i just said didn't yet done one with EFI, but i have no fucking clue how should it be done 
(the only clue i have so far is that's seems confusing, kernel seems to need nothing, but many tools exists i couldn't really get what are there for so) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Mon Dec 29, 2014 1:31 pm Post subject: |
|
|
| khayyam wrote: | | Firstly UEFI is a standard, its only relation to MS is that MS is part of the UEFI Forum ... but so is AMD, Intel, Apple, Redhat, and practically every other major hardware/software vendor. Secondly, UEFI isn't secureboot, that is an "extension" to UEFI, its not required and where provided can be disabled, so there is no requirement that the loader is signed by MS. |
| steveL wrote: | | Your first point is like claiming OoO.xml didn't get suborned by MS, and in effect lead to a binary standard allowing whatever the hell MS wants to stuff in there to lock people into Word. As well as seeming to appeal to a claim to authority, as if corporations hadn't clearly shown time and again, that they have zero interest in our welfare. |
| khayyam wrote: | | steve ... my first point was a direct counter to your "freedom from the Wintel monopoly", of course MS, et al, are going to leverage whatever they can to suit their own agendas, but this is *also* true for bios (unless you think that bios manufacturers don't also bend to pressure from the big players). |
No; this is why I brought in what needs to be done, and what doesn't. Point being that the BIOS did what we need, and there isn't any requirement for all the other stuff I've seen tacked on to the supposedly-critical, supposedly unique, selling-point of support for GPT disks.
Not that I'm not interested in projects like coreboot; I'm just saying that there would be a market for such boards, whichever software the assembler decided to flash. That's all.
| Quote: | | As I pointed out the UEFI Forum has practically all the various, and competing, hardware/software manufactures, even the big names in 'bios', so its not, as you suggest, a "monopoly" (at least a monopoly any different from that of 'bios'). |
Ah well that gets us on to the issue of de-facto cartel being the natural semi-stable state of crapitalism; in the semiconductor arena, like so many others, this is done via barriers-to-entry which always come down to who's more closely connected to the money-spigot. Though this may be off-topic. ;-)
| Quote: | | Now, am I to argue, counter to your strawman, that no, its all about "freedom" or what-have-you ... that would be silly, and I shouldn't have to because that wasn't my point. |
Your point appears to be that UEFI is an improvement on BIOS, overall. I disagree, but feel free to elucidate if I'm misunderstanding you.
| steveL wrote: | | The second begs the question "then why not just a BIOS?" (apart from the point about GPT partitioning, which doesn't require UEFI by any means.) |
| Quote: | | These terms, 'bios' and 'uefi', just refer to 'firmware', so unless there is something you think specifically wrong with UEFI (other than "all these hoops", or the misrepresentation of having to have the loader "signed by MS") then I don't see what you are arguing |
That there'd be a market for mobos using a traditional firmware, with guaranteed support for 64-bit filesystems.
| steveL wrote: | | And misses the point that people are still being sold a lie of security, much like basically everything on Windows to do with security (which seems rather intended to keep everyone in a make-work job, slowing us all down, and more broadly to keep us under control rather than secure as most of us understand the term.) |
| Quote: | | in fact by your focusing on "security" you seem to be talking about something other than EFI (my firmware doesn't have secureboot, but yet, oddly enough, its EFI). |
That's a broader point. And like it or not, "secure" boot is one of the selling points at an executive/end-user level. Further an OEM can't disable it on ARM platforms and still ship M$; in effect they're trying to lock a large part of the consumer-market out of true computing, only in terms of hardware rather than software. And succeeding. Which ofc leads to less freedom of choice prima facie, leave alone if you consider the GPL-3 at a more detailed level.
Specifically it embeds tivoization in the hardware platform, by abuse of dominant market-position, imo.
| Quote: | | IMO there are advantages to EFI, I think the separation of the firmware (which is not a pre-boot UI to set/enable/disable one or other feature but simply vars in NVRAM) and the loader is a good idea. |
I prefer the idea of having a simple UI that no-one really needs to change, so that device configuration is implicit in buying the device.
| Quote: | | If there is anything wrong with it its in the area of implementation (but as I said, this is mainly due to 'bios' manufactures making a bios-clone). |
Well from what I recall there's an awful lot of crap in the "standard", but if you like it fair enough. I don't really have the motivation to go back and reread it to refresh my memory, as I'm not really that bothered about it. I'll happily take your word for technical details.
| khayyam wrote: | | Now, whats so great about "bios"? It too is non-free, has numerous implementations (with all that entails), uses MBR (with its inherent issues/limitations), etc. UEFI is far better, when using EFI/GPT |
| steveL wrote: | | If GPT were not seen as somehow "requiring" UEFI then we wouldn't be having this discussion, imo. BIOS based can be done with another partitioning scheme, from what I've been told; it's only about the code accessing the drive, not the rest of the UI bloat. ISTR being told it doesn't matter at all if it's just going to look at the first part of the disk in any case. But I'm not claiming expertise here, and could well be mistaken as to the latter. But this is the nub of the point: if we had BIOS with GPT support for 64-bit kernels, as a choice in the vast panoply of consumer-choice we supposedly have, I reckon many would prefer that. |
| Quote: | | My EFI firmware doesn't have a "UI" so you seem to be confusing EFI with something else, probably the implementations brought to you by 'bios' manufactures. |
You're ignoring the main point I'm making here, but to answer you:
| Quote: | | I see now you were talking about bios UI ... but anyhow, sure, but the kind of firmware you seem to be describing ... ie, sans-UI, sans-bloat ... is exactly what the efi standard provides, so the argument against it seems weak ... other than both are often implimented badly. |
I never said sans-UI as above. The point is there were a few standard BIOS that practically every manufacturer had a recurring reimplementation license for; changing everything completely simply for GPT as opposed to MBR, was throwing away the baby with the bathwater.
Incremental improvements over "revolutionary innovation" avoids the second-system effect, on a larger scale (there's three systems before release, in our work.)
| Quote: | | By having a "generic" firmware all of the action, so to speak, can be shifted to the loader, this loader can be a shell (like efi-shell), or a bootmanager (like rEFInd) or a bootloader (like grub2, elilio, gumiboot, etc) or, as in the case of efi stub, the kernel itself. These, like other binaries, can be coded/compiled for the specific target, and that does "add" something because it means that your less tied to the firmware, one efi executable can be replaced with another. All that the firmware need do is know where this loader is on the filesystem, and run it. |
which is exactly the same as a traditional BIOS; only the former allows the installer to setup non-volatile vars, with just a bare board.
I call that a regression, in functional capability terms.
| steveL wrote: | | It's perfectly possible for a standard to have some valid points in it, yet still be inescapably a creature of its sponsors. The best liars always weave truth into the cloth, and at some point you have to get things done. It's at that point, when we're actually discussing what needs to be done, that we tend to see the difference between what is necessary and what is political. |
| Quote: | | Fair enough, but now you have to make this statement consistent with a "BIOS-based board for the freedom from the Wintel monopoly" otherwise this "creature" is that same "creature". |
Easy: the earlier standard was effectively prior-art that no-one could really claim much about, apart from copyright on a specific implementation. If we factor in what is necessary, in implementation terms it's a much better design, because it's as simple as it can be, while still fulfilling the brief. Useful functionality in the BIOS is a bit like useful functionality in sysvinit as pid1, afaic: you don't throw it away when you develop something newer in initspace, just as much as you don't add complexity.
Takes us back to the old Chesterton's Fence discussion we had, or at least my limited understanding of the point back then; you don't discard unless you know why those things were in place already, or you end up with lots of new, variant implementations doing the same job you pretend is irrelevant.
| Quote: | | The point I made about bios development was that its the same entities who are creating the uefi implementations. |
Well the point I'm getting at is that no-one cares about traditional BIOS in terms of commercial development, and like old software which just does its job and no more, it's perfect for community effort. So yeah I support coreboot, but these things have a tendency to follow the second-system law too; just look at grub2, for example (which should have extended the underlying config in a backwards-compatible manner, imo.)
The point remains: if we had a traditional firmware with GPT support for 64-bit kernels, as a choice in the vast panoply of consumer-choice we supposedly have, I for one, and I know a few others personally, would prefer that.
That's the only point I was making, really: expressing mild surprise that no enterprising mobo manufacturer uses some of that "worthless" BIOS code to appeal to the FLOSS market. |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9679
Location: almost Mile High in the USA
|
| Posted: Mon Dec 29, 2014 2:20 pm Post subject: |
|
|
| krinn wrote: | never install one yet on EFI ; but the real poll should be "how easy/documented it is".
like i just said didn't yet done one with EFI, but i have no fucking clue how should it be done :)
(the only clue i have so far is that's seems confusing, kernel seems to need nothing, but many tools exists i couldn't really get what are there for so) |
Technically it's very easy, EFI actually works the way you want - except when it comes to the "optional" secure boot (the firmware manufacturer decides if they want it or not, not you) and if you don't know the key and can't modify the keys, you're SOL.
The theory is all that you need to do is copy the EFI kernel into the system partition and have it run that file as a regular file (no more stage 1, no stage 1.5, no stage 2 boot loader stuff that we have to deal with in the past with lilo, grub, etc.).
My problem is that there is a lot of new hardware here and what could be blamed for one thing was actually something else. They say that x86 hardware is better at software maintenance, I think these new legacy free hardware are miserable... i2c peripherals are crap (what once was "fixed" with originally "plug and pray" that morphed into something actually usable is all gone).
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
bammbamm808
Guru
Joined: 08 Dec 2002
Posts: 548
Location: Hawaii
|
| Posted: Tue Dec 30, 2014 4:19 am Post subject: |
|
|
I've done this twice, and as it was a very unfamiliar paradigm, I did a lot of reading before trying it. I'm currently using rEFInd to boot efistub kernels. Once I got my head around the requirements for efi-sys partition and created the other gpt partitions my system would need, I had a bit of trouble getting a LiveCD that would boot into uefi mode. The first time I found that an Arch disk would do it.
| Progman3K wrote: | | what Gentoo media can you use to perform the installation? There is a step that requires the efivars to be available to the install process during the installation, but it does not appear that there exists any Gentoo install media that can boot in (U)EFI mode, so .... |
The newest HybridDVD boots into UEFI quite nicely. Opt out of X, choosing to stay in console mode, and in goes Gentoo!
_________________
MSI MAG B550 Tomahawk
Ryzen 3900x
32Gb Samsung B-die (16GB dual rank x2) DDR4 @ 3200MHz, cl14
Geforce RTX 2070S 8GB
Samsung m.2 NVME pcie-3.0
Etc.... |
|
| Back to top |
|
|
Progman3K
l33t
Joined: 03 Jan 2004
Posts: 773
|
| Posted: Wed Dec 31, 2014 2:36 pm Post subject: |
|
|
| bammbamm808 wrote: | I've done this twice, and as it was a very unfamiliar paradigm, I did a lot of reading before trying it. I'm currently using rEFInd to boot efistub kernels. Once I got my head around the requirements for efi-sys partition and created the other gpt partitions my system would need, I had a bit of trouble getting a LiveCD that would boot into uefi mode. The first time I found that an Arch disk would do it.
| Progman3K wrote: | | what Gentoo media can you use to perform the installation? There is a step that requires the efivars to be available to the install process during the installation, but it does not appear that there exists any Gentoo install media that can boot in (U)EFI mode, so .... |
The newest HybridDVD boots into UEFI quite nicely. Opt out of X, choosing to stay in console mode, and in goes Gentoo! |
I did finally manage to get it booted in EFI mode by replacing the kernel the Debian-install had left on the hard-disk and once that kernel booted, registering an EFI-enabled kernel worked.
I'm sure that these problems are normal as technologies evolve and won't be problems in a year or two. Things do get better.
Thanks for the info.
Off to look for the HybridDVD |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Dec 31, 2014 4:13 pm Post subject: |
|
|
Something happened a few days ago that made me realize that I don't know why my EFI system boots OK. It's working OK, I just don't understand it.
I installed using an EFI-capable SystemRescueCD. At the time I didn't understand the terminology the motherboard BIOS was using for EFI vs BIOS-compatible. I thought I had to use EFI boot, and didn't realize that the compatibility setting was not just for BIOS disks, as opposed to GPT disks, but for BIOS/MBR boot as well. I didn't need to do an EFI install, after all.
I was not able to do things to the EFI vars from SystemRescueCD, even after making sure it was booted in EFI mode. But somehow my motherboard found my newly-compiled EFI-capable kernel, and let me boot it. At that point I was able to do things with EFI vars. I installed rEFInd and had been mostly happy since. I've upgraded kernels several times, and only once had trouble booting once. So I thought everything was cool.
Then I got some memory for Christmas.
Aside from installing it and seeing the new number show up for "free", I wanted to test it. Adding the grub entry wasn't going to work any more, so I got a new copy of memtest86+ and put it on a flash stick, and have had both flash stick and optical drive ahead of the hard drive in boot order. So I plugged in the flash stick and rebooted, to run memtest86+.
I got to the normal "boot menu", which had several kernels, except now it had memtest86+ and an EFI shell as options. It looked just like the way I'd been booting, except it had the two extra entries.
I don't think I've ever been running rEFInd - I think I'm running something on my motherboard instead, and I'm not sure what. I think the EFI BIOS is searching everything it finds, looking for something bootable, and offering it as a choice. But I'm not sure, maybe SystemRescueCD also has rEFInd installed, it looks on my hard drive for bootable stuff, and looks just like the rEFInd on my hard drive.
I wish this stuff wasn't so complex and opaque. (I would prefer simple and transparent, and could probably take complex or opaque.)
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
|
|
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
|
|
Gentoo Chat
