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.

QED.

 

Being part of Community Architecture

It is time to tell the world that I have the distinct pleasure to become part of the Community Architecture team within Red Hat. This is indeed both an exciting as well as a deeply challenging opportunity.  Exciting because it means I get to continue to engage with some of the brightest minds within Red Hat who are chartered to think about how the FOSS community has to be kept alive and well. A thriving FOSS community will help continue the amazingly rapid innovation that happens which Red Hat can then bring to enterprises.  Red Hat bringing the innovations from the community to enterprises ensures that everyone wins by added engineering and QA/QE that is added so that deploying FOSS in mission critical systems become a no-brainer. Equally important, the investments by Red Hat on the additional QA/QE flows back out to the FOSS community.  All of this is the core of what has come to be termed, The Open Source Way.

I have a lot of ideas as does the team. We need to build a thriving community of FOSS contributors in Asia Pacific (APAC in short).  For too long, APAC has been a net consumer of FOSS and contributors are few and far between.  I am hoping that with the added focus I now can bring to this space on a full-time basis, that the number of people contributing code, documentation, testing, new ideas etc from APAC countries will see an increase. It has always been my belief that smart people are evenly distributed around the world.  Why we see pockets of contributors is largely a function of connectivity and opportunity.  With the connectivity equation becoming moot, we need to foster opportunity.  For that, I am gung ho and ready to make the plunge.

My initial target group will be the Fedora, JBoss and DeltaCloud communities. Onward ho!

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:

  sco-openserver-5.0.5
  447d29e3-7891-bb76-385c-82d38e43e739
  524288
  524288
  1

    hvm

  destroy
  restart
  restart

    /usr/bin/qemu

[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.

Minor issue with NetworkManager and Fedora 12

Just solved a problem on my Fedora 12 32-bit machine (Acer Aspire One D250). For some reason, the nm-applet is not starting when I log into the desktop. When I start a terminal and fire up nm-applet as a normal user, I get the following error:

[user@machine ~]$ nm-applet

** (nm-applet:7050): WARNING **:  request_name(): Could not
 acquire the NetworkManagerUserSettings service.
  Error: (9) Connection  ":1.372" is not allowed to own the service 
"org.freedesktop.NetworkManagerUserSettings" due to security policies
in the confuguration file

But, when I substitute user as root (su -), I can start it and all’s well. Not a happy situation.

Did some checking and got a hint from – http://bbs.archlinux.org/viewtopic.php?id=63576.

So, what I have done is the following. In etc/dbus-1/system.d/nm-applet.conf, I had to add the
following for my userid:

I am using the “user” setting and not a group as suggested in the URL above as I do not want to create a non-standard group for this purpose. Suffice that my immediate problem is solved.

On the Fedora 12 machine that is experiencing this issue, policykit is as follows:

$ rpm -qa|grep polkit
polkit-0.95-0.git20090913.6.fc12.i686
polkit-gnome-0.95-0.git20090913.3.fc12.i686
polkit-desktop-policy-0.95-0.git20090913.3.fc12.noarch

On another Fedora 12 machine that all’s well policykit is as follows:

$ rpm -qa|grep polkit
polkit-0.95-0.git20090913.3.fc12.i686
polkit-gnome-0.95-0.git20090913.6.fc12.i686
polkit-desktop-policy-0.95-0.git20090913.3.fc12.noarch

Posted this to BZ 549253.

Automatically connecting to the Wireless@SG hotspots

Thanks to a caustic comment some years ago to Lee Kuan Yew by some visitors to Singapore, we have a nation-wide free wifi network called “Wireless@SG”. It has been a constant pain to use and after much ridicule, someone, somewhere has decided to do the Right Thing (TM).

So, what was the problem? Well, when you come across a Wireless@SG hotspot, you have to log in via a browser before you can continue. Yes, you have to provide a username and password (yes, “someone” wants to track you). Move away from that hotspot to another Wireless@SG node, you have to log in again. No mobility. Wireless is about mobility. The people at IDA claim that they are constrained by “security requirements” from the Ministry of Home Affairs. On the other hand, the MHA folks I spoke with say otherwise. So, who dropped the ball? Whatever it is, we have wasted a tonne of tax-payer monies to run the Wireless@SG system for the last few years. There has not been a single report of the service levels of Wireless@SG and how IDA is accounting for the monies spent. I have no issue with providing a quality service using tax dollars. But to provide something that is annoying to use and having no public accountability is plain wrong.

Wireless@SG is still there and there appears to be some people using it. Most of them are NOT mobile – they tend to be seated at some fast food restaurant or coffee place etc.

Now, fast forward to 2010, it looks like the IDA has finally gotten around to make the Wireless@SG truly mobile. Why it took years, I cannot answer. Perhaps some boardroom battles had to be fought, who knows! Someone want to snitch? Post it anonymously if you must.

OK, so we now have proper mobility. Let’s look at the site that discusses this.

First, it suggests that you go to http://www.infocomm123.sg/wireless_at_sg/ssa#connect and gives you two options to connect – one via a piece of software (closed source) to connect your devices. Interestingly, they only list:

Supported Operating Systems
	- iPhone
	- Windows Mobile 6.1 and above
	- Windows XP/Vista/7
	- Mac OS 10.5 and above

as the supported OSes. No Fedora? Why?

Nevermind that. Let’s look at the 2nd option – the manual way of doing this.

Supported Operating Systems
	- iPhone
	- Windows Mobile 6.1 and above
	- Symbian S60 Windows XP/Vista/7
	- Mac OS 10.4 and above 
	- Blackberry OS 
	- Android 1.6 and above

again, no Fedora? They have Android so, how difficult is it to enable Fedora on it?

OK, let’s explore further. I had an account with iCellWireless and choosing thier column entry on Android, I get to see Android configuration document.

The information is trivial. This is all you need to do:

	- Network SSID: Wireless@SGx
	- Security: WPA Enterprise
	- EAP Type: PEAP
	- Sub Type: PEAPv0/MSCHAPv2

and then put in your Wireless@SG username@domain and password. I could not remember my iCell id (I have not used it for a long time) so I created a new one – sgatwireless@icellwireless.net. They needed me to provide my cellphone number to SMS the password. Why do they not provide a web site to retrieve the password?

Now from the info above, you can set this up on a Fedora machine (would be the same for Red Hat Enterprise Linux, Ubuntu, SuSE etc) as well as any other modern operating system.

Now that we have solved the single sign on problem with Wireless@SG, I want statistics on usage, support problems, etc etc etc.

Fonera 2.0n finally!

Finally vpost delivers the Fonera 2.0n I ordered online. Earlier this week, I was suprised to receive a letter (yes, paper mail) from SingPost that my Fon was being held at Singapore Customs pending approval to import from IDA. The letter had the names of the IDA folks to contact. I sent them an email and they came back promptly that they are OK with the device. I sent a PDFed copy of the letter to the IDA officer, who printed it out, stamped it saying that there are no objections, and PDFed it back. Thankfully I had cc’ed SingPost during all the correspondance, and viola, I get an email from SingPost that the delivery will be sent to my house. Wow! All done by email, PDFs and with litterally zero hassle. I do hope that SingPost would be able to check with IDA on these devices beforehand to see if there are any issues before going through the paces, but, as in any good story, the ending is happy.

Now I am a happy owner of a brand new Fonera 2.0n and I can now deploy at home. Welcome, 2010!