Oh, if you’ve downloaded a buildroot package, don’t forget to copy in the trunk/src/buildroot directory so all packages are ready. The config will need to be set from the fog.buildroot.config file.
Posts made by Tom Elliott
-
RE: 64 Bit Stuff
-
RE: Latest FOG 0.33b
If that works, it’s an unexpected quirk. It’s awesome none-the-less, but I’m a little worried about what affect the MBR is having on the smaller drives. Does the original size still hang in the balance on both smaller and larger drives?
-
RE: Maintenance - December 28th
With this change, did the database that keeps track of who’s registered to send notification get wiped? I only ask because now the fog login pages state: Estimated FOG sites: No database selected.
Thank you,
-
RE: Latest FOG 0.33b
Vincent,
The only problem with sysprep, unless rearmed, is you can only perform a sysprep up to 3 times. As you state you work at a school, I’m under the assumption, please correct me if I’m wrong, you work similar to the way my workplace does it. We create a base image that has all the necessary software all schools within our district need. (In your case I’m assuming this is one sysprep – unless there was something wrong with this and there were multiple other syspreps performed.) However, the way this base is created is probably using the manufacturer disc for OS install and chances are you don’t use Audit mode? This is technically another sysprep which Already means, theoretically, you’re at two syspreps for the Base image (Unless, again, somebody else sysprepped another time).
This means it only leaves you with one more sysprep before you’ve even been able to create your image for your school.
The way we create images at our school is we create, what I like to call, the Super Base. This is the base with all common software(s) installed on the system between all of the schools. Then we create the Base image for the school the image is going to be in place for, as these software needs change from High School/Middle School/Elementary School.
We don’t sysprep, yet, where we work, but we also aren’t using drives smaller than our initial image. I’ll look into testing some new commands to see if we have to sysprep a resizable image for Windows 7. This way, I’ll know whether or not it’s even possible. There’s a command I’ve been waiting to play with called partclone.ntfsfixboot that I imagine may do the trick for us. As far as extending systems with larger drives than the image was created on, I’m going to leave that up to the individual to fix/or not fix for now.
I know I’d love to be able to create a resizable, non-sysprepped, image for Windows 7, and maybe even Windows 8 as needed. (though I’m still waiting for Windows 8 to come in.)
-
RE: Latest FOG 0.33b
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.
-
RE: Latest FOG 0.33b
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,
-
RE: Unable to upload file.
That’s because of the two methods in use.
Tftp doesn’t use relative paths to locate the files, but the kernel and boot image consider the actual tftpboot directory (on it’s own) as the root of the file system. They’re not relative technically.
-
RE: Unable to upload file.
The upload of the file by means of ftp is not using receiving files in /images.
The location the file needs to write the task to is at: /tftpboot/pxelinux.cfg/
The reason anything can read/write to the /images directory is it’s default ownership permissions are 777 or in lehman’s it has full read, write, execute to everybody.
Check your fog settings FOG_TFTP_FTP_USERNAME and FOG_TFTP_FTP_PASSWORD are set correctly for your server. Also verify that FOG_TFTP_HOST and FOG_TFTP_PXE_CONFIG_DIR are correct as well.
The upload error it’s giving you during task creation is that it can’t send the server the pxe file generated for the task. Because this is using the PXE settings, these should be the only fields you have to worry about.
Hopefully this helps.
-
RE: Latest FOG 0.33b
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.
-
RE: Lenovo Thinkpad x240
If you used kitchen sink I can get it and see the major differences. Just try my kernel and let me know if it works. If not I’ll compare the two configs.
-
RE: Lenovo Thinkpad x240
Okay, so if I understand properly you used the fedora config?
-
RE: Lenovo Thinkpad x240
Chris, can you post the config file. It should be located in the root of the Linux directory with filename .config (notice the period in front.)
-
RE: Fujitsu Primergy TX150S8 Server - Hard Disk not found
I’ll build a kernel with raid controllers built in and let you know when its ready for download
-
RE: Latest FOG 0.33b
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.
-
RE: Latest FOG 0.33b
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.
-
RE: Latest FOG 0.33b
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.
-
RE: PXE Boot Error - Disk Drive not found
I know this thread is slightly older, but my latest of kernels seems to work with VMWare, and many others I’m sure, SCSI natively. No more having to change to Paravirtualized or anything to upload the image, to reset to the one windows needed to operate properly. Hopefully this helps. It should come with FOG 0.33b and if you’re not feeling good about going down the beta road, try downloading the latest one at: [url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]
-
RE: Latest FOG 0.33b
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.
-
RE: Kernel panic - not syncing attempted to kill the idle task
I’d recommend maybe trying my kernel:
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]
I’ve added a whole bunch of stuff dealing with VM’s. It looks like the rand number generator is causing your issue, so hopefully mine will work.
-
RE: Latest FOG 0.33b
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.