On Wed, Jun 4, 2014 at 1:57 AM, Curtis Shimamoto < sugar.and.scruffy@gmail.com> wrote:
On 06/03/14 at 03:51pm, Hong Shick Pak wrote:
I get these boot issues sporadically with kernel updates. I keep a separate boot entry in gummiboot with a kernel I know boots in case I get hit with it again.
I haven't found anything useful on this silly bug so I'd say this is your best option if you would like to avoid booting a liveCD every time it happens.
Rather than keep an old kernel around, I just keep grub-efi set up. Since the issue Mike Cloaked is referring to is the efistub bug, grub or syslinux (or elilo) continue to work just fine.
So I primarily use gummiboot, but in the gummiboot menu I have ne entry to get to grub. From grub I can boot the kernel normally. But I haven't been hit by this bug since about 3.9 I think...
If it is any help what I do is to have grub installed as well as my main boot manager, which is rEFInd, which is essentially the corresponding setup to that which Curtis reported for gummiboot in the previous post. I have a rEFInd config stanza that will chainload the grub bootloader to boot the kernel when the efistub fails to boot after any particular kernel update. Grub will always boot the same problematic kernel since it does not use the efistub. I had a thread which details how I chainload grub from rEFInd, when I had an issue setting it up, at https://bbs.archlinux.org/viewtopic.php?id=181906 and the corresponding technique can be employed for gummiboot as Curtis said in the previous post. I too have not had a problem booting kernels with the efistub recently, but it is certainly worthwhile setting up grub as an option so that you can still boot your system quickly in the event that the efistub kernel fails to boot. Then you can stay with the new kernel until the next kernel update so it is then no longer a worry. However it would be ideal if the underlying bug that causes occasional efistub kernels to fail to boot on particular hardware. Thus far nobody has been able to pin down any consistent factors that would allow diagnosing where in the boot code or firmware the problem lies. -- mike c