Building USB Booting FOS Image

[george1421]

Part 1

The idea for this solution is to build a usb bootable FOS client that will handle the basics of imaging from target registration, suitability checking, debugging, and image capture and deployment.

This solution is only mean to replace pxe booting where the target can’t pxe boot effectcivly or the network adapter is not supported by the firmware for pxe booting such as with uefi firmware and a usb 2.0 network adapter. The only caveat here is the network adapter MUST be supported by the FOS linux kernel. The usb bootable FOS client also should remove any incompatibilities we’ve seen with the iPXE kernel and and the hardware.

The USB FOS Client creation must be done on a linux computer. The operating system doesn’t matter much. What ever the FOG Server supports these instructions should work on. The only caveat here is that what ever operating system you use, the OS must use GRUB as the boot loader. I can say for both Centos and Ubuntu that grub is already installed and used.

The working solution for this solution is based on the work creating the FOSL (FOS Live) usb boot debugging tutorial https://forums.fogproject.org/topic/6532/usb-boot-target-device-into-fog-os-live-fosl-for-debugging and the support of Tom (senior developer) with his quick updates to the trunk build that tied all of the bits together nicely. That brings up the point that this FOS USB Boot drive will only work on/with trunk builds post r8050. If you have an older trunk build than 8050 you must update to get the supporting environment.

If you are interested in the development process of this product you can review this link: https://forums.fogproject.org/topic/7656/pxe-less-booting-fos-client-os

Now lets get down to business in Part 2

[george1421]

@sudburr To do some of this you will need to become versed in grub menu design. Some can be done in grub. The deploy image function in grub is not so easy, that requires the integration of iPXE menus (which we avoided by creating a usb based tool). You can get pretty close but with static grub menus (as apposed to dynamic iPXE menus when you pxe boot).

[sudburr]

Necro-bumping but I’m loving this solution; and as such I have feature requests.

I want two menus instead of the one. The first menu allows you to choose your FOG server from a list of options, clears the screen after your selection, then presents your existing menu as a second menu.

Next feature request, is a menu option to image directly without registering/rebooting.

Can these be done and how?

Orrrr, a prompt for user input prior to the existing menu that will be used to set myfogip .

[george1421]

@mwarner I really had to think about the answer to your task as to what is the right direction.

The 100% right answer is for when the iPXE guys are able to get the iPXE kernel to boot with the updated firmware that Apple has released. Then there will be no need for the USB drive. The MacPros will just PXE boot into the FOG iPXE menu. We are using the USB stick as only a stop-gap measure.

(Just me thinking out loud here) For FOG to backup a target computer the target computer’s OS must be stopped and the FOG linux (FOS) must be running on the target computer. So in “theory” if the MacPro was a uefi system, and you could create an at least 128MB partition formatted as FAT32, you could copy the contents of the usb drive to that partition. At this point all you would have to do is have the macpro boot from that partition. Once booted then FOG would take over.

It may be easier to just buy a handful of sandisk cruzer-fit install FOS on that and leave the fits plugged into the USB ports for when you need to image.

[mwarner]

@george1421 we are using FOG in a business environment (~120 employees), and a few of our users have Mac Pro’s. That’s why we were looking for this USB stick as a solution. But instead of having those two people relying on a USB stick, I was wondering if we could simply mount this .img as a partition on their device’s hard drive so it would be easier for them when they want to backup their device.

[george1421]

@mwarner and what do you need to do with it on a hard drive? Sorry I’m not seeing the intended use you are planning.

[mwarner]

@george1421 the .img file that your script generates (found in /tmp/fos-usb.img according to your script)

[george1421]

@mwarner said in Building USB Booting FOS Image:

mount this on the partition of a hard drive? Or would that likely mess something up

Please define ‘this’

[mwarner]

I just performed a capture and deploy and it worked flawlessly. Again, thank you so much.

I do have one question: would it be possible to mount this on the partition of a hard drive? Or would that likely mess something up?

[mwarner]

@george1421 Yep, that’s exactly what was happening. I changed it and ran a full host registration successfully. I will try an image capture next.

[george1421]

@mwarner that is probably the root of your issue if it tries 3 times to get dhcp, acts like it gets dhcp and then tries again. FOS does a web call to the FOG server to see if its up. It uses that call to identify if the network is working or not.

[mwarner]

@george1421 I did not change the $myfogip variable in the script, so I will snap a picture if changing that does not work.

[george1421]

@mwarner Can you provide an example of the troubles? A picture snapped with a mobile phone is helpful to tell the context of the error.

[mwarner]

Thank you for this guide! Your script works very well - a lot better than cloning the (much older and more obscure) mac-boot Github repo. We ran into an issue with DHCP leasing but it’s certainly a lot farther than we got with previous attempts on our test Mac.

[george1421]

@george1421 Bump…

Can I bump my own thread??

[Wayne Workman]

@george1421 do you want wiki access so you can start putting this stuff in there yourself?

[george1421]

@aplaisted Great catch on the single quotes, I’ll update the script.

[aplaisted]

Thanks for putting this together. It’s a lot less kludgy than the boot drive’s I’d made for clients that don’t support pxe boot. I did run into one tiny issue with your script. I’m running centos 7, but this shoud apply to anyone running bash. The
cat > /mnt/boot/grub2/grub.cfg << EOF command will evaluate all of the variables in the grub script instead of writing them out literally. Putting single quotes around the EOF will tell it not to evaluate anything.

cat > /mnt/boot/grub2/grub.cfg << 'EOF'

Other wise all of the variables in the grub script are written out as empty strings.

[george1421]

@Wayne-Workman Not just yet since that article is the path how we got here. Maybe once this method is accepted then the other one is not relevant any more.

[Wayne Workman]

#wiki worthy

George, do you want to scrap the “usb bootable media” article in the wiki for this or… what? Is this a separate thing? Up to you, it’s all your work.