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).
Posts made by TylerL
RE: Offline USB Imaging example
[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?
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
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...
Secure Boot and EFI over PXE?
Hello, we've been using CloneDeploy with great success in our school district since summer. Thanks for this great tool!
We use USB sticks to initiate CloneDeploy's standard linux block imaging, keeping our devices in UEFI Secure Boot mode.
We're now attempting to use PXE booting (via Proxy DHCP) to eliminate the need for physical USB sticks, but receive an "ACCESS DENIED" error after the pxeboot.0 file is transferred. Switching devices to legacy mode and using plain old pxelinux will boot just fine, but obviously adds extra steps pre- and post-imaging.
Moreover, disabling Secure Boot while leaving UEFI on will allow the pxeboot.0 to run, but brings the computer to the GNU GRUB rescue shell, rather than the normal CloneDeploy Grub menu we're accustomed to from the USB sticks.
I've tried messing with some of the files in /tftpboot and replaced pxeboot.0 with the USB stick's bootx64.efi, which seems to move on beyond the Secure Boot step (but then immediately fails for some other reason). Could it be that pxeboot.0 is not properly signed in the same way like bootx64.efi is? Or other critical files are not loading during the PXE/TFTP steps?
The CloneDeploy documentation (http://clonedeploy.org/docs/imaging-environments/) states that Secure Boot (and therefore EFI) is supported when Proxy Efi64 PXE Mode is set to grub (which ours is).
I tried searching for any chatter from other users, but haven't found an instance of someone using EFI Grub PXE with Secure Boot either on or off.
Is there anything I'm missing?
Thanks for any insight!
RE: Login problem after installation
Same problem here. I was really hoping to use this software...
I followed the steps on the "Install On Ubuntu" page to the letter. (http://clonedeploy.org/docs/install-on-ubuntu/)
Navigating to http://ipaddress/clonedeploy after a fresh install leads to the login.aspx page rather than initial setup.
Going directly to the firstrun.aspx script simply redirects to the login.aspx page.
Since I never had the chance to enter any credentials, I cannot log in.
1.1.0 on Ubuntu 16.04
1.1.1 on Ubuntu 16.04
1.1.0 on Ubuntu 14.04
1.0.1 on Ubuntu 14.04
All respond in exactly the same manner.
Is there a way to manually set user credentials to bypass this problem?