Cannot load latest kernels

[Qqmike]

Rod Smith gave me the go-ahead to post his email comments here. I'll post it for now, in case anyone has some time to dig into this:

Thanks for the bug report. Unfortunately, this week I'm very busy with
other matters, but I'll try to look into it late this weekend or next
week. In the meantime, I have a few suggestions of things to try:

1) If you haven't done so recently, upgrade to the latest rEFInd, and
especially to the latest filesystem driver for whatever filesystem
holds the kernel. There have been some recent changes to the ext4fs
driver, in particular, that might fix some problems.
2) If you are already running rEFInd 0.10.4, and in particular its
ext4fs driver, try dropping back to the 0.10.3 ext4fs driver. It's
conceivable that the recent ext4fs changes are actually causing
problems on some systems.
3) As a diagnostic measure, try launching the kernel in some other
way -- by using an EFI shell (you may need to rename it to give
it a .efi extension), by using systemd-boot, or by entering it
directly in the EFI's boot manager by using efitootmgr. If the
problem persists with these boot methods, then it's almost
certainly a bug in the latest kernel builds, and a bug should
be filed against them. If these alternative methods can boot
the system, then the bug is likely with rEFInd.
4) If Secure Boot is enabled, disable it as a diagnostic measure.

Late last night, I worked on 3) (i.e., this easy part: "entering it directly in the EFI's boot manager by using efitootmgr."), but have not yet had any luck getting things to go. Some of this depends on your computer's EFI firmware. I'm also not real adept at doing some of this stuff, more "under the hood," but maybe it's a chance to learn! I'll try to find time to dig deeper, but this week has turned out to be a pile of Post-It to-do's.

Thanks for helping to figure this out and report here.

[Qqmike]

I fixed this -- See Post #21 below. (The problem was that I tripled up my single quotes and backslashes ... oops ... those tiny single quotes are kind of hard to see.)

Whew, what a day, I must be missing something very subtle. Trying to boot the kernels (-100, 101, 103, 105, starting with -100, which seems to be "working"), using
Steve Riley's
https://www.kubuntuforums.net/showth...less-with-UEFI
or Kano's
https://www.phoronix.com/forums/foru...ge2#post377791
or even this, which adds in the initrd,
http://askubuntu.com/questions/51085...efistub-loader

Trying to test to see if the EFI firmware is able to boot directly these kernels.

My last of several tries was this, where I added in an initrd following the -u parameter:

sudo efibootmgr -c -d /dev/sda -p 1 -l '\EFI\StubL\vmlinuz-3.13.0-100-gen.efi' -L 'vmlinuz3130-100' -u 'root=/dev/sda2  initrd=\\EFI\\StubL\\initrd.img-3.13.0-100-generic quiet splash ro'

Each time, I get this

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

Yes, I googled it some. My ESP is FAT32; root is ext4; I don't see what this error could be. Time and attitude permitting, though obsession may rule, I'll look at it again tomorrow.

[GKNByNW]

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!).

[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.

[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! ;-)

[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]

(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]

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]

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

[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]

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!

[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]

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]

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

[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