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.