bug-grub
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Assortment of Issues with EFI on Mac


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Assortment of Issues with EFI on Mac
Date: Sat, 31 Dec 2011 15:48:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16

On 31.12.2011 09:36, Jake Thomas wrote:
Thank you Vladmir for the response : D ! I'm new to the Grub mailing lists, and 
these bugs have been on my mind for some while.

My experiences differ with a couple things you said. You said that you cannot depend on 
drive order. One of the few things that has worked 100% of the time with my adventures in 
Grub has been Grub calling the hard drive (by "hard drive" I include thumb 
drives) it is on the first hard drive. In all my experiences, regardless of machine and 
regardless of whether using EFI or BIOS, the hard drive with Grub on it is recognized by 
Grub as the first hard disk. That's the one thing I can count on.
Not true. While some implementations have this behaviour it's not specified or universal
  What if the UUID changes?
Then you need to update grub.cfg
  What if I have more than one thing with the same UUID?
Then you're just asking for trouble on several levels. Ranging from GRUB, going through initramfs, fstab and some FS drivers themselves (e.g. btrfs can't work in such conditions)
  In the bug I describe where Grub boots the internal instead of the thumb 
drive, Grub is disobeying my instruction from the grub.cfg file to boot (hd0, 
[whatever]). hd0 is my thumb drive. I have confirmed this with ls (list) at the 
Grub command line. Listing the contents of a partition in hd0 shows contents of 
my thumb drive, not the internal hard drive. Then it boots the internal instead 
anyways, even though I said to boot hd0, which I just confirmed is my thumb 
drive and not the internal.

how initramfs finds root is outside of GRUB's scope and I suppose that's where your problem is. I guess GRUB loaded kernel and initrd from stick but it mounted the internal root. Again duplicated UUIDs=trouble and isn't supported by anyone.
Ok, I messed up on technical terminology with the "carriage return." I meant whatever it is you get from 
pressing the "enter" key while in a text editor. That is, vertical space. If there is any vertical space 
after the last "}" from the last menu entry, grub doesn't load that config file. You would have to go back in 
and delete the vertical space at the bottom so that the "}" is the very last line. Not just the last visible 
line, the last line period. You can check by using the arrow keys to try and go down to the next line. If you get to a 
blank line, you need to delete that vertical space. If the cursor doesn't move, you're good.

Unable to reproduce. Check that you have latest version and that you use unix endline style, not dos/windows or mac one
Why shouldn't the normal mod be baked into the image? Isn't it vial for it to be baked 
into the image? How else is it going to come up with a background image and menu entries 
and not be in rescue mode? I want it to go to the menu automatically. I don't want to 
have to type "insmod normal". Especially if I am forging a multi-bootable thumb 
drive for someone who is not a Grub guru.

insmod normal is issued automatically. Use grub-install or grub-mkstandalone
With my grub.cfg file for 64-bit EFI, even when I didn't change anything in the 
file at all, behavior of Grub was not consistent across all boots, and all the 
while the drive mapping stayed the same; hd0 was always the thumb drive. So I 
know the bug is either in the EFI or in Grub. Not my grub.cfg. It usually 
works. And I am loading a unicode font file.

Upgrade to the latest version for starters
New Year's is getting close, maybe already is in some places around the world.

Not here. Cooking is still to be done. Will be unavailable for few days.
Cheers,
Jake

Sent from my iPhone

On Dec 30, 2011, at 8:54 AM, Vladimir 'φ-coder/phcoder' 
Serbinenko<address@hidden>  wrote:

On 30.12.2011 14:12, Jake Thomas wrote:
//Using version 1.99 of Grub
Hello everyone, I've been meaning to submit these bugs for quite a while now, 
at least since summer, but have been busy with school and hadn't taken the time 
to figure the Grub mailing list out, and was at a loss as to how to go about 
submitting bugs.

I have been playing with Grub2 on a thumb drive. I didn't know why it wasn't 
booting on the Mac, and, after some research, found out about EFI v.s. BIOS. 
After some more research and head-banging, I made some working grub efi images, 
put them on my thumb drive, and I could boot Linux off my thumb drive on a Mac, 
which uses EFI, not BIOS.

I encountered some issues.

One I call the "temptation error". If Linux is on the internal hard drive of my 
Macbook, and I get booted into Grub off my thumb drive via EFI, and I tell it to load 
Linux off the thumb drive, Grub finds the Linux on the internal hard drive too tempting 
and usually boots that instead. The kernel and initrd were the same name and path on both 
the internal hard drive and thumb drive, so it's not like it got possessed and started 
looking around for Linuxes to boot.

When you are on a Macbook with Linux on the internal hard drive with a kernel 
and initrd of the same name and path as the kernel and initrd on a thumb drive 
with a bootable grub EFI image, and you boot into EFI Grub off the thumb drive, 
it seems to, on average, actually succeed in booting off the thumb drive rather 
than the internal about 1 in every 14 times. It's more like it randomly picks a 
number between 12 and 17 or so, and that's how many more attempts it will take 
to get to the next successful attempt to boot off the thumb drive rather than 
the internal.

It's usually a symptom of duplicate UUID or wrong grub.cfg. You can't rely on 
drive order. You need to use search -s root -u UUID

Another one is an often patternistic blackout bug. I can boot my MacBook off my 
thumb drive into EFI Grub, select to boot Linux off my thumb drive, and boot 
Linux no problem (unless Linux exists on the internal). Then the next time I 
try, it might black the screen out. In fact, pressing enter or escape or any 
key doesn't do anything, so it actually is crashed-out, rather than the screen 
simply having gone black.
But here's the interesting part: If I save a copy of grub.cfg to my desktop (the one in 
the EFI grub prefix) and then delete it off my thumb drive, and then boot my MacBook off 
my thumb drive, I successfully get to a command line and can boot Linux "by 
hand." Then I can put the grub.cfg back on, and it will work next time. Sometimes it 
follows a simple AB pattern of blacking out, me deleting grub.cfg, getting to a command 
line, me putting grub.cfg back on, Grub booting correctly with a menu and background 
image and all, and then the cycle repeats. Though recently I haven't experienced a strict 
cycle; it's more of a certain probability of blacking out, to which the fix is to delete 
grub.cfg, boot without it, then put it back on.

It's possible that it's another symptom of last problem

And here's a couple of minor bugs (but they still ought to be fixed):

Grub doesn't load a grub.cfg file if it has extra carriage returns at the end. To someone 
who doesn't know this and is making a grub.cfg file by hand for, say, a thumb drive, this 
can cause a lot of frustration; it sure caused me a lot of frustration! Grub only loads a 
grub.cfg file if the last character is a part of the Grub script, usually a "}".

grub.cfg has to be in unix-style newline that is \n=LF. There should be no 
CR=carriage return at all.
When I boot my thumb drive via EFI on my MacBook, it erroneously, for a brief moment, 
says "error: prefix not set" and then continues loading Grub to a menu with a 
background and everything (unless it blacks out). The prefix is indeed set and can be 
confirmed by command line.
normal mod shouldn't be baked into image. Use grub-install
Also, I have experienced issues with iMacs, but don't have enough definite 
testing to really report anything. It wasn't loading the background, had funny 
characters around the menu like it does when the font file isn't present, and 
it was in portrait rather than in landscape, and if I remember right, didn't 
even boot Linux.

if you use gfxterm you need to load unifont. If you don't GRUB can't load 
background image
I'm a big fan of Grub. I felt like I found heaven on Earth when I started 
understanding it and using it, because I was using syslinux before that (for 
thumb drives). Boy! Support for either EFI or BIOS, the ability to have a 
pretty background image, font of your choice, so many modules for 
anything...it's got so many great things to it! And if these kinks could be 
worked out, it'd be even better. If we really do switch to EFI, they better get 
fixed.
That's good to hear. You can drop by in IRC and hopefully we can figure what's 
wrong with your system and whether any of it is a bug as opposed to wrong 
manual config
Cheers,
Jake


_______________________________________________
Bug-grub mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/bug-grub

--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko



--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko




reply via email to

[Prev in Thread] Current Thread [Next in Thread]