UEFI and Fedora/RHEL – trivially working.

My older son just enrolled into my alma mater, Singapore Polytechnic, to do Electrical Engineering.  It is really nice to see that he has an interest in that field and, yes, make me smile as well.

So, as part of the preparations for the new program, the school does need the use of software as part of the curriculum. Fortunately, to get a computer was not an issue per se, but what bothered me was that the school “is only familiar with windows” and so that applications needed are also meant to run on windows.

One issue led to another and eventually, we decided to get a new laptop for his work in school. Sadly, the computer comes only with windows 8.1 installed and nothing else. The machine has ample disk space (1TB) and the system was set up with two partitions – one for the windows stuff (about 250G) and the 2nd partition as the “D: drive”. Have not seen that in years.

I wanted to make the machine dual bootable and went about planning to repartition the 2nd partition into two and have about 350G allocated to running Fedora.

Then I hit an issue.  The machine was installed with Windows using the UEFI. While the UEFI has some good traits, but unfortunately, it does throw off those who want to install it with another OS – ie to do dual-boot.

Fortunately, Fedora (and RHEL) can be installed into a UEFI enabled system. This was taken care of by work done by Matthew Garrett as part of the Fedora project. Matthew also received the FSF Award for the Advancement of Free Software earlier this year. It could be argued that perhaps UEFI is not something that should be supported, but then again, as long as systems continue to be shipped with it, the free software world has to find a way to continue to work.

The details around UEFI and Fedora (and RHEL) is all documented in Fedora Secure Boot pages.

Now on to describing how to install Fedora/RHEL into a UEFI-enabled system:

a) If you have not already done so, download the Fedora (and RHEL) ISOs from their respective pages. Fedora is available at https://fedoraproject.org/en/get-fedora and RHEL 7 Release Candidate is at ftp://ftp.redhat.com/pub/redhat/rhel/rc/7/.

b) With the ISOs downloaded, if you are running a Linux system, you can use the following command to create a bootable live USB drive with the ISO:

dd  if=Fedora-Live-Desktop-x86_64-20-1.iso of=/dev/sdb

assuming that /dev/sdb is where the USB drive is plugged into. The most interesting thing about the ISOs from Fedora and RHEL is that they are already set up to boot into a UEFI enabled system, i.e., no need to disable in BIOS the secure boot mode.

c) Boot up the target computer via the USB drive.

d) In the case of my son’s laptop, I had to repartition the “D: drive” and so after boot up from the USB device, I did the following:

i) (in Fedora live session): download and install gparted (sudo yum install gparted) within the live boot session.

ii) start gparted and resize the “D: drive” partition. In my case, it was broken into 2 partitions with about 300G for the new “D: drive” and the rest for Fedora.

e) Once the repartitioning is done, go ahead and choose the “Install to drive” option and follow the screen prompts.

Once the installation is done, you can safely reboot the machine.

You will be presented with a boot menu to choose the OS to start.



Rescuing a SCO OpenServer 5.0.5 machine to run in a VM on RHEL5.4

I received a frantic SMS from an old classmate running a travel agency business saying that his SCO machine cannot now boot. He is running an application written to a 3-GL/4-GL product called Thoroughbred. He has had the system running since about 1999. And since it does not connect to the Internet, and only has internal LAN users coming in via a telnet connection, he never needed to keep it updated.

So, what was the problem? His 10-year old IBM tower machine failed to boot. Got some help from a local vendor and found that it was the power supply that failed not the harddisk. WIth the power supply replaced, he is now back in business. The proposal given to him from the vendor who fixed the hardware was to “upgrade to a new machine, but we cannot guarantee that the OS and applications you have running will work”.

Enter, the lunch meeting. After hearing his story, I thought his situation would make for an interesting case study for virtualization. So, with his permission, I got hold of the “still in original shrink-warp” SCO manuals and CDs along with the Thoroughbred software and installed the SCO OpenServer 5.0.5 in a RHEL 5.4 VM.

Here is what I had to do:
a) dd’ed the SCO OpenServer 5.0.5 CD (“you can now boot from the CD if your BIOS supports it”) into an iso. It came up to about 280M only!
b) From virtual-machine-manager, choose a new maching with full virtualization
c) Specified 800MB as the drive size (imagine that!)
d) Kept the defaults for the rest.
e) Proceeded with the boot up and installation.
f) All went well. It is hilarious to see the setting up of the harddisk with the sector numbers and heads being cycled through – the “drive” is virtual, and kudos to the virtualization engineers, the SCO installation program was sufficiently convinced that it was all real.
g) Boot up.

The boot up went well (user: root and password: fedora). But the network was not working. Had to start “scoadmin” to get into a curses based setup to configure the network device. I had to go back to virtual-machine-manager and set this VM to have a “pcnet” network. The default “hypervisor” network did not seem to work. The “pcnet” is apparently a ISA device which the SCO has drivers for. It was in the AMD section of the hardware network hardware setup section of the scoadmin command.

So here’s the /etc/libvirt/qemu/sco-openserver-5.0.5.xml:





[BTW, in the xml file above, I have to add a space after the < above so that it will not be interpereted by lj. Edit out the extra space if you want to use the xml file.]

The SCO OpenServer 5.0.5 does not have DHCP default and needs an IP to be specified. So, an IP, netmask and default gw has to be specified manually. Interestingly, the network device is “net3”.

It could ping out of the box, telnet to external machines etc so the NAT setup of the VM is working fine.

Looks like I have solved the problem from my friend by using virtualization. Now can get go get a new machine and run RHEL 5.4 on it have his ancient SCO OpenServer 5.0.5 + applications run in perpetuity.