On Jun 28, 2012, at 8:52 PM, Matthew Garrett wrote:
> On Thu, Jun 28, 2012 at 05:55:09PM -0600, Chris Murphy wrote:
>
>> The behavior I care about, is results. Swap hard drives, even dual
>> boot, between two Apple computers, and they still boot. Lenovo example
>> in this thread, does not boot
On Thu, Jun 28, 2012 at 05:55:09PM -0600, Chris Murphy wrote:
> The behavior I care about, is results. Swap hard drives, even dual
> boot, between two Apple computers, and they still boot. Lenovo example
> in this thread, does not boot in the same case. These are not
> identical behaviors.
Yes
On Thu, 2012-06-28 at 17:55 -0600, Chris Murphy wrote:
> How about we save the firmware puke in the face for when there's
> meaningful ambiguity involved?
Who is the 'we' here? Any conceivable 'we' which might be held to exist
in the context of the Fedora development list does not, to me, seem to
On Jun 28, 2012, at 3:25 PM, Matthew Garrett wrote:
>> An optional file in an optional vendor subdirectory is the obvious
>> choice? Maybe a future spec could be more clear that the subdirectory
>> and an EFI image in it are required, who should provide it, and that
>> it should be used first i
On Jun 28, 2012, at 3:13 PM, Peter Jones wrote:
> There's no way to know if a UEFI application is a boot loader. You're as
> likely to accidentally run a firmware raid setup utility or the debug programs
> we put there with gnu-efi.
Well that seems rather limiting, and problematic.
>> I admit t
On Jun 28, 2012, at 2:51 PM, Matthew Garrett wrote:
> On Thu, Jun 28, 2012 at 02:22:48PM -0600, Chris Murphy wrote:
>
>> I'm not bitching about the spec, I'm bitching about the firmware in
>> the context of the OP's described experience. The intent of 3.3 is to
>> avoid failure. It predates 3.
On Thu, Jun 28, 2012 at 03:03:55PM -0600, Chris Murphy wrote:
> On Jun 28, 2012, at 1:59 PM, Matthew Garrett wrote:
>
> > The only obvious thing for it to boot is EFI/BOOT/BOOT${ARCH}.efi.
> An optional file in an optional vendor subdirectory is the obvious
> choice? Maybe a future spec could b
On 06/28/2012 05:03 PM, Chris Murphy wrote:
They have a vendor defined order, which 3.3 allows, even though Apple EFI is
not UEFI. When PRAM is zapped, the NVRAM is empty and nothing is blessed,
therefore the sequence I described earlier applies.
This is actually wrong as well. Blessing is a p
On 06/28/2012 05:03 PM, Chris Murphy wrote:
On Jun 28, 2012, at 1:59 PM, Matthew Garrett wrote:
The only obvious thing for it to boot is EFI/BOOT/BOOT${ARCH}.efi.
An optional file in an optional vendor subdirectory is the obvious choice?
Maybe a future spec could be more clear that the subd
On Jun 28, 2012, at 1:59 PM, Matthew Garrett wrote:
> The only obvious thing for it to boot is EFI/BOOT/BOOT${ARCH}.efi.
An optional file in an optional vendor subdirectory is the obvious choice?
Maybe a future spec could be more clear that the subdirectory and an EFI image
in it are required
On Thu, Jun 28, 2012 at 02:22:48PM -0600, Chris Murphy wrote:
> I'm not bitching about the spec, I'm bitching about the firmware in
> the context of the OP's described experience. The intent of 3.3 is to
> avoid failure. It predates 3.4.1.2. The user is experiencing boot
> failure. I don't see
On Jun 28, 2012, at 2:01 PM, Peter Jones wrote:
>>
>> The intent of 3.3 plus 12.3.1.3 is rather clear that the idea is to result
>> in the booting of an operating system or maintenance utility. The previously
>> bootable disk is not malformed, the computer simply lacks the proper efi
>> boot vari
On 06/28/2012 03:54 PM, Chris Murphy wrote:
2.
It doesn't at all indicate who should do this. If anything 12.3.1.3 implies
it's vendor domain. Not operating system domain.
It's completely obvious that if we want something to happen, we have to do it.
Given there's no mandate that this subdire
On Thu, Jun 28, 2012 at 01:54:13PM -0600, Chris Murphy wrote:
> It's wholly irrational for a user to move a disk from one computer to
> another and to get either puke in the face (the OP's experience) or
> even a vendor provided maintenance utility, rather than booting the
> singular obvious op
On Jun 28, 2012, at 12:29 PM, Peter Jones wrote:
>> In all of my testing, an empty NVRAM will always locate Apple's bootloader
>> and use it first. If not present, then it goes to EFI//EFI/BOOT/BOOTx64.EFI.
>> If not present, then it executes the first 440 bytes of the MBR (if a
>> partition other
On Thu, Jun 28, 2012 at 12:04:41PM -0600, Chris Murphy wrote:
> I don't know what UEFI version Lenovo purports to conform to, but the
> lack of an EFI//EFI/BOOT/BOOTx64.EFI image isn't an excuse for it
> failing to boot a previously bootable disk that is in no way
> malformed. This seems to be
On 06/28/2012 02:04 PM, Chris Murphy wrote:
On Jun 28, 2012, at 10:26 AM, Peter Jones wrote:
On 06/28/2012 12:17 PM, Chris Murphy wrote:
It is perturbing that in 2012, with a nearly 30MB operating system as a
pre-boot environment, that by design it doesn't scan the EFI System
partition for o
On Jun 28, 2012, at 12:04 PM, Chris Murphy wrote:
> Lacking a UI entirely, I think these are rather good fallbacks considering
> the target market. [1]
[1] The possible exception is the UI-less, optionless, no way to prevent, the
activation of CSM-BIOS booting in the case there's MBR boot code
On Jun 28, 2012, at 10:26 AM, Peter Jones wrote:
> On 06/28/2012 12:17 PM, Chris Murphy wrote:
>
>> It is perturbing that in 2012, with a nearly 30MB operating system as a
>> pre-boot environment, that by design it doesn't scan the EFI System
>> partition for other possible boot options - like a
On Jun 28, 2012, at 8:08 AM, Kamil Paral wrote:
>
> Do we have a Fedora page documenting boot problems somewhere (re-installing
> GRUB and stuff)? It would be useful to add a short help in there about UEFI
> too. GRUB guides are all over the Internet, but UEFI is a new stuff and I
> wasn't abl
On 06/28/2012 12:17 PM, Chris Murphy wrote:
It is perturbing that in 2012, with a nearly 30MB operating system as a
pre-boot environment, that by design it doesn't scan the EFI System
partition for other possible boot options - like a rescue mode - in the event
efi boot variables aren't set.
W
On Jun 28, 2012, at 7:29 AM, Peter Jones wrote:
> Having sent that mail it became obvious that what's happened is that your
> new x220 board doesn't have the efi boot variable set. Some machines allow
> you to boot from a file, in which case it'll be /efi/fedora/grubx64.efi .
> If your firmware d
On Thu, Jun 28, 2012 at 03:40:17PM +0200, Lennart Poettering wrote:
> Hmm, so if grub would also install itself into /efi/boot/bootx64.efi
> then this problem would just go away as that is the default file that
> the EFI bios will execute. This would enable disk images that just boot
> without any
On 06/28/2012 10:08 AM, Kamil Paral wrote:
Having sent that mail it became obvious that what's happened is that
your
new x220 board doesn't have the efi boot variable set. Some machines
allow
you to boot from a file, in which case it'll be
/efi/fedora/grubx64.efi .
If your firmware doesn't have
> Having sent that mail it became obvious that what's happened is that
> your
> new x220 board doesn't have the efi boot variable set. Some machines
> allow
> you to boot from a file, in which case it'll be
> /efi/fedora/grubx64.efi .
> If your firmware doesn't have that, you'll need to boot some
On 06/28/2012 09:40 AM, Lennart Poettering wrote:
On Thu, 28.06.12 09:29, Peter Jones (pjo...@redhat.com) wrote:
Having sent that mail it became obvious that what's happened is that your
new x220 board doesn't have the efi boot variable set. Some machines allow
you to boot from a file, in whic
On Thu, 28.06.12 09:29, Peter Jones (pjo...@redhat.com) wrote:
> Having sent that mail it became obvious that what's happened is that your
> new x220 board doesn't have the efi boot variable set. Some machines allow
> you to boot from a file, in which case it'll be /efi/fedora/grubx64.efi .
> If
On 06/28/2012 09:25 AM, Peter Jones wrote:
On 06/28/2012 09:11 AM, Kamil Paral wrote:
If you are knowledgeable about UEFI, I'll welcome your advice. This is the
issue I encountered:
1. I enabled UEFI mode in BIOS in Lenovo X220 (more exactly I set UEFI as the
preferred method).
2. I installed F
On 06/28/2012 09:11 AM, Kamil Paral wrote:
If you are knowledgeable about UEFI, I'll welcome your advice. This is the
issue I encountered:
1. I enabled UEFI mode in BIOS in Lenovo X220 (more exactly I set UEFI as the
preferred method).
2. I installed Fedora 17.
3. "Fedora" item appeared in BIO
If you are knowledgeable about UEFI, I'll welcome your advice. This is the
issue I encountered:
1. I enabled UEFI mode in BIOS in Lenovo X220 (more exactly I set UEFI as the
preferred method).
2. I installed Fedora 17.
3. "Fedora" item appeared in BIOS in "Boot order" and also in the boot manage
30 matches
Mail list logo
