Cannot load latest kernels

[GKNByNW]

I run a dual-boot desktop with rEfInd as my bootloader. As the title suggests, the last 2 kernel updates (3.13.0-101 & 3.13.0-103) cause rEFInd to display the following at boot:



Thankfully, 3.13.0-100 is still installed and I can select it from the submenu in rEFInd, but that of course doesn't eliminate the issue. Does anyone know what may have caused this error, and how to prevent or eliminate it with future kernel updates?

[Qqmike]

EDIT: See my post following #4

[deleted because I didn't read the OP question carefully]

[Qqmike]

EDIT: See my post following #4

[deleted because I didn't read the OP question carefully]

[Qqmike]

EDIT: See my post below.

[deleted because I didn't read the OP question carefully]

[Qqmike]

Geez, too early this morning ...

OK, you are using 14.04, I see that now, and carefully read your OP. I'm also on 14.04, I have 100, 101, and 103, just like you. And I have the same problem with rEFInd as you report. Sorry for the mix-up here.

My rEFInd boots to GRUB2 (that's the way I set it up), so I wasn't seeing what you see so directly. But if I let rEFInd boot, and then select either 103 or 101 to boot directly (by stub loader, not by GRUB), I am getting the same Error message you get. But 100 boots from rEFInd ok.

I looked at the kernel options in my GRUB, and they are all the same for 100, or 101, and for 103:

linux statement has these: ro quiet splash $vt_handoff (not sure what that last one is)
initrd statement is standard, no options.

Strange, what am I not seeing here? Is this bug? We'll have to poke around some more. I'm being pulled away here on some other things, but will try to return.

[Qqmike]

It won't go using single user mode or using "with minimal options" mode in rEFInd: I get that same error message that you posted. (I.e., in rEFInd, highlight the 103 kernel, press F2 for more options, and there you see "single user" and "minimal options.") I googled for awhile -- nothing turned up. May have to ask Rod Smith, not sure yet about this. Anybody else see or know anything that is different about the 101 and 103 kernels from the 100 kernel that would affect booting? (vmlinuz-3.13.0-103-generic-efi.signed, in 14.04)

[Qqmike]

GKNByNW, I just sent Rod Smith (rEFInd author/maintainer) an email, just as an fyi so he can be aware of this issue as you and I try to dig deeper. I hope we are not over-looking something obvious here. Re-reading some of Rod's material on rEFInd, there are settings to be tweaked in the /boot/efi/EFI/refind/refind.conf (involving scans, drivers, and such). I'm just a little hesitant to undertake a systematic experiment with that this morning, having too many distractions here. Besides, rEFInd does boot kernel -100 by stub loader, just fine, right? in a standard fashion; and you and I both have standard installations of Kubuntu 14.04--rEFInd, GRUB, the filesystem, the whole show, right?

I do plan to keep thinking on this as I find the time.

[Rod J]

I have exactly the same problem here (K14.04). I always boot via rEFInd directly and bypass Grub2. I had a similar problem with an earlier kernel (maybe 3.13.96 I think) and just let Grub2 do the booting for a while until it was fixed with the next upgrade.

More recently when I upgraded to 3.13.101 rEFInd failed to boot again with exactly the same error message as the OP got. This time I decided to remove the 3.13.101 kernel and revert to 3.13.100 which boots fine via rEFInd. Now I seem to be stuck on the 100 kernel and 103 didn't install correctly or something is messed up somewhere. I haven't bothered about it so far but I'm surprised the 103 kernel is still not booting via rEFInd for the OP and I guess others. I did google about the issue myself and found nothing, so maybe it is a new bug.

[Qqmike]

Thanks for the input Rod J. So just to be clear for anyone else looking in, we have, recently:

vmlinuz-3.13.0-103-generic-efi.signed, in 14.04
vmlinuz-3.13.0-101-generic-efi.signed, in 14.04
vmlinuz-3.13.0-100-generic-efi.signed, in 14.04

And you can boot 100?
but not 101 or 103?
Is that right?

Thanks.

[Rod J]

I made a mistake in my earlier post: "More recently when I upgraded to 3.13.100 rEFInd failed to boot" ... I meant the 3.13.101 kernel.

[Qqmike]

I made a mistake in my earlier post: "More recently when I upgraded to 3.13.100 rEFInd failed to boot" ... I meant the 3.13.101 kernel.

Yes, thought so! Thanks!

[Qqmike]

My thoughts I sent to Rod Smith this morning were,

... it would seem that the issue concerns directly the stub loader code in the two newer kernels, 103 and 101. rEFInd seems to be working fine (with -100). Unless this concerns some subtle, nonstandard thing with EFI drivers or some-such. Strangely, searching with Google thus far this morning, I can find no one yet mentioning this as a problem with rEFInd.

I need to re-read more carefully Rod Smith's page on the stub loader to appreciate what could be doing this. I don't know enough about this at such a technical level, but perhaps there's a setting one could change in rEFInd's configuration file that might get this going: /boot/efi/EFI/refind/refind.conf. Tomorrow looks like a busy day, starting at 7 am for me (medical stuff for the spousal unit here), Tuesday may be out of town on business, but maybe I can look at this again soon this week.

[GKNByNW]

Thanks for the input Rod J. So just to be clear for anyone else looking in, we have, recently:

vmlinuz-3.13.0-103-generic-efi.signed, in 14.04
vmlinuz-3.13.0-101-generic-efi.signed, in 14.04
vmlinuz-3.13.0-100-generic-efi.signed, in 14.04

And you can boot 100?
but not 101 or 103?
Is that right?

Thanks.

That is correct. My initial thought when 101 errored out was that something went wrong during the installation. But after installing 103 and having the same issue I wasn't so sure, especially seeing as how others are having this same problem.

I have exactly the same problem here (K14.04). I always boot via rEFInd directly and bypass Grub2. I had a similar problem with an earlier kernel (maybe 3.13.96 I think) and just let Grub2 do the booting for a while until it was fixed with the next upgrade.

I suppose I should have mentioned in the OP that I do not have GRUB installed at all. I rely solely on rEFInd for my boot management as it has never given me an issue until now.

On another note - and most likely unrelated - rEFInd updated a couple months back, the update failed, and I ended up with an unbootable Linux system. Win7 still booted because of the boot code being on the EFI partition. I ultimately had to use the rEFInd boot disc to load up Kubuntu and from there remove and the reinstall rEFInd.

~~

One additional thought... Is it possible that the current issue is not due to a bug in rEFInd but rather something that was changed in the kernel itself with the release of 101?

[Qqmike]

One additional thought... Is it possible that the current issue is not due to a bug in rEFInd but rather something that was changed in the kernel itself with the release of 101?

I think so, as I expressed in Post #12--my email to Rod Smith.

[Rod J]

Well, we can add 3.13.0-105-generic to the list of kernels that rEFInd can't boot via the stub loader.

I just updated to the 105 kernel (after fixing my problem with the kernels not updating) ... I had inadvertently removed the linux-generic meta package when I removed the 3.13.0-101 kernel recently, so the linux kernel headers were updating but not the actual kernel!

The rEFInd error message is the same as before: Error: Load Error while loading vmlinuz-3.13.0-105-generic.efi.signed.

Boots fine via Grub2, thankfully.

I too wonder if there has been some change in the way the kernel is being compiled or if the problem is with rEFInd? I've been reading through some of Rod Smith's documentation but it's a bit over my head. I also wonder if there are any similar problems with the other kernel lines (3.19, 4.2, 4.4, etc. Is it just limited to K14.04)?