USB bootable image for WiFi imaging.
I want to create a USB image that can be burned onto a USB Device (with something like Rufus) that will enable imaging over WiFi.
I’m told by Tom that iPXE can pass a SSID and password with kernel arguments, and that the wifi device can be started.
There should be easily editable fields in a configuration file somewhere where the FOG Server’s address can be specified, along with SSID and Password.
I suggested creating kernels just for WiFi use. They would have the WiFi drivers included, and be included on the USB image. Tom has said he would want to create 32 bit and 64 bit kernels for wifi use, just as there are 32 and 64 bit kernels for wired use.
I feel this is really vital. While I would always recommend that people should get a USB to Ethernet adapter for the increased performance and simplicity, a USB bootable device that would enable imaging over WiFi would ultimately provide an imaging answer for more devices.
I have no clue where to start with this, but I feel like George is really close already with all the work he’s done with making USB bootable drives for FOG.
Let’s get this working with WiFi.
@Wayne-Workman I’d definitely go with George’s suggestion and skip iPXE entirely if booting from a USB stick anyway. This way you can skip on part that might cause head aches along the way. On the other hand you cannot use iPXE configuration (loaded via HTTP) from the FOG server then. You’d need static parameters configured right on the USB stick - possibly have several entries for different taskings.
@george1421 Thanks George. That’s a lot more clear than what I was finding.
@Wayne-Workman OK, lets take a hacker approach here (this is more of a concept than an action). Also I’m not going to give you answers only places to look. If I told you to do this, click that you would only be parroting my instructions and not learning.
Also understand my kernel knowledge is about 10 years old. I’m sure almost everything applies still today.
First of all, you will need to load the kernel development tools for your linux platform. There should be an installation package group for kernel development. Go ahead and install that on your test system.
Once that’s installed we need to do a little reverse engineering. First you need to see how Tom builds his kernels. Not knowing Tom (hacker principals), so you can’t ask questions you’ll have to research a bit. The first thing you will want to do is see if you can (precisely) duplicate his work. For that you need to look at a current bzImage file. Run the
filecommand to find out what linux kernel he used.
Knowing this (assuming he hasn’t messed with the version number because its totally possible) goto kernel.org and download that same linux kernel version. That archive file typically should be expanded to something like /usr/src/kernels.
Now once that kernel has been extracted, you’ll find out you need a config file that sets all of the options to build the kernel. (what you want to do here is to duplicate what Tom does when he builds the kernels). I’m sure if you poke around the fog project github you will find some TomElliott.config files. This should be just a huge text file with a bunch of Y and N settings with a few M scattered about. You will need to copy that to the proper location and probably need to rename it to the proper name. Right now there is no way to know if Tom has patched this official kernel.org kernel, so we have to assume no.
Once you have all of the bits in place, with the kernel dev tools installed all you should have to do is issue a
make allcommand to build the kernel from the source. With any luck the compiler will compile the kernel without error. If the compiler ends without error, the built kernel should be in… that linux source path somewhere in/below boot. What you want to do is see if the compiled kernel is relatively close in size to what Tom makes. If its close then upload that to your dev FOG server and see if it boots.
Once you have a working build environment then you can start experimenting with that config file removing unwanted drivers and adding in the ones you want to deploy. There is a C code header file that contains the kernel version, you might want to update the minor version with something like -WW or what ever so when someone lists out the kernel version you can tell is a WW special.
I might be concerned about bandwidth for imaging. You have to remember that wifi is a shared medium.
This is a concern, but it’s not our concern. It’s the concern of the person doing the imaging.
That said, we can make recommendations. Personally, I’d set up an 802.11ac AP that would be just for fog, and set my storage node’s maximum active tasks to 1, and I’d only have one device booted at a time, with nothing else connected to that AP. That’s just one way, there are others.
How would I get started with this? I’ve never built a kernel before. Never fabricated a custom boot image. I’m a newbie to those things.
Just thinking out loud here…
One could use the FOS Live (FOSL) boot concept. Use grub as the ipxe menu replacement. You have a decision if you want to support only 64 bit or both 64/32 bit. I might suggest that you just focus on 64 bit since I think your goal/focus here is for new and emerging tablets. If you look at the ipxe menu created by the boot.php script there isn’t a lot of dynamic content. The ip address of the fog server and the SSID info would be the most dynamic. You would not need pxe at all in this concept. I might be concerned about bandwidth for imaging. You have to remember that wifi is a shared medium. Multicasting might be a solution here, but again I do have reservations and suspect that it just won’t work over wifi. If you are using using a GbE network you have a potential bandwidth of 1000Mb/s with 802.11g you have a theoretical max of 54Mb/s. 802.11n has a max of 600Mb/s. If you use 802.11ac then for a single channel you can get up to 870Mb/s closer to GbE speeds but still a shared connection.
The bzImage and int files will be delivered on usb to boot. As long as you had the required wireless drivers in the kernel as passed the required settings as kernel boot parameters it might work well.