Latest FOG 0.33b
-
Working on a rewrite, currently, of the Post_Stage2.php. Apparently using FOGFTP is not correct.
-
Post_Stage2.php has been updated, slightly, to work with class files which ultimately means MUCH less code for easier management. Will work this same methodology to the other service files, but this one was my starting point, therefore the best chance I had at testing.
r1034 released to fix the Post_Stage2.php file itself.
Thank you,
-
r1035 fixed issue with system.php file and created the basepath/web_root information.
r1036 updates the TomElliott.config file to allow native VMWare disk recognition. (I love this part.)
I know the changes are coming fast, but it’s all worth it I think. My normal tarball is also updated to r1036 just so all are aware. I haven’t, yet, added my new kernel to the tftp folder during installation, but somehow I think it’s worth it.
-
I have corrected the issue with XP imaging. First part, it was generating a random Sector to start imaging to. This has been fixed. Another issue I was running into was the boot flag wasn’t being set, so I’ve corrected this. Due to this, I’m rebuilding the init.gz file and it will be inserted into the latest revision of fog once complete. I’ll post once this is done and tested.
This issue should be corrected now. The only issue I’ve yet to get a fix is the renaming, if the image already exists. It’s renaming the $mac address folder /images/dev/$mac/$mac.000, so during the creation of the actual image file it gets stored as:
/images/$imgname/$mac.000 instead of /images/$imgnameThat’ll be for later. For right now, the correct action is to move the $mac.000 file and rename it as the image name.
For example, if your image name is testxpimage
The system will be stored as: (Assuming a mac address of 00:01:02:03:04:05)
/image/testxpimage/000102030405.000Just move the folder as and move the image file (the .000) as such:
[code]mv /image/testxpimage /image/tmpfolder
mv /image/tmpfolder/000102030405.000 /image/testxpimage
rmdir /image/tmpfolder[/code] -
r1038 was released to fix init.gz script to properly deploy windows xp images. (YAY, THIS WORKS NOW…I’ve tested with a VM and all seems to work properly, please test to properly verify.)
r1039, forgot to add my new Functions.class.php file to the last revision, so it couldn’t checkout the task. This is corrected now.
My fog tarball has been corrected as well.
Thank you,
Sorry about all the fixes/issues lately. It’s a lot of testing writing, so simple variable names (which is the issue in this case) keep getting missed. Hopefully all is now good.
-
r1040 is released.
This fixes UDPSENDERPATH issue in the config.php file. Originally had it as UPDSENDERPATH (UP rather than UD) . Fixed the WEB_ROOT/WEBROOT issue in the FOGTaskScheduler file.
-
r1041 is released.
It should fix issue of Windows XP images, when created resizable, not being moved/renamed correctly. The current method (before this) just moved the /images/dev/$mac/$mac.000 to /images/$imgname as a folder containing: /images/$imgname/$mac.000 Which when trying to redeploy didn’t work so well as it couldn’t find the file name and start the deploy. Though not fully tested, this new method should send the osid, if it’s the xp osid, it will move the file inside /images/dev/$mac/ and rename that rather than the entire folder.
Hopefully all works as expected. This is similar to the old way XP resizable images were created. I don’t know if other methods work properly under this, but I’m guessing we could make it work now that I’m starting, I think, to get a hang of this all.
-
r1042 is released.
Tested the Post_Stage2.php file and it performs a check on the srcdd as well as the src origination schema (/images/dev/$mac/$mac.000) so it copies the file into the correct location now. All else should remain the same as before, but needed this check for Windows XP resizable images.
Will try deploy, but as I’ve, as far as I can tell, fixed the fog script to create the partition properly all should work well. Tarball updated to r1042 as well.
Thank you all,
-
r1043 is released with “true” Image deletion. If you delete the image from fog, it will delete the image from the file system as well. I will add checks and balances to make sure people intend to delete the image or not, but for right now it’s default to delete the image. If you don’t want to delete the actual files, just rename the original image to something like /images/image2 and recreate the file or directory (as you choose) to /images/image, then delete the image record from fog. Hopefully r1044 will add that questioning functionality to the file deletion part so we don’t have to do that.
-
r1044 is released. Basically, in Image deletion, now, there’s two buttons. One without “and File” and one with. You get the idea I think.
Lots of other files modified as well. Trying to get files more in line with one another.
Mainmenu now verifies if the user is ADMIN or MOBILE. If they’re mobile, they get the mobile buttons (Home, Host, Task, Logout) but with full functionality of those options. Will work on the Main files way down the road maybe to limit the functionality. This will serve as a kind of proof of concept for RBAC control functionality.
FOGFTP now has a function to check if a file/folder exist. (though in r1044 it only checks folder)
-
r1045 fixed a couple more found issues, namely tried addressing the checkexists files and folders.
r1046 fixes delimiter of the checkExists. My tarball is updated.
Merry Christmas Eve everybody, I’m going to sleep.
-
r1047 fixes ftp put in Post_Stage2.php
Basically, when it ASCII transfer’s the files, it corrupts the image upload data. Created rename function in FOGFTP.class.php and this seems to have fixed this issue. It’s also much faster as it’s not trying to copy the data, it’s actually moving the data.
-
I know I keep working on this, but “Why not?” I say. I’m currently implementing the Deploy Task functions. As I’m moving the functions I can’t figure out where else from the old style to the new Functions.class.php file, I’m starting to get the hang of some things. I was able to move the snapin tasks. Now I just need to figure out a means of checking if it’s a deploy/upload task that determines if snapins will be deployed after the image completes. It’ll be a little while I imagine. After that, to figure out deleting the task from the queue.
-
r1048 released.
It, now, properly creates snapin tasks. You can also remove the snapin task.
I’m still in the process of testing, but the Scheduler system should work as well. Hopefully you all enjoy.
-
Tested Scheduled Snapin tasks with both cron and delayed. All seems to be working properly. Hopefully this still goes for WOL, though my guess is I’ll have to do some of the same work with WOL tasks, though I guess if you’re WOL, you’re probably imaging as well.
-
All,
I’m moving my compression medium to xz rather than lzma. Though lzma seems to work rather well, xz is much better. The other part of my reasoning, is lzma doesn’t seem to maintain the same compression across different versions of itself. Meaning, if I compress the init.gz using lzma version 4.2 on one system, and uncompress it on lzma 4.9, it uncompresses fine. Recompressing it causes issues though for some, unknown to me, reason. For that reason, as far as I can tell, xz has maintained the same methods of recompression and does a very good job (better than lzma). I’ve included xz reading into my kernel file, which will be a must.
Please test and see how you like it. As alway’s, gzip compression is still available, and I’m keeping lzma available in the kernel as well, but I did add xz to the kernel parameters.
Please test the kernel, and for those of you on 0.33b, feel free to play with the init.gz:
[url]https://mastacontrola.com/fogboot/images/init.gz[/url] <-- goes in default location of /tftpboot/fog/images/init.gz
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url] <-- goes in default location of /tftpboot/fog/kernel/bzImage
I’m not adding these things into a new revision yet, as I’ve yet to hear back whether the kernel works on the Lenovo T440(s/p/etc…).
I’ve minimized my kernel, and it seems to me the configuration looks much more similar (all be it, seemingly, with more options – besides the newer features of the kernels since 2010) to the kitchensink kernel configuration. However, this kernel (I’ve tested), natively recognizes VMWare SCSI Drives (Win 7) and hopefully recognizes all different types of motherboard chipsets. If compressed with gzip, it seems to be about 13 MB, compressed with LZMA is just shy of 6 MB, and with XZ is a little more than 5.5 MB in size.
With this latest kernel configuration, I’ve also added RAID utilities to it. It should recognize hardware raid controllers, though I don’t know how to tell for sure as I don’t have another system with a hardware RAID system, for those of you trying to image servers or something of that sort.
Ultimately, I’m trying to assist in building a kernel that works across the board. I haven’t, quite yet, figured out a method of imaging LVM systems (the default filesystem layout for CentOS – and many more I’m sure) though my default debian install seems to image just fine (I think that has an LVM based file system as well.)
I hope you all are enjoying the latest and greatest I’m attempting to put out there.
-
r1049 re-added the fog.auto.del script into the init.gz file. There was a typo though, so this has been fixed in:
r1050 fixes the typo. Many of the service files have been updated to use class based things. I’ve tested a few elements, but can’t ensure all are working as expected. However, the amount of code is very much reduced. Doesn’t mean much now, but it means easier management later on down the road. Tarball has been updated to the latest revision as well.
Hopefully you guys like and enjoy. I’ve also, due to the fog.auto.del, made the dive into updating the init.gz with the xz compression method described above. The kernel has also been added to ensure all works properly out of the box.
Thank you all,
-
I’ve been thinking about resizable images… Since I’ve been having trouble getting them to work. (I have not yet tried the latest 0.33b yet, but aiming to do so very soon)
If Partclone could deploy a partition that is relatively small… only just bigger than the OS and installed apps. and then use a snap in to extend the drive via Diskpart within windows.
the only issue I;ve had so far is that if you start with a certain size HDD and try to deploy to a smaller HDD, even with a partition that is smaller than the new HDD, it will fail. (doing more tests at the moment, but disk IO is limited on my test suite.)
-
Vincent,
The issue, as I understand it, is that you’re having problems deploying an image created as Single Disk-Resizable/Multi-Part Non-Resizable, but using a machine that has a larger hard-drive than the systems you’re trying to image? What is the OS you’re referring to? I’m guessing Windows 7.
This isn’t, persay, a Partclone/Partimage issue, but rather a way the images are created.
In Multi-Part images, there are (typically) three files created during the imaging process. These are d1.mbr (Master Boot Record), d1p1.img (Partition 1) and d1p2.img (Partition 2). With this mode of imaging, you CANNOT image a system with a smaller disk than the “master” system no matter how hard you try. This is, in-part, due to how the imaging process creates the images. Usually speaking, images of this type don’t require you to sysprep, but even if you did, it wouldn’t matter because of the mbr file. Most Partitioning tables are stored within the MBR of the drive you’re trying to work with. This is why, if you image a drive larger than the drive you initially imaged with, the system only recognizes (initially) the original drive sizes.
What this means is, if you upload an image from a 160GB drive, and image a 320GB Drive, the 320GB drive system will, initially, look like it only has 160GB available to it. (until you look at the disk manager and extend the drive.)
Now, in retrospect, the partitioning tables won’t work for drives that are smaller. If you take that same image from the scenario above and try to image a system with only 80GB drive, the partitioning tables can’t write to the 160GB setup.
Resizeable images, on the other hand, don’t copy the MBR, and rather uses an MBR file located within the init.gz file on systems that, at the very least, the drive information has been removed, and therefore can recognize the drive independently.
With Windows XP images, the resizable images worked perfectly even without sysprepping because all that was copied was the boot information, not the partitioning schema. In Windows 7 (and I imagine up) the methods involved in generating an non-hard-drive specific MBR, actually requires a sysprep of the system. You can take the time to fix this issue with:
HKLM\System\MountedDevices\ and remove all entries except “Default” before uploading the image. Once complete, setup your image upload task then reboot the system and let the upload finish. Once complete, try deploying the image to another machine. Theoretically, all should work and the disk size shouldn’t matter if it’s larger or smaller than the original size, so long as the drive is larger than the image’s uncompressed size. Seeing as a simplistic base Windows 7 64 image is just larger than 10GB, you should be fine as most Hard drives are many times larger than this. This should keep out the evil Winload boot error, though I can’t guarantee that it will fix the boot issue itself.
However, I’d say it’s much easier, in the long run, just to sysprep/generalize the master system before upload. It might take a few extra minutes, but It will work much better from the tests I’ve performed.
-
I sysprep at the school where I work. not usually on my test systems.
Just setting up a new set of tests at the moment.
Will try one set without sysprep and one set with.
Might even create a few more VMs to test your new improvements with the SCSI drives in VMware
Currently the system I run at my school involves a Multi Partition image, created with the smallest drive we use. The only disadvantage is the larger systems don’t use all their HDD space. Easily solvable with Diskpart…
I’ve tried Resizable images once or twice on tests at work and it always seems to end up destroying the operating system and any system deployed from the image doesn’t boot.
Luckily we don’t have anywhere near 80gb of applications so we’re fine with that size image. (although it was annoying when a slightly different 80gb drive in one of our machines didn’t work with our 80gb image…)
