Cannot load latest kernels

[Qqmike]

I'm still booting via rEFInd but it points to Grub2

Yep, me too :-) In doing the how-to's and all my experimenting, I now have 12 partitions which include 3 ESPs. My rEFInd menu has many entries, I think 27 or something like that.

There's a simpler method of making sure rEFInd is at the top of the EFI boot order ... there's a little utility that comes with rEFInd called refind-mkdefault. Just execute sudo refind-mkdefault in a terminal.

Thanks for that tip, I've never used it. Just checked, and I don't have refind-mkedefault installed; I must have missed that along the way.

[Rod J]

Until it gets fixed, people can always use their GRUB. Simply boot into Kubuntu (somehow), and issue the command
sudo grub-install
and that will place GRUB at the top of your UEFI boot list (check it using sudo efibootmgr). I'm sure you know this Rod J, just posting it for others who may bounce here.
After the kernel thing gets fixed, you can boot into Kubuntu and use sudo efibootmgr -o to change the BootOrder and put rEFInd back to the top of the boot list. See man efibootmgr -- scroll down to very end where they illustrate the -o switch.

I'm still booting via rEFInd but it points to Grub2 (which I still have installed as a backup booting method) instead of booting the kernel directly. rEFInd works fine that way

There's a simpler method of making sure rEFInd is at the top of the EFI boot order ... there's a little utility that comes with rEFInd called refind-mkdefault. Just execute sudo refind-mkdefault in a terminal.

[Qqmike]

Until it gets fixed, people can always use their GRUB. Simply boot into Kubuntu (somehow), and issue the command
sudo grub-install
and that will place GRUB at the top of your UEFI boot list (check it using sudo efibootmgr). I'm sure you know this Rod J, just posting it for others who may bounce here.
After the kernel thing gets fixed, you can boot into Kubuntu and use sudo efibootmgr -o to change the BootOrder and put rEFInd back to the top of the boot list. See man efibootmgr -- scroll down to very end where they illustrate the -o switch.

[Rod J]

I do NOT have the problem with vmlinuz-3.13.0-100-generic.
I do, however, have the problem with the following three kernels:
vmlinuz-3.13.0-101-generic
vmlinuz-3.13.0-103-generic
vmlinuz-3.13.0-105-generic

Ditto here

[Qqmike]

Just to be clear (as I got myself confused for awhile), let me make this comment:

I do NOT have the problem with vmlinuz-3.13.0-100-generic.
I do, however, have the problem with the following three kernels:
vmlinuz-3.13.0-101-generic
vmlinuz-3.13.0-103-generic
vmlinuz-3.13.0-105-generic

https://bugs.launchpad.net/ubuntu/+s...326/comments/4

[Qqmike]

OK, Rod Smith has determined that this is a bug with the kernel's EFI stub loader, not with rEFind, nor with a filesystem.

He has given me permission to post his detailed comments here. Please try to take time and add your name to the bug list at the link Rod Smith gives in his email, here, from Rod Smith (my emphasis added):

I've finally had a chance to dig into this a bit more. I've reproduced
the bug in VirtualBox with a 3.13.0-104 kernel, and I've verified that
it's a problem with the EFI stub loader, not with rEFInd or its
filesystem drivers. I've filed a bug report about it; see here:

https://bugs.launchpad.net/ubuntu/+s...x/+bug/1649326

I recommend that those encountering problems click the link to indicate
that the bug affects them. (A Launchpad account may be necessary to do
so.) If you believe you have additional important details, please feel
free to add them; but avoid "me too" type responses.

Until this bug is fixed, I can think of several possible workarounds:

* Keep using a 3.13.0-100 or earlier kernel. Of course, this may
be inadvisable if subsequent kernels include important security
updates. (I've not checked this detail.)
* Upgrade to a 4.4.0-series kernel. You can find instructions
on doing this various places on the Web, like here:
http://askubuntu.com/questions/75336...ubuntu-14-04-4
Note that I've not directly tested this, but I've had no
problems with Xenial, so I expect this would work.
* Use GRUB, ELILO, or some other boot loader as an intermediary
or as a replacement for rEFInd.
* Compile your own kernel locally using upstream (non-Ubuntu) sources.
This is a major undertaking for most users, though.

IMHO, the best of these options is probably to upgrade to a 4.4.0-series
(Xenial) kernel, unless you have a compelling reason to stick with
3.13.0, in which case I'd advise using another boot loader in addition
to or instead of rEFInd.

Feel free to share this information on the kubuntuforums thread.

--
Rod Smith
rodsmith@rodsbooks.com
http://www.rodsbooks.com

[Qqmike]

Kernel info?

Rod J It's looking more like it's kernel related now I guess.

If so, in plain English, what's the difference between kernel vmlinuz-3.13.0-100-generic and vmlinuz-3.13.0-103-generic? Never got into researching kernel details. Need to try searching this. What changed? Something to do with ext4? or the a change in the kernel as involved with the stub loader?

[Qqmike]

Thanks Rod J. I updated Rod Smith tonight on this little experiment I did, he has this link, so he will see your post, too. I think he'll be interested in all this.

It sure pays to keep a couple or three kernels on hand, doesn't it!

[Rod J]

Thanks for the update Mike

It's looking more like it's kernel related now I guess.

I don't know if it's any help, but the previous problem I had with rEFInd not booting a kernel was a little different. It was a different error message that time. I found the bit of paper I wrote down the info on a while back (the kernel was 3.13.0-92-generic). This is what rEFInd said at that time (bold emphasises different error message):

"Starting vmlinuz-3.13.0-92-generic.efi.signed
Using Load options 'ro root=UUID=#### quiet splash initrd=boot\initrd.img-3.13.0-92-generic'
Failed to get file info size
Failed to alloc highmem for files"

Again, at that time Grub2 booted the kernel no problem. The next kernel update (3.13.0-93 I think) seemed to fix the problem and rEFInd booted that kernel no problem.

[Qqmike]

For anyone following this and wishing for more details, I just wrote up a short how-to, posted it here:

Boot Kubuntu Using UEFI Only

https://www.kubuntuforums.net/showth...271#post396271

[Qqmike]

OK, so in summary, so far:

Using only my UEFI firmware (ASUS H97-PLUS), I can boot (by stub loader) the -100 kernel (that's the kernel rEFInd can boot by stub loader without problems).

However, my UEFI firmware does not boot the -103 and -105 kernels (rEFInd also fails on these two kernels).

What can we conclude?
Maybe the -103 and -105 need other kernel boot options?
Or, as I posted above, from Rod Smith, it is to do with the ext4 filesystem driver?
Or, what?

You can see what happened in my test:

Register the -105 kernel:

sudo efibootmgr -c -d /dev/sda -p 1 -l '\EFI\StubL\vmlinuz-3.13.0-105-gen.efi' -L 'vmlinuz3130-105' -u 'ro root=/dev/sda2  [FONT=Liberation Serif]quiet spl[/FONT][FONT=Liberation Serif]ash[/FONT] [FONT=Liberation Serif]initrd=[/FONT][FONT=Liberation Serif]\[/FONT][FONT=Liberation Serif]EFI[/FONT][FONT=Liberation Serif]\[/FONT][FONT=Liberation Serif]StubL\[/FONT][FONT=Liberation Serif]initrd.i[/FONT][FONT=Liberation Serif]mg[/FONT][FONT=Liberation Serif]-3.13.0-10[/FONT][FONT=Liberation Serif]5[/FONT][FONT=Liberation Serif]-g[/FONT][FONT=Liberation Serif]eneric[/FONT]'

After registering kernel -105:

BootOrder: [B]0006,000E,0000[/B],0003,0007,0001,000A,0005,0002,0004,000B,000C

 Boot[B]0000[/B]* vmlinuz3130[B]-100[/B]
 Boot0001* debian
 Boot0002* grub_sda5K1504
 Boot0003* rEFInd Boot Manager
 Boot0004* Mint_2
 Boot0005* Hard Drive 
 Boot0007* TestMint_sda8
 Boot000A* Mint_1
 Boot000B* ubuntu
 Boot000C* ubuntu
 Boot000D* Unknown Device
 Boot[B]000E[/B]* vmlinuz3130[B]-103[/B]
 Boot[B]0006[/B]* vmlinuz3130[B]-105[/B]
 

 mike@mike-desktop:~$ inxi -Fxxx
 System:    Host: mike-desktop [B]Kernel: 3.13.0-100-generic[/B] x86_64 (64 bit, gcc: 4.8.4)  
 Desktop: KDE 4.13.3 (Qt 4.8.6) info: plasma-desktop dm: lightdm Distro: Ubuntu 14.04 trusty

The firmware tried -105 and failed to boot, then tried -103 and failed, and then tried -100 and it booted OK.

(Aside: Oh-oh, my firmware is taking a longer time to re-boot, and shows the POST screen quite a long time. Too much experimenting?! Last time this happened, I had to reset my UEFI firmware (using the motherboard jumpers), then re-establish the booting.)

[Qqmike]

(had time to try ...)

OK, it looks like my firmware can NOT boot kernel -103 directly, although it can boot -100 directly. Didn't test -105 yet, but guessing it won't boot either (will check asap). I'll double check my work. (EDIT: Not true: But if this is correct, then maybe rEFInd has some catch in it. ) I'm using standard boot options as the statement in my post #21 above indicates. Btw, my firmware gave me no diagnostics: it simply returns to the boot screen quietly; if I just let the computer boot without intervening, it simply fails on the -103 kernel and goes to the next BOOT NVRAM variable (which is -100) and boots OK. Checked this using inxi -Fxxx, also, btw.

[Qqmike]

re my Post #17 ...

OK, I'm getting somewhere (as far as trying to diagnose this problem). I got the -100 kernel to boot using only my UEFI firmware (booting the kernel directly, by stub loader), using this corrected command:

sudo efibootmgr -c -d /dev/sda -p 1 -l '\EFI\StubL\vmlinuz-3.13.0-100-gen.efi' -L 'vmlinuz3130-100' -u 'ro root=UUID=127fc14b-aa8a-4c00-b781-0a70a88cf07c  [FONT=Liberation Serif]quiet spl[/FONT][FONT=Liberation Serif]ash[/FONT] [FONT=Liberation Serif]initrd=[/FONT][FONT=Liberation Serif]\[/FONT][FONT=Liberation Serif]EFI[/FONT][FONT=Liberation Serif]\[/FONT][FONT=Liberation Serif]StubL\[/FONT][FONT=Liberation Serif]initrd.i[/FONT][FONT=Liberation Serif]mg[/FONT][FONT=Liberation Serif]-3.13.0-100-g[/FONT][FONT=Liberation Serif]eneric[/FONT]'

I fixed the proper format for the initrd path (single backslash within single quote). (The UUID is not important, I think root=/dev/sda2 will work as well.)

Now, as time permits, I need to see if my UEFI firmware will boot the -103 and -105 kernels directly. If they boot, that would tell me that maybe rEFInd has a catch in it. Being pulled away here, again, to go food shopping now ...

[Qqmike]

If it is not broken don't fix it! In fact, until the kernel problem is solved I'd lock your working kernel so that it doesn't get updated.

Yeah. Or, you might be forced to use GRUB! ;-)

[GreyGeek]

A lot of this is beyond my knowledge/expertise level but I can probably pick it up if I do some reading. I just got the update notice for the 105 kernel a little while ago. I'm debating whether to install it at this time or wait until I can make sense out of the info you guys have given me (which I thank you for, by the way!).

If it is not broken don't fix it! In fact, until the kernel problem is solved I'd lock your working kernel so that it doesn't get updated.