R Installation in Centos/RHEL-7 with R-Studio

R installation on CentOS/RHEL - 7 with R-Studio

Step 1: Make local repository 

First we need to mount the iso image into /mnt/cdrom directory.

[root@master ~]#  mount -t iso9660 /dev/cdrom /mnt/cdrom

[root@master ~]# vim /etc/yum.repo.d/centos.repo
[centos]
name=CentOS
baseurl=file:///mnt/cdrom
enabled=1
gpgcheck=0

Save it  with [esc]:wq!

Step 2: Download and Configure epel-release rpm

[root@master ~]# wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
[root@master ~]# yum localinstall epel-release-*
[root@master ~]# yum clean all
[root@master ~]# yum repolist

Step 3: Manually download Dependencies Packages( If you installing R, without installing the dependencies manually then it's occurs dependencies error, so it better download one-by-one and install it.)

[root@master ~]# wget ftp://195.220.108.108/linux/epel/7/x86_64/r/R-java-3.4.0-2.el7.x86_64.rpm
[root@master ~]# yum localinstall R-java-*
[root@master ~]# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/blas-devel-3.4.2-5.el7.x86_64.rpm
[root@master ~]# yum localinstall blas-devel-3.4.2-5.el7.x86_64.rpm
[root@master ~]# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/lapack-devel-3.4.2-5.el7.x86_64.rpm
[root@master ~]# yum localinstall lapack-devel-3.4.2-5.el7.x86_64.rpm
[root@master ~]# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/texinfo-tex-5.1-4.el7.x86_64.rpm
[root@master ~]# yum localinstall texinfo-tex-5.1-4.el7.x86_64.rpm
[root@master ~]# wget http://mirror.centos.org/centos/7/os/x86_64/Packages/texlive-epsf-svn21461.2.7.4-38.el7.noarch.rpm
[root@master ~]# yum localinstall texlive-epsf-svn21461.2.7.4-38.el7.noarch.rpm

[root@master ~]# yum clean all
[root@master ~]# yum repolist
[root@master ~]# yum update; init 6

Step 4: Disable selinux
[root@master ~]# setenforce 0

Step 5: Disable Firewall
[root@master ~]# systemctl stop firewalld.service
[root@master ~]# systemctl disable firewalld.service


Step 6: Now, Install R
[root@master ~]# yum install R

Step 7: Download R-Studio Server 
[root@master ~]# wget https://download2.rstudio.org/rstudio-server-rhel-1.0.143-x86_64.rpm
[root@master ~]# yum localinstall --nogpgcheck rstudio-server-rhel-1.0.143-x86_64.rpm
[root@master ~]# service rstudio-server status/start/stop/

Step 8: Check R in shell prompt: type R

[root@master ~]# R
R version 3.4.0 (2017-04-21) -- "You Stupid Darkness"
Copyright (C) 2017 The R Foundation for Statistical Computing
Platform: x86_64-redhat-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

  Natural language support but running in an English locale

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

>
> version
               _
platform       x86_64-redhat-linux-gnu
arch           x86_64
os             linux-gnu
system         x86_64, linux-gnu
status
major          3
minor          4.0
year           2017
month          04
day            21
svn rev        72570
language       R
version.string R version 3.4.0 (2017-04-21)
nickname       You Stupid Darkness

All done... Happy Learning R

Install and configure GANGLIA ON CENTOS/RHEL

INSTALL AND CONFIGURE GANGLIA ON CENTOS/RHEL

This article will guide you through the installation and configuration steps for Ganglia-3.6.0 on CentOS/RHEL 6.3

1) About

Ganglia is a scalable distributed monitoring system for high-performance computing systems such as clusters and Grids. It is based on a hierarchical design targeted at federations of clusters. It leverages widely used technologies such as XML for data representation, XDR for compact, portable data transport, and RRDtool for data storage and visualization.

Ganglia has following three main components:

1) Ganglia Monitoring Daemon (gmond) 
It is a lightweight service that is installed on every machine you’d like to monitor.
Gmond has four main responsibilities:

• Monitor changes in host state.
• Announce relevant changes.
• Listen to the state of all other ganglia nodes via a unicast or multicast channel.
• Answer requests for an XML description of the cluster state.

Each gmond transmits in information in two different ways:

• Unicasting or Multicasting host state in external data representation (XDR) format using UDP messages.
• Sending XML over a TCP connection.

2) Ganglia Meta Daemon (gmetad)
The ganglia meta daemon (gmetad) is a service that collects data from other gmetad and gmond sources and stores their state to disk in indexed round-robin databases. Gmetad provides a simple query mechanism for collecting specific information about groups of machines.

3) Ganglia PHP Web Front-end 
The Ganglia web front-end provides a view of the gathered information via real-time dynamic web pages. Most importantly, it displays Ganglia data in a meaningful way for system administrators and computer users using PHP.

Other component are:
4) Gmetrics
The ganglia metric tool is a commandline application that you can use to inject custom made metrics about hosts that are being monitored by ganglia. It has the ability to spoof messages as coming from a different host in case you want to capture and report metrics from a device where you don’t have gmond running (like a network or other embedded device).

4) Gstat
The ganglia stat tool is a commandline application that you can use to query a gmond for metric information directly.

1) Prerequisite

• Following dependent package needs to be installed first, before installing Ganglia.
  

     yum -y install apr-devel apr-util check-devel cairo-devel pango-devel libxml2-devel rpmbuild glib2-devel \
     dbus-devel freetype-devel fontconfig-devel gcc-c++ expat-devel python-devel libXrender-devel 
• Other dependent packages that need to be Installed are rrdtool and confuse that are covered in installation steps.

2) Installation
2.1) Create user ganglia by which we will be running ganglia services:

   useradd ganglia
   password ganglia

2.2) Create a directory where you would download ganglia source:

   mkdir /usr/local/src
   cd /usr/local/src

2.3) First of all we need to Download/Untar/Compile/Install all necessary files for confuse:

   wget http://savannah.nongnu.org/download/confuse/confuse-2.7.tar.gz
   tar -xzvf confuse-2.7.tar.gz
   cd confuse-2.7
   ./configure
   make
   make install

2.4) Secondly we need to Download/Untar/Compile/Install all necessary files for rrdtool:

   cd /usr/local/src
   wget http://oss.oetiker.ch/rrdtool/pub/rrdtool.tar.gz
   tar -xzvf rrdtool.tar.gz
   cd rrdtool-1.4.8/
   ./configure --prefix=/usr
   make -j8
   make install
   which rrdtool

2.5) Make sure all the new installed package have libraries linked using *ldconfig* command:

   vi /etc/ld.so.conf
      /usr/local/lib
   Then execute the following command:
   ldconfig

2.6) Now all the dependency are installed now is the time to Download/Untar/Compile/Install all necessary files for ganglia-core package:

   cd /usr/local/src
   wget http://sourceforge.net/projects/ganglia/files/ganglia%20monitoring%20core/3.6.0/ganglia-3.6.0.tar.gz
   tar -xzvf ganglia-3.6.0.tar.gz
   ./configure --with-gmetad
   make -j8
   make install

NOTE: You should exit without errors. If you see errors, then you may want to check for missing libraries.

3) Configuring Ganglia
3.1) Create the config directory for Ganglia:

   mkdir /etc/ganglia

3.2) Copy the sample gmetad configuration file: 

   cp gmetad/gmetad.conf /etc/ganglia/

3.3) Generate the initial gmond configuration file: 

   gmond -t | tee /etc/ganglia/gmond.conf

3.4) Copy the initial startup script, change the binary and config path and enable it on boot: 

   cp gmetad/gmetad.init /etc/rc.d/init.d/gmetad
   cp gmond/gmond.init /etc/rc.d/init.d/gmond
   vi /etc/init.d/gmetad

       #GMETAD=/usr/sbin/gmetad
       GMETAD=/usr/local/sbin/gmetad
       #daemon $GMETAD
       daemon $GMETAD -c /etc/ganglia/gmetad.conf

   vi /etc/init.d/gmond

       #GMOND=/usr/sbin/gmond
       GMOND=/usr/local/sbin/gmond
       # daemon $GMOND
       daemon $GMOND -c /etc/ganglia/gmond.conf

   chkconfig --add gmetad
   chkconfig --add gmond

3.4) Now create a storage directory for RRDTool and make sure rrdtool can write to it: 

   mkdir -p /var/lib/ganglia/rrds
   chown ganglia:ganglia /var/lib/ganglia/rrds

3.5) Modify the following parameter in gmetad config file: 

   vi /etc/ganglia/gmetad.conf
      data_source "Ganglia Test Setup" FQDN Name of Ganglia Server
      setuid_username "ganglia"
      case_sensitive_hostnames 0

Note: Replace “FQDN Name of Ganglia Server” with your DNS server name.

3.6) Lastly modify the following parameter in gmond config file:

   vi /etc/ganglia/gmond.conf
   user = ganglia
   cluster {
      name = "Ganglia Test Setup"
      owner = "Ops"
      latlong = "unspecified"
      url = "unspecified"
    }

   udp_send_channel {
      host = FQDN Name of Ganglia Server
      port = 8649
      ttl = 1
    }

udp_recv_channel {
      port = 8649
    }

tcp_accept_channel {
      port = 8649
}

Note: *) Replace “FQDN Name of Ganglia Server” with your DNS server name.
*) By default gmond will use reverse DNS resolution when displaying hostname, to override this value use“override_hostname” config parameter.
*) Gmond will use IP Address in case DNS resolution and “override_hostname” is not set.

4) Validation and Testing
4.1) First try to run gmetad daemon in debug mode and see everything is fine on one of the terminal window:

   gmond -d 5 -c /etc/ganglia/gmond.conf

   Going to run as user nobody
   Sources are ...
   Source: [Ganglia Test Setup, step 15] has 1 sources
    127.0.0.1
   xml listening on port 8651
   interactive xml listening on port 8652
   Data thread 140442277627648 is monitoring [Ganglia Test Setup] data source
       127.0.0.1
   cleanup thread has been started
   data_thread() for [Ganglia Test Setup] failed to contact node 127.0.0.1
   data_thread() got no answer from any [Ganglia Test Setup] datasource

4.2) First try to run gmond daemon in debug mode and see everything is fine on second terminal window:

   gmond -d 5 -c /etc/ganglia/gmond.conf

   saving metadata for metric: disk_free host: localhost
   Processing a metric value message from localhost
   ***Allocating value packet for host--server001.gauri.com-- and metric --disk_free-- ****

   Processing a metric metadata message from localhost
   ***Allocating metadata packet for host--localhost-- and metric --part_max_used-- ****

4.3) Open another terminal window and see rrd file are created or not:

   ls -lh /var/lib/ganglia/rrds/
   total 8.0K
   drwxr-xr-x. 4 ganglia ganglia 4.0K Aug 16 16:28 Ganglia Test Setup
   drwxr-xr-x. 2 ganglia ganglia 4.0K Aug 16 16:28 __SummaryInfo__

4.4) Once you are convinced that everything is fine, stop these process in daemon mode (by pressing CTRL + C) and start there individual service that we have created earlier:

   service gmetad start
   service gmond start
 

4.5) Verify process are running and respective ports are opened:

   ps -ef | grep -v grep | grep gm
   ganglia   6226     1  0 16:59 ?        00:00:00 /usr/local/sbin/gmetad -c /etc/ganglia/gmetad.conf
   ganglia   6267     1  0 17:01 ?        00:00:00 /usr/local/sbin/gmond -c /etc/ganglia/gmond.conf

   netstat -plane | egrep 'gmon|gme'
   tcp        0      0 0.0.0.0:8649                0.0.0.0:*                   LISTEN      502        1067310    6267/gmond          
   tcp        0      0 0.0.0.0:8651                0.0.0.0:*                   LISTEN      502        1047072    6226/gmetad         
   tcp        0      0 0.0.0.0:8652                0.0.0.0:*                   LISTEN      502        1047073    6226/gmetad         
   udp        0      0 0.0.0.0:8649                0.0.0.0:*                               502        1067309    6267/gmond 
 

5) Deploying Ganglia Web
5.1) Download the package and Untar it:

   cd /usr/local/src/
   wget http://sourceforge.net/projects/ganglia/files/ganglia-web/3.5.10/ganglia-web-3.5.10.tar.gz
   tar -xzvf ganglia-web-3.5.10.tar.gz
   cd ganglia-web-3.5.10

5.2) Modify the Makefile Config that will be used to deploy ganglia web:

   vi Makefile
      # Location where gweb should be installed to (excluding conf, dwoo dirs).
      GDESTDIR = /var/www/html/ganglia

      # Gweb statedir (where conf dir and Dwoo templates dir are stored)
      GWEB_STATEDIR = /var/lib/ganglia-web

      # Gmetad rootdir (parent location of rrd folder)
      GMETAD_ROOTDIR = /var/lib/ganglia

      # User by which your webserver is running
      APACHE_USER =  apache

5.3) Now install Ganglia Web, once we have done the config changes:

   make install

5.4) Try to open Ganglia Web UI in your favourite Web Browser:

   http://localhost/ganglia
   OR  
   http://Server-IP-Address/ganglia

NOTE : In case of any issue try to disabling iptables and selinux as described in next Section and check.

6) Security Rules
6.1) Firewall Rule for Ganglia
6.1.1) Temporary disabling IPTables rules:

   service iptables stop

6.1.2) Firewall port (8649) that needs to be open for Ganglia daemon:

   iptables -A INPUT -p udp -m udp –dport 8649 -j ACCEPT

6.1.3) Firewall port (80) that needs to be open for Ganglia Web:

   iptables -A INPUT -p tcp -m tcp –dport 80 -j ACCEPT

6.1.4) Save the Iptables rules and restart it:

   service iptables save
   service iptables restart

6.2) SELinux Rule for Ganglia
6.2.1) Temporary disabling SELinux rules:

   echo 0 >/selinux/enforce 

Once we are fully convinced that Ganglia Server is running successfully, now is time to do nodes (i.e. Client) Setup.

7) Preparing Client package for ganglia
Build up the Ganglia Client Package that will be deployed on client machine:

   tar -czvf /tmp/ganglia-client.tar.gz /usr/local/sbin/gmond /etc/ganglia/gmond.conf /etc/init.d/gmond \
   /usr/local/lib64/libganglia-3.6.0.so.0* /lib64/libexpat.so.1* /usr/local/lib/libconfuse.so* \
   /usr/lib64/libapr-1.so* /usr/local/lib64/ganglia

8) Deploying Client package
8.1) SCP the tar package on one of the Client box from Ganglia Server:

   scp /tmp/ganglia-client.tar.gz root@CLIENT-MACHINE-IP-OR-NAME:/tmp/

8.2) Untar the package using following command:

   tar -C / -xzvf /tmp/ganglia-client.tar.gz

8.3) Create user ganglia as well and start the gmond service:

   useradd ganglia
   service gmond start

8.4) Verify the gmond process is running:

   ps -ef | grep -v grep | grep gmond

8.5) Also check the rrd file is created for this machine on the Ganglia Server or checking Ganglia Web UI:

   ls -lh /var/lib/ganglia/rrds/Ganglia\ Test\ Setup/
   total 8.0K
   drwxr-xr-x. 2 ganglia ganglia 4.0K Aug 16 16:28 localhost
   drwxr-xr-x. 2 ganglia ganglia 4.0K Aug 16 16:28 web001
   drwxr-xr-x. 2 ganglia ganglia 4.0K Aug 16 16:28 __SummaryInfo__

8.6) Add the other nodes (Client) to Ganglia Server by repeating the steps mentioned from 8.1 to 8.5:

Congratulations! You have successfully deployed Ganglia Setup, grap a glass of bear and enjoy exploring it.

Add new node to existing Platform LSF Cluster

Add new node to existing Platform LSF Cluster

If the new host type already exists

See if the new node is of the same type (eg. linux2.6-glibc2.3-x86_64) as those existing in the cluster.
If it does, a sub directory named (eg. linux2.6-glibc2.3-x86_64) with its type will exist in LSF_TOP/7.0

1. Log on to the master host as root,
2. add the hosts to lsf.cluster.cluster_name (file can be fount at LSF_TOP/conf). If they are servers, specify 1, otherwise specify 0. You can use !  for model and type for automatic detection.
3. run badmin mbdrestart
4. On the new host, create “lsfadmin” user & run ./hostsetup –top=”/usr/share/lsf” –boot=”y” found under LSF_TOP/7.0/install as root user.
5. Start LSF on the new host with: lsadmin limstartup, lsadmin resstartup and badmin hstartup

If the new host is different architecture

1. Get the LSF distribution file for the new type (eg aix5-64) from the download section in my.platform.com (Need valid user account to login)
2. Edit install.config in LSF_TOP/7.0/install
3. Change the following parameters:
a. For LSF_TARDIR, specify the path to the tar file. For example:LSF_TARDIR=”/usr/share/lsf_distrib/7.0″
b. For LSF_ADD_SERVERS, list the new host names enclosed in quotes and separated by spaces.
For example:LSF_ADD_SERVERS=”hosta hostb”
4. Run ./lsfinstall -f install.config. This automatically creates the host information in lsf.cluster.cluster_name.
5. Run lsadmin reconfig and badmin reconfig

UEFI Boot Process

The UEFI boot specification offers new capabilities – and new headaches if you aren’t ready for it.

Master Boot Record

Until recently, most computers used the Basic Input Output System (BIOS or legacy BIOS) for managing the boot process. The BIOS performs a few preliminary tasks and then loads the boot sector of the hard disk. This boot sector is called the Master Boot Record (MBR). The MBR is the first 512 bytes at the beginning of the disk that describe not only the layout of the disk (partitions), but also how to start loading the operating system. The MBR has changed slightly over the years, but it is not radically different from when it was first created in 1983.

The MBR contains four primary partitions, and one of these partitions is set as the active or bootable partition. Along with a list of the partitions, the MBR contains a very small (approximately 440 bytes) bootloader to load the operating system. This bootloader will find the active partition and then proceed to execute the Volume Boot Record (the first sector of that partition), which will continue the process of loading the operating system.

The MBR has some limitations that have held back progress. Two such limitations are that the number of primary partitions is limited to four, and the size of disk partitions is limited to 2TB. These limits were not a problem when the MBR first appeared, but now that it is possible to purchase a 3TB USB drive for less than Rs 10000/- , these issues have become more and more visible.

Experts have long recognized a need to break with the past and produce a modern, operating-system-independent firmware with support for booting from large disks, as well as a flexible pre-OS environment, network capability, and a modular design. The Extended Firmware Interface from Intel is the result. An industry-wide organization was formed in 2005 to promote adoption of the EFI specification, and the specification was then renamed Unified EFI (UEFI).

Unified Extended Firmware Interface

The UEFI brings the concept of the BIOS to a whole new level. Instead of a 512-byte MBR and some boot code, the UEFI, in contrast to the legacy BIOS option, knows what a filesystem is and even has its own filesystem, with files and drivers. This filesystem is typically between 200 and 500MB and formatted as FAT32.

Instead of a few bytes of assembly code for loading the operating system, each installed OS should have its own bootloader (e.g., grubx64.efi). This bootloader will have enough logic to either display some sort of boot menu or start loading an operating system. Basically, UEFI is its own mini-operating system.

UEFI has thrown out the old MBR partition methodology and instead uses GPT for managing partition tables. Using GPT eliminates the limitation on the number of partitions and also ensures support for larger partitions of up to 9ZB. (A zettabyte is 10²¹ bytes.) The GPT partition is part of the UEFI standard, but it is limited to just a list of partitions with no bootloader logic. The specification allows for nearly an unlimited number of partitions, but specific implementations might impose more practical limits. (Windows, for instance, actually limits the number of partitions to 128.) Like the MBR, UEFI marks one of the partitions with the boot flag, but this is only the EFI partition, never any of the OS partitions.

The general structure of the EFI filesystem means that each operating system (or vendor) has its own directory. This directory can contain any and all necessary files for loading the operating system:

/EFI
    /Boot
    /Microsoft/
    /ubuntu
    /refind

Some directories have a fairly flat hierarchy, whereas others (e.g., Microsoft’s) are less so. The bootloader programs by default have the extension .efi; however, this is just convention: Bootloader files that are properly created and called work even without this extension.

Looking at the EFI directory structure gives hope that, with the next install or reinstall, another Microsoft operating system will not clobber my existing Linux installation, but I haven’t tried that yet.

One especially convenient thing about how UEFI has been implemented in Linux is that, after the computer is booted up, the EFI partition, at least in Kubuntu, is mounted under the boot partition (/boot/efi), which makes it easy to change or experiment with this filesystem.

Taking this one step further, though, a bootloader is just a program that performs the operation of loading the operating system. What if this program were a shell? A UEFI-capable shell would allow the user to interact with the UEFI system to modify boot parameters, launch bootloaders, and obtain information on the firmware environment. 

The drive designation FS0 refers to File System 0; depending on your configuration, you might also have an FS1 or FS2.

You can register a new shell, a new operating system, or multiple operating systems with UEFI. Thus, the computer itself can seamlessly support multiple operating systems or shells. You have a couple of different options for maintaining these entries.

The first would be using the Linux efibootmgr program to manipulate entries stored in the non-volatile RAM (NVRAM). Depending on the UEFI implementation, your UEFI might actually support efibootmgr when booting into the UEFI/BIOS screen. The Asus N76, which uses the Aptio UEFI-based firmware system from AMI, allows the user to register the program directly with the option Add New Boot Option (Figure 1).

Figure 1: Some firmware systems let you add your own boot option to the configuration.

Eventually, I was able to get this to work when I stopped trying to refer to the drive explicitly (in my case, \EFI\path versus FSO:\EFI\path). It was then possible to try out new bootloaders and a shell. The path entries are relative to the installed EFI partition.

Secure Boot

UEFI offers a lot of flexibility, more partitions, larger partitions, and an easy and standard way for setting up multiple operating systems. What’s not to like? Perhaps you’ve heard of UEFI’s infamous “secure boot” feature.

Secure boot will secure the boot process, preventing drivers or bootloaders that are not signed with a known key. As several sources in the open source community have already reported, this feature would effectively prevent someone from compiling their favorite distribution and installing it on their own PC (at least in the worse case – a somewhat better case would be if the user has the ability to turn off the secure boot feature.)

Fixing My Laptop

My configuration was as follows:

Drive 0:

• GPT partitioned
• UEFI filesystem
• Non-functional Windows installation

Drive 1:

• MBR partitioned
• A couple of partitions full of data
• Non-functional Linux installation

The incompatibility of GPT and MBR, and my subsequent repair efforts, left the system unbootable. When I first added Linux, the pre-existing bootloader couldn't boot the Linux system on the MBR-partitioned Drive 1. I tried changing the boot drive, which gave me my Linux back–including a GRUB menu that pointed to the Windows boot option, but Windows would not start successfully. To get Windows back, I tried to use the Windows Restore option, but it actually caused even more problems, eventually rendering my Linux system unbootable.

How did I correct the problems with my dual-boot mess? The ease of my recovery was because I had a backup image of the first disk prior to any installation of Linux, because Linux was being installed on the second disk, and because I recognized the need to install ubuntu with EFI support.

The list of tasks was quite small:

1. Convert drive 1 from MBR to GPT

2. Add/modify partitions on drive 1

3. Install ubuntu with EFI support

4. Save all EFI configuration from ubuntu install

5. Restore disk image for drive 0

6. Restore ubuntu setup to EFI partition

7. Reboot and test

Note: When dealing with partitions, it is important to back up important data.

Convert MBR to GPT

The laptop was booted with ubuntu 16.04 with a Live DVD. The partitions were fine; the problem was the partitioning, so the easiest thing was to use the sgdisk command to read in the old MBR partition table and write out a new GTP partition table.

It is important to keep in mind that there must be some free space to hold the new GPT structures. This might require resizing the first partition to leave some space free at the start of the disk, as well as resizing the final partition to leave some space at the end.

Once all preparation has been done, the following command performs the conversion:

sgdisk -g /dev/sdX

This command will do the proper conversion but will leave the drive without any bootable operating system.

Add/Modify Partitions

All partitioning was done during my previous install; no additional partitioning was necessary in this case. (You could also perform partitioning in the step in which you install ubuntu.)

Install ubuntu 16.04 with EFI Support

This step is easy but not 100% obvious. When you put a CD or DVD into the optical drive and boot, the UEFI will examine what media might be available; this could be a USB stick or a bootable DVD.

However, at least for my lapi, both a normal MBR-bootable DVD and a UEFI-bootable DVD were found in the list of bootable devices. Even though both entries refer to the same disk, it is important that the UEFI entry is chosen because the UEFI entry seems to be the trigger for using the EFI GRUB rather than the standard MBR setup. On my Asus, UEFI-bootable devices are prefixed with UEFI: in the boot list (Figure 2).

Figure 2: On my lapi, UEFI-ready boot devices are prefaced with UEFI:.

When you boot ubuntu as a UEFI device, it will bring up a familiar GRUB menu list. It is possible that any of these choices will successfully install any UEFI-compliant system, but I chose Install Expert Mode.

The process closely follows a standard graphic installation; I set up my swap (/) and /home partitions and selected GRUB as the bootloader. The only trick for this step is how you boot the disk.

Save ubuntu Configuration Files

The EFI partition is simply a FAT32 file system. Backing up the setup simply means copying the files to a safe location. Simply mount the EFI filesystem and copy the necessary files elsewhere:

mount /dev/sdX1 /mnt/mountpoint
cp -rp /mnt/mountpoint/EFI/refind /media/usbstick
cp -rp /mnt/mountpoint/EFI/ubuntu /media/usbstick

Note: your EFI directory will probably be partition 1, sdX1, but this doesn’t have to be the case.

Restore the Disk Image for disk1

I had never planned to make a mess of my installation, but before I started this grand adventure, I backed up drive 0 using dd:

Save: 
 dd bs=1M if=/dev/sdX of=/media/usbdevice/saved-image

Restore: 
dd bs=1M if=/media/usbdevice/saved-image of=/dev/sdX

At this point, the laptop drive 0 has the original Windows 7 installation, but the ubuntu bootloader setup has been lost. This has nothing to do with Microsoft or Windows but rather how I backed up the disk.

Restore the ubuntu EFI Configuration

The laptop was booted with ubuntu 16.04 on a Live DVD for this next step.

The EFI partition is simply a FAT32 file system. Restoring the setup simply means copying the files from a safe location:

mount /dev/sdX1 /mnt/mountpoint
cp -rp /media/usbstick/refind /mnt/mountpoint/EFI
cp -rp /media/usbstick/ubuntu /mnt/mountpoint/EFI

After restoring these files, I was able to reboot the lapi and start Linux or Windows 7.