No,
Upload is creating the image and placing it on the server.
Download is placing the image onto the system intended.
Upload -> Deploy from client to server
Download -> Deploy from server to client
No,
Upload is creating the image and placing it on the server.
Download is placing the image onto the system intended.
Upload -> Deploy from client to server
Download -> Deploy from server to client
Can you run in upload debug and run this line from the FOG init.gz file?
[code]fdisk -l | grep /dev/sda2 | awk ‘{print $3}’ [/code]
It sounds like the -a opt part of parted doesn’t like doing this for Windows XP partitions.
[COLOR=#000000]fdisk -l | grep $part | awk '{print $3}'fdisk -l | grep $part | awk ‘{print $3}’[/COLOR]
Why doesn’t it boot anymore? Maybe the drive is bad?
This is plenty possible.
First things first, I’d recommend making an exact replica of the database information with:
[code]mysqldump -u root -p[root_password] fog > fog_db.sql[/code]
If you don’t have a password on the mysql server then:
[code]mysqldump -u root fog > fog_db.sql[/code]
I’d keep the other fog server running just for a little bit. Get the second one up and running. Then use rsync, or scp to copy the data from /images to the new server.
First, you’d want to install the new FOG Server information as you normally would, replacing server ip (recommended only) with the old IP address just for use later on.
Then, run the scp or rsync command from the old FOG server, with something like:
[code]scp -r /images/* <NEWFOGIP>:/images[/code]
Copy that fog_db.sql file to the new server in similar fashion.
[code]scp fog_db.sql <NEWFOGIP>:~/[/code]
Then on the new FOG Server you’ll run:
[code]mysql -u root fog < ~/fog_db.sql[/code]
If you set the password use:
[code]mysql -u root -p[PASSWORD] fog < ~/fog_db.sql[/code]
Then the final step, shutdown the old server, and set the old server’s IP address on the new fog server. You should be good to go. You may have to reboot your new fog system to, just to ensure apache/ftp/etc… get updated with the new IP address.
Partimage wasn’t very good at translating free space, though in some cases it was accurate, many times, if you had terabytes worth of data, it wouldn’t work properly.
Looking at the access log, it looks like it’s trying to send the data, properly, to Post_Stage2.php
This line is what worries me:
[code]GET /fog/service/Post_Stage2.php?to=prova&mac=00:1b:78:84:bd:7a&ftp=&size=&imgid=4&imgtype=mps HTTP/1.1" 302 697 “-” “Wget”[/code]
Not so much the line itself, but it feels like it can’t move the image file from /images/dev to /images/prova.
It keeps repeating this line so it continues to try to perform the move. Have the permissions on the /images directory changed? The permissions are typically chmod -R 777 /images, but if it’s changed to 755, or 655, you’ll likely need to add apache:apache to the owner so the files can be written through php.
I’d start by verifying and setting permissions to:
[code] chmod -R 777 [/code] and if it’s permissions, you’ll see the task clean up.
I’d recommend, performing upload - debug mode in your case.
I’m assuming you’re running FOG 0.32, in which case, the upload commands for your system would be:
Assuming your doing a multi-partition image:
[code]mkdir /images
mount -o nolock,proto=tcp <IP.OF.FOG.SERVER>:/images/dev/ /images
mkdir /images/{temporarynameofimageupload}
mkfifo /tmp/pigz1
pigz -p 1 -3 < /tmp/pigz1 > /images/{temporarynameofimageupload}/sys.img.000 &
partimage save /dev/sda2 /tmp/pigz1 -V9900000000 -z0 -o -d -f3 -b 2>/tmp/status.fog[/code]
Download, you should be set. Though I’d recommend, performing the testdisk MBR fix and then reupload the image to the server using regular means.
Once you’re complete with the image upload process, log in to your FOG Server as root and type into a terminal window.:
[code]mv /images/dev/{temprorarynameofimageupload} /images/{IMAGENAME}[/code]
I’ve removed buildroot-2013.08 and replaced it with 2013.11, however it needs to contain the stuff from [url]https://svn.code.sf.net/p/freeghost/code/trunk/src/buildroot[/url] to work properly.
No, you wouldn’t need to put that though.
Try my latest kernel.
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]
It contains all possible network drivers I can fit, without losing speed, and contains none of the VGA information that used to plague (scrambled screen, output issues, etc…)
This sounds like one of two things. First thing, it sounds like the transfer of /images/dev/MA:CA:#D:RE:SS:## isn’t happening. This could be because, from the web gui, Storage Management->Storage Nodes-><YOUR STORAGE NODE>->Username and Password [B]AND[/B] Other Information (the Question Symbol)->FOG Settings->[FONT=Ubuntu][COLOR=#333333]FOG_TFTP_FTP_USERNAME [/COLOR][/FONT][B][COLOR=#333333]AND[/COLOR][/B][FONT=Ubuntu][COLOR=#333333]FOG_TFTP_FTP_PASSWORD ane make sure they’re the same as the fog user on your fog server. The other item, it sounds to me, is the utility wget is inaccessible, or your web service directories ({FOGWEBDIR}/service) files are inaccessible.[/COLOR][/FONT]
[FONT=Ubuntu][COLOR=#333333]Try giving us a printout of your apache2 error log, located at (/var/log/apache2/error.log) and possibly a printout of your access.log file (/var/log/apache2/access.log). Of course, try to make this issue occur, then give us the last few lines of the files so we can be of greater assistance to you.[/COLOR][/FONT]
r1008 contained 64 bit and 32 bit binaries.
r1009 updates the fog.mk script to know which binaries to copy.
r1006 is updated. The same basic configuration from before, package/Config.in is updated to 2013.11. Kernel headers are still 3.12.1. Everything else is more or less the same. Just prefer to keep things updated while we’re updating. init.gz was update as well.
Also,
If you build a 64 bit system, you’ll need to replace the partclone binaries to be 64 bit as well. I’ll try to provide links to them based on 0.2.66.
To build the init.gz as 64 bit. Make sure you start with a clean buildroot system.
[code]make clean[/code]
Then you will need to run:
[code]make menuconfig[/code]
Within the menu choose:
Target Architechture(x86_64)
Toolchain->C Library(eglibc)
Then exit and save the configuration.
Then all you should need to do is run:
[code]make[/code]
Once all is done. Copy the output/images/rootfs.ext2.lzma file as init.gz to the FOG Server under: /tftpboot/fog/images/init.gz
Then you need to build a 64 bit kernel.
Download the kernel you want to build and extract it. Copy the configuration you want to use to the directory that is extracted as .config.
[code]cp ~/TomElliott.config ~/linux-3.12.2/.config[/code]
Then, just to verify all is well run menuconfig from within the linux folder.
[code]cd ~/linux-3.12.2
make menuconfig[/code]
Select 64-bit Kernel then save the kernel configuration.
Then run:
[code]make bzImage[/code]
Once all is done, copy the arch/x86/boot/bzImage file to the FOG Server under: /tftpboot/fog/kernel/bzImage.
You have now build a 64bit compatible FOG imaging system. Of course this will not work for netbooks, or strictly 32 bit architectures, but to each their own.
For a side note on building your own stuff like this. I don’t have time to try to explain what you need to do on the system side of the house to get things to work properly and actually build. I’m almost certain there are many things that need to be added for things to work exactly as needed. However, the quick and dirty (and I’m certain, even with this, you’ll need a couple more packages but that depends on your distribution) for Debian/Ubuntu and CentOS is:
First install the OS as you normally would. Once done, make sure all is updated.
Once all is up-to-date, reboot the system so you know all is loaded and well.
Then as the root user run: (FOR CENTOS/REDHAT/FEDORA)
[code]yum -y groupinstall “Development Tools”[/code]
Then as the root user run: (FOR DEBIAN/UBUNTU)
[code]apt-get update; apt-get install build-essential[/code]
You should now be able to build things. There are other packages you may need. But I don’t remember all of them. Maybe, when I get a change to reinstall, I’ll go through the entire process and document it here, but for now you’re somewhat on your own.
Also,
I’ve updated the tarball: [url]https://mastacontrola.com/fog_0.33b.tar.bz2[/url], so it’s at the same revision. File size there saves a whole 5MB too!
With so much work put into the latest init.gz, I find it appropriate to release a version of SVN FOG 0.33b that contains all the latest and greatest.
So without much further ado, here goes the change list for this.
r1005 contains.
[LIST=1]
[]Updated src/buildroot information to contain information I used to build my init.gz with updated trees.
[LIST=1]
[]Newer Buildroots (mine is based on 2013.08.1) do not use the fs/skeleton structure anymore. They use system/skeleton. This maintains the same as the inittab still needs that minor adjustment in it.
[]Newer Buildroots no longer automatically find package/customize anymore. So I built the packages with the main packages folder. The FOG specific files are included in the tree build under src/buildroot/package for familiarity sake. With this, the package/Config.in file needs to be slightly modified to add the packages for fog. This is included as well. Rather than using fog.busybox.config as before, the busybox config is located in it’s natural buildroot hiding place, under package/busybox. The only configuration I made was to 1.21 so if you’re trying to use an older version, you’ll have to modify the config with[code]make ARCH=i386 busybox-menuconfig[/code] Make sure to ONLY add to it. Add base64 and fdisk utilities.
[]As before fog.busybox.config exists. I’ve also added the .config so when you perform the task:[code]cp -r ~/trunk/src/buildroot/* ~/buildroot-2013.08.1/[/code] it should add the config for you, meaning all you should have to do is perform[code]make ARCH=i386[/code] and off you go building. Obviously if you need to make changes do that first.
[LIST=1]
[]NOTE: If you’re trying to build for 64 bit, and your build system is 64 bit, you’ll need to change from uClibc to eglibc in the toolchain section. eglibc, for now, does not support i386, and as far as I can tell, uClibc does not support x86_64.
[/LIST]
[]The customization I had to make to get chntpw to build made it a file I had to provide. It’s located in src/buildroot/dl/. With this, there is pigz and mpfr. Pigz is included because the download location doesn’t keep pigz with versioning information, i’ve included it for ease when you want to build. Mpfr was included because the download site is down way too often to try playing around in my opinion.
[]The init.gz file is now compressed with lzma. Minor change to how to unzip from current wiki. decompress with[code]lzma -d -c init.gz > init[/code] Recompress with[code]lzma -z -9 -e -c init > init.gz[/code] This file is also updated to contain 3.12.1 kernel headers. This is to help save on size over all. Original init.gz is around 11 MB. Compressed with this method is down to 5.8MB.
[]The kernel is updated to the latest and greatest 3.12.2. Also compressed using lzma. Brings 10MB kernel down to 7.8MB. Just another size. It’s based on my TomElliott.config which has also been updated in this release.
[]The base FOG script contains replacement from partimage to partclone. I’m using partclone.${fstype} as the identifier where ${fstype} is based on the OSID. If it’s ID 50, it’s extfs. If it’s anything else, for now, it’s ntfs.
[LIST=1]
[]NOTE: I would like to use partclone.dd for raw image format just so we have GUI happening if at all possible. Right now RAW image formats still work using straight dd.
[]NOTE: for ncurses (BLUE PROGRESS SCREEN) to work, buildroot needs to be compiled with udev. Just trust me on this for now.
[/LIST]
[]Added ntfsfix commands to the FOG Script as well as some adjustments to parted for partition creation. When uploading a new image under resizable, the resize forces the drive to go into a chkdsk state. If this isn’t cleared, partclone will not create the image. So ntfsfix is added to clear the tag to allow imaging to happen. Parted is now using -a opt to create the partitions. However, it doesn’t like to move the system to the latest sector as, in Win 7/ (8 ???) the first partition ends on 105906kB. The start point for the second partition was the same which parted does not like now. So to fix this, the defaultpart2start is now set to bytes at: 105906176. Also, different drives like different end sizes. Some drives can use 100%, others need to specific size. If added two lines that basically do the same thing, to try to ensure the second partition actually does get created. Otherwise you can’t push the image.
[*]It appears, and will need some testing to verify, that using partclone we’re back to the old style of imaging where you won’t need to sysprep the image before uploading. You can choose to still sysprep if you want, but sysprepping is only needed, from what I’ve been able to test, if you’re trying to do resizable windows 7 image. I don’t have windows 8 to test with, so will need help from that end. Theoretically Windows 8 imaging works with partclone anyway, so hopefully all is well now though I don’t know 100%. Hope you all enjoy.
[/LIST]
[/LIST]
Based on my understanding,
Your IP DHCP Range changed from 10.140.252.x to 10.140.190.x?
Was this an on the fly change?
Did you make the changes to your FOG Server configurations? TFTP, WEB_HOST, FTP?
Have you restarted your fog server since DHCP took over? Or at the very least the apache server?
The reason you’d not be able to access the web server (10.140.190.82/fog) sounds like you changed the network but did not restart the apache service.
You’ll run into all sorts of other issues though unless you make the configuration changes. Many of them will be on the Web GUI, but you’ll likely need to make the change to your /tftpboot/pxelinux.cfg/default file as well. All references to the old IP will need to be updated to the new server address.
I’ll be posting a more defined tutorial in the next couple of day’s on exactly what to do.
It may take a little more testing to make sure all is well and good, but I think, for now, the only major changes for building the init.gz in 64 bit mode is to change the ARCH from i386 to ARCH=x86_64, and to change from uClibc to eglibc.
Again, I’ll test with it to make sure, but just though to give some information. The init.gz will then be based, almost exactly, on the 32 bit modes. If worse comes to worse, I’ll try tinkering with eglibc on 32 bit builds as well.
All,
I think I’ve tweaked enough with the init.gz. Still in initial testing, but I think I’ve got it down enough that it was safe for me to update the src/buildroot files on the trunk of svn. We’re now at r1004 because of this. Now once I’m complete with testing the init.gz I’ll update svn with my latest and greatest one. It’s built around 3.12.1 headers so I may have to make a go at updating the kernel that we can download.
Compression,
I’m going to move mine away from gzip as it’s, to me , a rather large init.gz file if only gzipped. I’m compressing it with
[code]lzma -z -9 -e < rootfs.ext2 > init.gz[/code]
Thank you Fernando for giving me the insight for this compression medium.
as it makes it from ~10-12 MB down to ~5-6 MB. This means less time waiting for it to load.
I don’t mind the kernel being larger as that is to be expected due to it containing all the drivers for the systems to be imaged, but I think a smaller loading rootfs is a necessary thing.