Mac Linux USB Loader version 2.0

This consumer preview release includes loads of new features including:

1. Enterprise, my new UEFI boot loader that is far more customizable. You can view more information here.
2. Updates to localizations. Added a traditional Chinese localization (done by a third party user) and updated Spanish localization. For credits for localizations, see this file.
3. Big fixes and other changes.

If you want to download it, you can get it here. Please note that this is still beta, so it may be buggy. You can also email me if you have problems.

A Sneak Preview of Enterprise

So, after a long, hard month of serious development (before this was a rather lackluster and on-and-off effort) I am pleased to show some screenshots of Enterprise, my custom UEFI boot manager program that I wrote about at length in this post. However, there are some (small) details that are different in the plan versus the implementation, and that's of course because I've found a better way to do things. So, here's are some screenshots, as promised, with comments:

This screen (which may receive minor tweaking) allows the user to select one of two basic options: starting the Linux distribution immediately or, in case there's issues with the video card, etc, to customize Linux kernel boot options.

This is what the boot options screen that I just mentioned looks like. You can toggle a variety of boot options (up to 9 is supported with this approach) that have a variety of functions. Some of them make troubleshooting easier, while others facilitate installing Linux to your Mac. I plan on adding more before the final release. Please note that not all options are supported by all distributions.

Love it? Hate it? Have suggestions? Drop me a line. I'm shooting for a release date of the 30th of November and I'd love to get some feedback.

Enterprise Developing is Rolling...

I am happy to announce that, after a long interim, development on Enterprise is going full speed ahead. Hopefully, there won't be any more long delays in development. I know that this is a much-needed program, due to many bug reports detailing the flaws with Mac Linux USB Loader's current firmware solution, and so hopefully it should be in a somewhat beta-testable state soon.

What's currently working is the initial menu and the kernel boot options configuration panel (from where, you'll be able to add options like nomodeset and acpi=off to the kernel boot procedure).

What still needs to be done is processing Enterprise's configuration file - currently it checks for the existence of such a file, but doesn't read its content - it could contain song lyrics for all it mattered - and passing everything to GRUB, which will load Linux from the supplied ISO file like at present.

Screenshots will be coming soon, but will take some setup to capture, as Enterprise runs before any operating system, and thus any potential for screen capturing.

Implementation Details of Enterprise, my Custom UEFI Booting Solution for Linux on Intel Macs

My repository on GitHub holding the source code for my program Enterprise is currently sparse on commits - no updates in over a month. But before you accost me for being lazy, listen up, for I have not been lazy, nor has the project been abandoned. I simply have been using this time to figure out exactly how I'm going to implement the program instead of simply throwing code together like before.

So, what do I have in mind? Well, listen up.

My booting solution for booting Linux distributions via EFI is a three-stage loading process, involving (at least) three files instead of the present two (two EFI executables and one ISO file of your preferred Linux distribution). These programs will be executed in sequential order. This works out as follows:

1. The user boots into the USB drive made by Mac Linux USB Loader. Enterprise will then perform some hardware checks to ensure that you actually booted on a Mac. It will then display a menu similar to those found in gummiboot or GRUB. I'm looking at rather basic options at this point - the options will be to boot normally, boot with certain options (like no graphical X desktop and/or disabling kernel mode setting), or reloading and/or dropping into an EFI shell.
2. If the user chooses to boot the operating system, we then write out a configuring file detailing exactly what is needed to boot Linux on the current hardware. Then we pass control off to GRUB, which is another EFI executable in the same directory. GRUB reads this configuration file and boots the Linux distribution included in the installed ISO file.
3. GRUB loads the kernel and RamDisk from the ISO using loopback. Together the kernel starts up the remainder of the operating system.

This approach will ultimately yield itself to be a more viable alternative to the current solution, which works with hard coded kernel locations inside of the ISO (however, loopback support will still be required, as this is required for GRUB to boot from the ISO file - there isn't really any way around this). Additionally, it will allow me to add support for more distributions with relative simplicity.

For those of you who want to see the directory structure, here's what it will look like:

I know many of you have been waiting very patiently for a solution. Tails, Knoppix, Backtrack, and Arch Linux are all distributions that I've been requested to support. I assure you that I am working as fast as I can to get these distributions working with Mac Linux USB Loader. I have no idea when this solution will be ready for beta testing, but everything should be on track now.

What do you think of this setup? Comment below. If you prefer to communicate via email, I can be reached here.

How to Code UNIX Daemons - Part One

In continuing with my time-honored tradition in bringing you the absolute latest in small code samples, here's an example of how to write a UNIX daemon. For the unfamiliar, daemons are background backgrounds that are typically started when the system starts up and have one specific task - typically ranging from serving web pages (the Apache web server, https, is a daemon, as is sshd, which listens for ssh requests on remote servers you can ssh into).

So, without further ado, here's the code sample:

 #include <unistd.h>  
 #include <fcntl.h>  
 #include <stdlib.h>  
 #include <string.h>  
 #include <stdio.h>  
 #include <syslog.h>  
 #include <sys/types.h>  
 #include <sys/stat.h>  
 int main(int argc, char *argv[]) {  
   // Set our uid to root so we get root permissions.  
   setuid(0);  
   // Fork off.  
   pid_t pid;  
   int current_arg = 0;  
   pid = fork();  
   if (pid < 0) {  
     exit(EXIT_FAILURE);  
   }  
   if (pid > 0) {  
     exit(EXIT_SUCCESS);  
   }  
   umask(0);  
   // Open a syslog so we can post messages, as daemons shouldn't access  
   // stdout.  
   openlog(argv[current_arg], LOG_NOWAIT|LOG_PID, LOG_USER);  
   syslog(LOG_NOTICE, "Successfully started daemon\n");  
   // Create a new process group.  
   pid_t sid;  
   sid = setsid();  
   if (sid < 0) {  
     syslog(LOG_ERR, "Could not create process group\n");  
     exit(EXIT_FAILURE);  
   }  
   // Set our working directory to / so we know where we're writing files  
   // from. Also good practice.  
   if ((chdir("/")) < 0) {  
     syslog(LOG_ERR, "Could not change working directory to /\n");  
     exit(EXIT_FAILURE);  
   }  
   // Close the standard streams like stdout so we're not attached to the  
   // console (and thus killable with Control-C).  
   close(STDIN_FILENO);  
   close(STDOUT_FILENO);  
   close(STDERR_FILENO);  
   // Now mimic some daemon activity. A real daemon would actually do  
   // something here, such as monitor CPU temperature or something...  
   do {  
     syslog(LOG_NOTICE, "Sending a message\n");  
     sleep(10);  
   } while (1);  
   // Close our access to the syslog.  
   closelog();  
 }  

Put this into a text file, and then compile it with your C compiler. You then go into the terminal, run your program, and… it exits immediately - what gives?

The truth is, something did happen - you just don't notice. Thanks to our fork() call, we split off from the main process and run in the background.

In the second part of this series, we'll write a more complicated daemon program. See you later!