Posts made by abos_systemax

Hi FOG,

I just upgraded to FOG trunk and everything works with a few exceptions;
in the task management window I see a

Search failedSyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data 

error in the top of my window;

I also see some other errors, regarding Strict settings

Strict Standards: Accessing static property TaskManagementPage::$returnData as non static in /var/www/fog/lib/pages/taskmanagementpage.class.php on line 41

Strict Standards: Accessing static property TaskManagementPage::$returnData as non static in /var/www/fog/lib/pages/taskmanagementpage.class.php on line 85

This happens on all the pages related to tasks.

Now is my issue, that I started an upload task of a Windows 10 Machine. The images got created (they are in the /images/dev/mac/ folder) but the task keeps on running and the images do not get moved.

Is there a way to ’ manually’ tell fog that the process went right; or do I need to start the whole process over (and: how can I prevent this from happening)

The Image row in MySQL has data in it, but the ’ All Images’ -management screen shows ’ No data’ behind the image.

@george1421
it’s off topic on the initial topic, but it’s very relevant on the later part of this topic. Giving your KB a read and its a very interesting read.

@Wayne-Workman
eventually we will store our images on a SAN, so the partitions should not be that much of an issue. However, if it somehow makes a difference then we will definitely have to consider all options. Since we will have multiple customers and lots of images in the future, speed and efficiency are the two major things to take into account.

I’ll check out the guides on CentOS and Fedora as you mentioned. Thanks for the heads up.

@Tom-Elliott We are one of them people…(we setup the LVM with everything on one partition) Mostly because I do not know any best practices in terms of this setup.
Does FOG has a ‘best practice’ in terms of disk layout and setup? As said, we are still busy with the initial implementation and everything tackled in this phase is a job done.

@Tom-Elliott

Since we are still busy with our test environment, and nothing is set in stone: are newer versions of Debian a better solution; or do we have to look to different Linux OS’ses to support Fog 1.3.0 (and multicast traffic(!)) without having to resort to RAW image data?

@Sebastian-Roth

Thank you, i’ve updated the kernel to 3.19.3 (was 3.15).
Will check Monday if it’s bootable in UEFI. (I believe you, but theory and practice are different beasts )

@Tom-Elliott
I’ve found the file that is responsible for the ${arch} variable; the reason it wasn’t working with my setup was because the arch it was expecting is x86_64; and the arch i’m passing is x64… so the x32 was always the file getting served.

Thank you for the push in the right direction; I was staring myself blind at the problem.

I’ll definitely check out 1.3.0 and see if it works on Debian Wheezy

@Tom-Elliott

AH! that’s it… I need to pass the ${arch}…

stupid little me thnx!

@Wayne-Workman

My ‘problem’ here is that I already supply the right ipxe based on the architecture via DHCP; however, the boot.php file does not recognise this apparently, because it always distributes the x32 versions of bzimage and init.xz; so somehow I think fog changed the original ipxe files to include some other script to help in the boot process?

I will certainly have a look at 1.3 (trunk), mostly because we are still in our own beta setup here and having the latest when going live is in everyone’s interest.

@ch3i

That is because I created my own from the IPXE project

Hello fog,

Currently i’m busy implementing the Fog Project in our enviroment.
This enviroment is a mixed one (Legacy x86, Legacy x64, UEFI x86 and UEFI x64).

We use a Debian Wheezy as our fog and DHCP server and use IPXE as our default boot menu.
I’m booting to fog using the “var/www/fog/service/ipxe/boot.php”

I’ve noticed that for Legacy x64, I have to rename bzImage and init.xz to their x32 equivalents (bzimage32 and init_32.xz) because the default boot.php always selects the 32 version of the files… (–> way to circumvent this?)

However, the ipxe64.efi and ipxe86.efi files both end up with a Kernel Panic…
I can find a lot of Kernel Panics on google, but all topics are 2 to 3 years old…
What files do I need to boot to support UEFI? booting to legacy is not an option on these devices.

Thanks in advance,

Alex