On my MacBookPro 8,2, I just upgraded to Ubuntu 18.04 from 17.10 and my builtin wifi card is no longer recognized. My preferred method to boot is via the EFI Stub Loader bypassing grub2. As a backup, grub2 is correctly configured.
Here is my refind_linux.conf:
"Boot with defaults" "root=UUID=8a0c91a2-1477-4c32-9e51-efc345f83fc7 ro quiet splash i915.modeset=0 radeon.modeset=1"
"Boot into single-user mode" "root=UUID=8a0c91a2-1477-4c32-9e51-efc345f83fc7 ro quiet splash single"
"Boot without graphics" "root=UUID=8a0c91a2-1477-4c32-9e51-efc345f83fc7 ro"
After the upgrade, the wifi was no longer recognized, so I booted via grub and wifi worked. So I generated a refind_linux with mkrlconf. It looks different, but still the wifi is not recognized.
"Boot with standard options" "root=UUID=8a0c91a2-1477-4c32-9e51-efc345f83fc7 ro quiet splash vt.handoff=1"
"Boot to single-user mode" "root=UUID=8a0c91a2-1477-4c32-9e51-efc345f83fc7 ro quiet splash vt.handoff=1 single"
"Boot with minimal options" "ro root=UUID=8a0c91a2-1477-4c32-9e51-efc345f83fc7"
I prefer to NOT use grub because EFI stub is faster. Any suggestions?
Thanks for the hard work!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This sounds more like a Linux question than a rEFInd one, but lets check something to confirm:
First I'm assuming from your post that you already checked that booting from Grub -AFTER- the Ubuntu upgrade, the WiFi works.
If that is true, check what is the output of "cat /proc/cmdline" when booting with Grub (with WiFi working) and booting with rEFInd (without a working WiFi)
This is also likely to be a Kernel version/configuration issue. Possibly your Grub configuration and your Refind configuration differ after the upgrade and are booting different Kernels, so, check the output of "uname -a" when booting with Grub (WiFi working) and with rEFInd (WiFi not working).
This may give you some clues of what may be wrong and possibly you can go from there if the outputs of the above checks are different.
Anyway, you can post your results here so that we can help you further.
Good luck
Last edit: mfvianna 2018-04-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
@mfvianna !!! You were correct! Grub boots kernel 4.15.0-20 and EFI stub boots 4.15.0-13. I can override that selection by hitting TAB and selecting 4.15.0-20 from the menu, but what's going on? Why won't EFI stub load the most recent kernel?
Thanks
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Well... it should (actually rEFInd should). Technically speaking, the EFI stub is part of the Linux Kernel, i.e., it is within the Kernel and makes the Kernel file to look like an EFI executable, so, it is not the stub to blame as, when the stub runs, the Kernel was already loaded.). The case here is that rEFInd is not selecting the newest version of the Kernel to boot. Lets see why:
According to the "refind.conf-sample" file provided with rEFInd, when the "fold_linux_kernel" option is used (the default), which seems to be your case (as well as mine), it uses the file timestamps to determine which is the most recent one which, by the way, makes sense (see the extract from the sample below):
# Combine all Linux kernels in a given directory into a single entry.
# When so set, the kernel with the most recent time stamp will be launched
# by default, and its filename will appear in the entry's description.
# To launch other kernels, the user must press F2 or Insert; alternate
# kernels then appear as options on the sub-menu.
# Default is "true" -- kernels are "folded" into a single menu entry.
#
#fold_linux_kernels false
What probabbly happened in your case is that when you upgraded Ubuntu, the installer copied the new kernel files to the destination dir preserving the date of packaging (or something like that) that is older than the date your 4.15.0-13 kernel files have. Another possibility is that the 4.15.0-13 package for the older Ubuntu version was released after the 4.15.0-20 for the newer Ubuntu version. The results would be the same, anyway...
Simply check their dates to confirm the theory.
Being that the case, you should get the expected results by simply "touching" the files (i.e. updating their dates to the current one):
# cd /<whatever-dir-your-kernels-are-in>
# touch *4.15.0-20*
OBS: Take caution to "touch" only the desired kernel (4.15.0-20) otherwise, for obvious reasons, the confusion will persist.
OBS2: This is very likely caused by the update process or kernel releases packaging, so you should not face this issue again with regular updates as they should, at least in principle, install new kernels with newer dates than the older ones.
Good luck
Last edit: mfvianna 2018-04-30
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Ohhhhh yeahhhhh..... I totally touched those files... AND THEY LOVED IT!!!
Thanks mfvianna for the help. It might have taken me weeks to notice the different kernels loading. Or more likely, the kernel would have been updated and the problem went away and I never would have known what happened.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello!
On my MacBookPro 8,2, I just upgraded to Ubuntu 18.04 from 17.10 and my builtin wifi card is no longer recognized. My preferred method to boot is via the EFI Stub Loader bypassing grub2. As a backup, grub2 is correctly configured.
Here is my refind_linux.conf:
After the upgrade, the wifi was no longer recognized, so I booted via grub and wifi worked. So I generated a refind_linux with mkrlconf. It looks different, but still the wifi is not recognized.
I prefer to NOT use grub because EFI stub is faster. Any suggestions?
Thanks for the hard work!
This sounds more like a Linux question than a rEFInd one, but lets check something to confirm:
First I'm assuming from your post that you already checked that booting from Grub -AFTER- the Ubuntu upgrade, the WiFi works.
If that is true, check what is the output of "cat /proc/cmdline" when booting with Grub (with WiFi working) and booting with rEFInd (without a working WiFi)
This is also likely to be a Kernel version/configuration issue. Possibly your Grub configuration and your Refind configuration differ after the upgrade and are booting different Kernels, so, check the output of "uname -a" when booting with Grub (WiFi working) and with rEFInd (WiFi not working).
This may give you some clues of what may be wrong and possibly you can go from there if the outputs of the above checks are different.
Anyway, you can post your results here so that we can help you further.
Good luck
Last edit: mfvianna 2018-04-29
@mfvianna !!! You were correct! Grub boots kernel 4.15.0-20 and EFI stub boots 4.15.0-13. I can override that selection by hitting TAB and selecting 4.15.0-20 from the menu, but what's going on? Why won't EFI stub load the most recent kernel?
Thanks
Now that's a rEFInd question :-)
Well... it should (actually rEFInd should). Technically speaking, the EFI stub is part of the Linux Kernel, i.e., it is within the Kernel and makes the Kernel file to look like an EFI executable, so, it is not the stub to blame as, when the stub runs, the Kernel was already loaded.). The case here is that rEFInd is not selecting the newest version of the Kernel to boot. Lets see why:
According to the "
refind.conf-sample" file provided with rEFInd, when the "fold_linux_kernel" option is used (the default), which seems to be your case (as well as mine), it uses the file timestamps to determine which is the most recent one which, by the way, makes sense (see the extract from the sample below):What probabbly happened in your case is that when you upgraded Ubuntu, the installer copied the new kernel files to the destination dir preserving the date of packaging (or something like that) that is older than the date your 4.15.0-13 kernel files have. Another possibility is that the 4.15.0-13 package for the older Ubuntu version was released after the 4.15.0-20 for the newer Ubuntu version. The results would be the same, anyway...
Simply check their dates to confirm the theory.
Being that the case, you should get the expected results by simply "touching" the files (i.e. updating their dates to the current one):
OBS: Take caution to "touch" only the desired kernel (4.15.0-20) otherwise, for obvious reasons, the confusion will persist.
OBS2: This is very likely caused by the update process or kernel releases packaging, so you should not face this issue again with regular updates as they should, at least in principle, install new kernels with newer dates than the older ones.
Good luck
Last edit: mfvianna 2018-04-30
Ohhhhh yeahhhhh..... I totally touched those files... AND THEY LOVED IT!!!
Thanks mfvianna for the help. It might have taken me weeks to notice the different kernels loading. Or more likely, the kernel would have been updated and the problem went away and I never would have known what happened.
You are welcome :-)