Offline USB Imaging example



  • Attached is an archive of the customizations I did for offline USB imaging:

    s99cd from initrd was edited to strip out most network requirements, and to mount the USB stick read-only at /dev/sdb1 to /storage. (This can probably be better accomplished through a new boot option and kernel boot variables)

    In cd_global_functions, mount_smb() was changed to find the the image located at /storage/images

    In cd_push:
    A preflight script was used to either find the computer name from a .csv of serials and asset numbers, or to pop up the standard CloneDeploy "please choose a name" prompt.
    $hd_schema was changed from the curl access to a simple cat of a schema.json file, pulled from a log from a successful normal image run.
    $PartLayout was also pulled out of the log to its own file, and modified to fill the drive to the max with the last partition rather than have a set end.
    in download_image(), cat is used to pipe files to $partCompAlg, and then into partclone. $partCompExt is called as "$partCompExt*", which alphabetically concatenates any files matching that pattern, as spit out by the linux split command (filename.lz4aa, filename.lz4ab, etc). Works even for unsplit files (filename.lz4).

    Hopefully you can skim through the code and my changes are immediately apparent. There is a lot of outright gutting and commenting out — this wasn't meant for publishing 🙂

    What I envision from a "Prepare for Offline Deployment" option:
    1: Detect which is dev entry is usb drive vs. main drive
    2: Mount usb drive rw, create image folder
    3: Stage a mock deployment to get the hd_schema and PartLayout information, add to image folder
    4: Download image files, running >4GB files through split
    5: Add new boot option to grub.cfg with kernel variable signaling to s99cd within initrd to do offline mode, probably with specific usb dev entry as a variable

    Let me know what you think. What I've outlined works great for EFI booting and block imaging, while ignoring other strategies. BIOS support should be trivial. But file-copy and WinPE may be entirely different balls of wax...



  • Thanks, I believe it should be fairly easy to implement this. The biggest issue I can think of is still the partitioning. If the drives are are the same size there would be no issue. Otherwise the partition script wouldn't match. If the image is just a standard Windows layout, then it would be simple to just lay it down, otherwise without contacting the server, I'm not quite sure how to adjust the partition script, yet.

    As far as creating the image for offline I see two possibilities.
    1.) What you suggested could work, the problem is that many people use VM's to create images and not all support usb passthrough

    2.) The other option, which I am leaning towards, is still to upload to the server, but with everything needed to build a usb for offline deployment. Then it can stay there and be copied to usb whenever needed. Obviously networking would be needed to upload images but not deploy.

    Any thoughts? I'm thinking this could be something that could fit for a 1.4.0 release



  • [quote=3232:@clonedeploy]As far as creating the image for offline I see two possibilities.
    1.) What you suggested could work, the problem is that many people use VM's to create images and not all support usb passthrough
    2.) The other option, which I am leaning towards, is still to upload to the server, but with everything needed to build a usb for offline deployment. Then it can stay there and be copied to usb whenever needed. Obviously networking would be needed to upload images but not deploy.
    Any thoughts? I'm thinking this could be something that could fit for a 1.4.0 release[/quote]

    Oh, I think I wasn't totally clear. I was envisioning first uploading the image to the CloneDeploy server like normal, and then on a prospective target device, run the "Prepare for Offline Deployment" workflow while connected to the network.
    The necessary information (hd schema, partitions, image data) would then be downloaded from the CloneDeploy server to the USB drive.
    This would allow the CloneDeploy server to continue to contain and deliver all logic for partitioning.

    Does that make more sense?



  • Yes that makes sense. I'm still going to think about this some more. With your idea is the usb made bootable ahead of time, or are you just copying the files to the usb to be used later to create a bootable usb.



  • My idea is that the USB device is made bootable through the current set of instructions, and later, the offline preparation step is what copies the image/schema files to the USB device (and modifies its boot options).



  • Sounds good, I think that only leaves the partition problem. If you made the offline usb from a computer with a 500GB hard drive and then ran it against one with a 1TB hard drive, it would only end up being a 500GB hard drive. As you stated if the last partition is the Windows partition we could just extend to the end, but if it's not the Windows partition, this wouldn't work, many times the recovery partition is last. I'm sure it will work itself out once I start doing it.