2

Previous configuration:

  • Ubuntu 12.04 on /dev/sda [WD 2T HDD]
  • Ubuntu 14.04 on /dev/sdb [Hitachi 2T HDD]

~10 years old PC in BIOS mode (no PC in EFI in 2006!), basic Nvidia graphics card. The BIOS is set to boot on /dev/sdb where grub2 is installed and points at the 14.04 + the 12.04 that is on /dev/sda.

New configuration:

Recent PC set to EFI mode. No graphics card, using the integrated Intel GPU inside the Core i7 6700.

Ubuntu 16.04 (fresh install) on /dev/sda [Samsung 500G SSD]

Ubuntu 16.04 works fine with this configuration. The EFI points to boot on the SSD.

The issue:

Now, as I like having my old version of Ubuntu around, as a backup, and in case I forgot to reapply some useful tweak, I pulled the Hitachi drive from the old PC and installed it on the new PC.

So now I have:

  • Ubuntu 16.04 on /dev/sda [Samsung 500G SDD]
  • Ubuntu 14.04 on /dev/sdb [Hitachi 2T HDD]

Did a grub-update on the 16.04 to get the grub menu with the 14.04. The machine still boots fine on 16.04 with the grub menu displayed.

But the issue is that it does not boot correctly on the 14.04, when I select it from the grub menu.

What happens:

It is like if Ubuntu didn't find at all what hardware I am running, everything seems to be "by default".

I managed to enter the session by removing the NVIDIA drivers on the 14.04, but I get:

  • Default 1024x768 video (ugly on a 1920 LCD!)
  • No ethernet
  • No sound

Disks, keyboard and mouse work normally.

All that seems "kind of normal" as this installation of 14.04 was initially BIOS, and from what I could search, EFI seems to show the hardware differently to the kernel.

What kind of repair I would like:

The closest question was this one: Which commands to convert a Ubuntu BIOS install to EFI/UEFI without boot-repair on single boot hardware?

But in this post the op didn't have a working machine, which I have (on 16.04) and didn't have an EFI boot installed, which I already have.

I would prefer to understand what I am doing too, instead of using automated Boot-Repair (which I doubt would do anything clever in my case).

The answer to the question above, suggested to install the grub-efi in the version to repair. It does not really work in my case, because:

  1. I don't wish to create an EFI partition on my HDD (/dev/sdb) as I already have a working one on my SSD (/dev/sda) from which I boot.
  2. if I do a grub-efi-update on the 14.04, asking it to install grub on /dev/sda, it will probably overwrite the 16.04 in the efi partition with that of the older 14.04. That is not desirable!

Indeed, I could also dd the beginning of /dev/sda to restore it after 14.04 has overwritten it, but such manipulations are "dangerous" and bear a risk of destroying everything!

I already tried:

Successfully:

  • removed nVidia drivers so to get a "minimal" session on 14.04. With the Nvidia drivers, it was going as far as lightdm, but failed to start the Unity session.

Unsuccessfully:

  • tried to modprobe e1000e (the ethernet Intel driver used by the 16.04) and ptp plus pps_core. The modules loaded correctly but didn't provide me with an ethernet interface
  • mounting the efi partition on the /etc/fstab, same as it is mounted in the 16.04. No difference.
  • tried to add insmod efivars by live-editing (Emacs style) the grub menu: does not work, there is no efivars.mod in the 14.04 boot modules list (neither on the 16.04)

What I didn't do yet:

Install 14.04 in EFI mode on a spare partition I reserved for future use, NOT installing grub-efi if possible (see above), and if not possible, putting it on an USB key I don't care to destroy. Then trying to understand the differences from that installed version with the one on my HDD.

What step do you suggest next to avoid a full reinstall of 14.04, or overwriting my 16.04 efi grub?


I would like the kernel to guess the drivers "automatically", as it is supposed to do when you don't disrupt it with BIOS/EFI issues.

Here is my understanding of the issue I can't solve (by lack of clear documentation).

Boot process: (as far as I understand it)

  • Power on button
  • EFI (or BIOS) starts and scans the hardware
  • Start reading from whatever storage device is parameterized for an "initial loader" (MBR, EFI loader...)
  • With EFI it goes through the EFI partition, runs some of the executables there (for example shimx64.efi to circumvent the M$-Secure-Lockdown feature), which are capable of minimal-mounting Linux partitions like ext2/3/4. Read from the grub.cfg that is there to find where the "real" grub loader is.
  • Starts that "real" grub loader (on /dev/sda3 for me).
  • This "real" grub-loader (from the 16.04) reads the menu which contains lines for the current version (16.04), recoveries and lines from the old 14.04 I added.
  • When I choose 14.04 it then starts the correct vmlinuz on /dev/sdb1 with the corresponding initrd image.
  • From there the kernel is loaded and will try to get the correct drivers for the machine (modules). It can do that from the /etc/modules ("manual" method) or by looking at your configuration as it is reported by BIOS/EFI ("automatic" method).
  • When the system is set as EFI, the way the kernel will look at your configuration is through efivars, for which I found some documentation here: https://firmware.intel.com/blog/accessing-uefi-variables-linux. Basically, there is pseudo filesystem in /sys/firmware/efi that allows the kernel to query your configuration and act accordingly.

My guess is that obviously a BIOS-installed system does otherwise. The way for the kernel to query the BIOS being different and the system being booted as EFI, the kernel finds "no hardware"... and so initializes only a default machine.

How to tell that old installation of 14.04: "now you have been booted through EFI, please use efivars to get the hardware details".

Don't hesitate to correct me if I was grossly wrong in my assumptions of the (simplified) description of the boot process, and to point me to any useful links about that.

6
  • 1
    I have multiple Ubuntu installs and last install overwrites the ESP entry for /EFI/ubuntu folder, have yet to find a work around. Actual only change is the 3 line grub.cfg in ESP that is a configfile to full grub. cfg in install. You should be able to boot from one time boot key, but not grub unless both installs are BIOS or both UEFI. Once you start booting in one mode you cannot change to other mode, or grub only boots other installs in same boot mode. While not recommended you can boot a MBR second drive in UEFI from ESP on sda. You would have to backup ESP on sda first and then restore it.
    – oldfred
    May 30, 2016 at 22:44
  • Nice, can you give me any pointers on how to boot the second drive that is indeed MBR from the ESP?
    – Zakhar
    May 31, 2016 at 19:06
  • UEFI has CSM which allows BIOS boot. But you have to do that from UEFI or one time boot key. When system starts (from cold boot) does screen show keys to get into UEFI and boot menu? Often f10 or f12 is boot menu, but varies by vendor, check manual if not shown. And that should give you both UEFI entries and the BIOS boot option on that drive.
    – oldfred
    May 31, 2016 at 19:58
  • Indeed, I have an Asus H170M-Plus (asus.com/en/Motherboards/H170M-PLUS) with CSM option. It is cumbersome changing EFI option to boot as it is not through F8 one-time-boot-menu and you have to go through the all settings. Furthermore, I already tried to set all parameters to "Legacy OPROM" and that does not seem to be much better. The only thing I gain booting from /dev/sdb is 1920 definition, be it EFI or Legacy.
    – Zakhar
    May 31, 2016 at 21:04
  • Whats a 1920 definition? With older drive and Skylake processor you may need multiple boot parameters. I only installed 16.04 with my Skylake build in Feb as I knew older kernels would not support new hardware.
    – oldfred
    May 31, 2016 at 22:54

2 Answers 2

1

To recap: you moved a BIOS booting 14.04 disk to a UEFI 16.04 system, reran update-grub, and can now boot the 14.04 system, but have video/driver problems. Your solution is to uninstall all the (old system) proprietary drivers to get back to a default system, then install any new drivers.

Click on the "Settings" button on "software updater", under the "Ubuntu Software" tab, click on the "proprietary drivers..." button, and under the "additional drivers" tab see which proprietary drivers are offered, and click on the ones you want (and maybe reboot). Nothing happens automatically.

You might also want to install the backports to the 14.04 system to get a more up-to-date kernel for your 6700. That's it. No "conversion" needed. So what if your moved 14.04 updates change the (unused) grub.cfg on that system -- you just rerun update-grub on the 16.04 system. So what if it doesn't have any reference to /boot/efi (although you could add that easily enough with a line in the /etc/fstab file). You don't have a boot problem at all.

3
  • Perfectly summarized! That is an acceptable solution, but I'd rather let Ubuntu manage with drivers than add them "manually". From what I read, it is supposed to "automatically" use the right drivers... provided the kernel can see the hardware! So setting the drivers "manually" is still an option, such as setting the IPV4 address "manually" instead of using DHCP and a lease, but I'd prefer the "automatic" way. I'll add a post to clarify. For the kernel, I'll definitely update it if the one in Trusty does not handle things like Crypto using the accelerates AES instruction (I need that!)
    – Zakhar
    May 31, 2016 at 19:07
  • New hardware needs new kernels, drivers & support software. Some very new hardware like Skylake is still getting updates and even Haswell is getting improvements. They may be in newest kernel, but will not be in a distribution till next one is released. Probably 16.10, and not even 16.04.1. Many with new systems then use ppa to automatically get new kernels & drivers.
    – oldfred
    Jun 1, 2016 at 13:06
  • I tested with a live USB 14.04.3 and all seems to work: ethernet, sound, and the screen is correctly in 1920x1080. So that will be probably enough for this "backup" version and to copy my tweaks. Obviously from live USB you don't use the Intel Video driver. I have to look how to test if it is used on a disk-installed version. I might have the kernel from 14.04.0 on that version though, and I'll probably upgrade to the last one supported there.
    – Zakhar
    Jun 1, 2016 at 21:50
1

I give up the idea to convert the old installation from BIOS to EFI.

Instead, I'll use @oldfred's suggestion to dual-boot through the MotherBoard when I need it.

This has in fact advantages:

  • I don't need to have a Grub-Menu waiting (even 3 seconds) to boot in my everyday system (16.04), thus I'll save time booting.
  • When I want to boot the old system (14.04), hitting F8 at startup is not harder than the arrow keys!
  • I can keep my BIOS install on /dev/sdb because my motherboard can boot both EFI and BIOS, thus when booting 14.04, it will be in BIOS mode.

Anyway, even in BIOS mode I drivers don't load, but as this is another issue, I'll do another question to try and fix these drivers.

This question is therefore closed, nevertheless if you find a good documentation about the detailed boot process of a Linux Box, I'll be delighted to read it!

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .