Latest FOG 0.33b
-
@Fernando, @darkxeno
I’ve been building the svn as a tarball as well.
The link for tarball download will always be:
[url]https://mastacontrola.com/fog_0.33b.tar.bz2[/url]
Sometimes I don’t update it right away, but as of right now, it’s at r998, the same as svn.
-
[quote=“Tom Elliott, post: 19958, member: 7271”]@Fernando, @darkxeno
I’ve been building the svn as a tarball as well.
The link for tarball download will always be:
[url]https://mastacontrola.com/fog_0.33b.tar.bz2[/url]
Sometimes I don’t update it right away, but as of right now, it’s at r998, the same as svn.[/quote]
I don know it. Thx for your work!!
-
Im a bit confused and a noob here. So can someone tell me if i got the right understanding of svn? If its wrong in my thinking about it please correct me. So with and SVN you have the main code for fog and it’s up in the cloud for anyone to get and install. Then after it’s installed I can then modify the code for issues that i see. Then after i modify the code it will send it to the svn for the administrator to see and if they like the fix and it works that can add it in to the main code. now here is the part that confuses me. with the svn say you where to publish a new code in the svn with fixes and what not would it then push the new code with all the fixes to everyone that is using the svn version of fog automatically? or would i still have to update it and install the new code manually?
-
you have to manually sync your SVN with that available in the “cloud” as you have described it.
after you sync your SVN with the current SVN you go to /bin and run ./installfog.sh and it will update to the latest synced revision.
-
Darkxeno,
You don’t have write access to the svn, so if you notice a problem and make a fix, post it here on the forums under the Bugs in FOG 0.33 thread. You can even post your files directly so I can then look. If it’s viable I’ll try implementing or look into alternative fixes. I try to be quick in turnarounds on issues as such. Lately I’ve been stuck on snapins and snapin tasks.
-
nice thanks currently im using 0.32 in my production do you think it’s safe to upgrade that to 0.33 and it will do i what i need it to do? all i do is create images and the domain add and host rename is what i use.
-
Another way to get a tarball directly from SVN latest version is to use SourceForge, and hit “Download snapshot” on [url]http://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/[/url]
-
r999 is out.
All it updates is the TomElliott.config file for kernel building. Contains working virtio_net drivers as well as most networking drivers. I had to remove some of the 10G net drivers due to compatibility issues of speed.
-
And Tom is DAMN GOOD at what he does, he’s fast, responsive, and even will keep you posted on WHY he hasn’t had time to get to it. Really an Ace developer, most devs won’t even give you the time of day.
-
im no coder at all i’m just a system administrator lol i just know how to use the product
-
[quote=“darkxeno, post: 19976, member: 4011”]nice thanks currently im using 0.32 in my production do you think it’s safe to upgrade that to 0.33 and it will do i what i need it to do? all i do is create images and the domain add and host rename is what i use.[/quote]
I’d recommend a fresh install from 0.32 to 0.33. Backup hosts and images and any other majorly need infos from the 0.32 database as there are many many changes that won’t make the switch easy or pretty.
-
sorry for asking so many questions. i just been seeing that 0.33 was in beta since i started using fog and have been scared to update to it. is there a link anywhere that has all the new features that it has over 0.32 and Tom i see your last post will 0.33 let you in put drivers in to the kernel? like does it have a easy to use kernel builder?
-
No,
Kernel building is still done the old method, unfortunately. But I’ve become quite adept at doing so and keep my kernels as up-to-date as I can. There is a wiki page on how to update/build a new kernel though and it’s pretty simple to follow.
Don’t be afraid to play.
-
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.
