Cannot load latest kernels

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

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

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

[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)?

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

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

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.

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

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

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

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.

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

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]

EDIT: See my post below.

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