[arch-general] Kernel updated to 3.14.5-1. Now my Lenovo IdeaPad hangs on boot...

Mike Cloaked mike.cloaked at gmail.com
Wed Jun 4 05:59:54 EDT 2014


On Wed, Jun 4, 2014 at 1:57 AM, Curtis Shimamoto <
sugar.and.scruffy at 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


More information about the arch-general mailing list