Latest FOG 0.33b
-
r1000 and r1001 released.
Contains infancy of partclone inclusion for extfs filesystem. It’s also using my custom build of init.gz which does support hostname resolving.
-
These are just minor things I noticed… don’t hate me for being picky!! lol
On Service Configuration -> Task Reboot it reads:
[I]If it does and no user is logged in, the Servicewill restart.[/I]
under fog .32 it reads:
[I]If it does and no user is logged in, the host will restart.[/I]
Report Management Page -> Home it reads:
[I] FOG system. to view a [/I]
needs a capital T
-
r1002 released to fix grammar and spelling as requested.
-
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] -
will give this a test when back at work, thanks
-
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!
-
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.
-
r1007 updated with 2013.11, now contains the rsync tools.
-
r1008 contained 64 bit and 32 bit binaries.
r1009 updates the fog.mk script to know which binaries to copy.
-
Hello!
I have updated fog 0.33b to the latest revision on my test server, then I started to test a few things. I tried to upload the image from the client to the server and got this error: “FOG requires your Windows XP’s partition start sector to be 63 but is 1”. I checked the start sector from a linux live cd and it shows me 63, tested with vmware and winxp, same problem. To be sure that this problem has nothing to do with the update, I did a complete reinstall of ubuntu 12.04.03 and from the fog server, the error still appears.
If you need more informations or want me to test me something, write it down here and I will test it.
-
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] -
I think this is because it’s reading /dev/sda1 as well, and of course the start sector for the first partition is going to be 1.
I’ll see if I can figure out another method.
-
I started from debug mode, and typed in fdisk -l, it shows me start sector 1. The disk has only 1 partition, there is only /dev/sda1.
-
[quote=“Albatros, post: 20692, member: 16710”]I started from debug mode, and typed in fdisk -l, it shows me start sector 1. The disk has only 1 partition, there is only /dev/sda1.[/quote]
I get exactly the same issue using REV 1009.
Also I’m unable to upload a Windows 7 Image, it flashes on the blue upload screen then restarts.
Deploying ‘looks’ like its working, until it restarts then just crashes before the windows logo (note its not the image as using the exact same image of previous revisions 999 and below it worked fine)
Maybe the problem is linked in someway? -
[quote=“Albatros, post: 20692, member: 16710”]I started from debug mode, and typed in fdisk -l, it shows me start sector 1. The disk has only 1 partition, there is only /dev/sda1.[/quote]
It sounds like the issue for you is related to it creating the partition. To my knowledge, XP only uses the one partition. I correct the start sector, if it’s blank or 1 to set it 63.
[quote=“Joe Butler, post: 20698, member: 3637”]I get exactly the same issue using REV 1009.
Also I’m unable to upload a Windows 7 Image, it flashes on the blue upload screen then restarts.
Deploying ‘looks’ like its working, until it restarts then just crashes before the windows logo (note its not the image as using the exact same image of previous revisions 999 and below it worked fine)
Maybe the problem is linked in someway?[/quote]Joe, can you start yours as debug (Download or Upload?) and run the command:
[code]parted -s /dev/sda2 -a opt u kB mkpart primary ntfs 105906176s 100%[/code]Tell me what it spits out at you.
It sounds for your particular issue, is it’s not recreating the second partition and I need to find out why. I have two commands:
[code]parted -s ${part} -a opt u kB mkpart primary ntfs ${defaultpart2start}B ${layoutSize}
parted -s ${part} -a opt u kB mkpart primary ntfs ${defaultpart2start}B ${diskSize}kB[/code]Back to back. One way or another, it’s supposed to create the second partition. Some drives don’t mind 100%, others need the size specified directly. I don’t know why. On an 80GB drive, it wants percents. On a 50GB drive, it wants the actual disk size. It’s dependent upon the drive itself.
${layoutSize} is set to 100%
${diskSize} reads the max size the drive can contain. -
r1010 released, hopefully to address start sector 1 for windows xp images. Please test. I don’t have XP to play around with.
Thank you Albatros for the info.
Joe, I’ll try to come up with a solution for your issue as well, but on the systems I have to test with everything seems to work. So I’ll need your help if at all possible.
Thank you,
-
I upgraded the fog server, tried to upload an image from the client to the server and get this error:
[IMG]http://i.imgur.com/a6XlaEh.png[/IMG]Tried this wth other computers, same problem. I am not sure what’s now wrong there, sorry Tom.
-
First of all, thank you! You’re doing a great job
I want to ask for UEFI support, when I try to register a PC it throws an “unsupported BIOS version” error and later a Kernel Panic.
There are any news about of that?
Thanks!
Joan
P.D: I was writing this message at the same time as Albatros
-
The issue you’re seeing is the init.gz file you’re using, seems to not have lzma support. So it can’t mount the rootfs which will, of course, cause a kernel panic. You’re sure you’re on revision 1010?
I don’t have any UEFI systems to test with, but could you provide more information about the kernel panic? Ultimately, I don’t care so much about the error. That’s fairly typical as the kernel has many bios options available to it, but not all will be supported.
Thank you,
-
Well, I thought the error was caused by UEFI but it is the same kernel panic that Albastro has posted.
I’m running the r1010 revision.
Thank you!
