it doesn’t install anything, it makes nothing.

@ installfog.log only is

Script started on Sa 17 Jan 2015 22:34:22 CET
Debian

Also is this on upload or download tasks it is important

Though I will admit, I don’t know if we tested XP/2000 OSID type.

Known about issue and is fixed in SVN.

We narrowed what the issue was. On current SVN versions we are not specifying the version number of fog in the init. This displays when the banner is displayed and this was where the issue was/is occurring. The reason for the banner to be stuck is his system would boot and everything just fine. However the os layer is being assigned an ip outside of the fog dhcp controller. For example if his network main has a dhcp server handing out IPs in the 172.16 range while the fog dhcp is handling 10.x.x.x range, boot up would get the 10.x.x.x range but the init would get ip in 172.16.x.x range.

Just perfect, thank you very much!

We wanted to know what your server version was b/c there are may things you must do if you are moving from 0.32 to 1.x.x. So many things there is a nice wiki for it.
[LIST=1]
[*]I guess I haven’t as of yet. I keep rebuilding my images yearly and deploy soon after they are finished. You could always ftp them over to the “master” server before connecting the storage nodes. then just create the images in the web gui. as long as you drop the images in /images and name them exactly the same then you should be ok.
[/LIST]
You may also want to export your hosts and export you database. This will get you back in action faster.

Under storage management->relevant node->path. You change this here. Then you’ll have to update the /etc/exports file to match the new path. Then you need to update the /opt/fog/.fogsettings file so the image location is updated so future upgrades. Make sure to set perms and place the .mntcheck and dev/.mntcheck files and make the new path chmod 777 -R and all should be done.

if the wol task is not working automatically, but works for the same host when done manually from the url, and all of the settings are correct, i don’t know what could possibly be wrong

Finally!!

Thanks to TOM and everyone else on here who helped me out.

I wont be touching it again for a while.

Why cant be I be in bin directory while running svn?[/quote]
because it’s only updating the files in the bin directory if you’re in the bin directory when you run the update, which is 2 files

Thanks for your reply.

I have fog 1.2.0 and Ubuntu 14.04.
I will have look on wiki.

thanks

PK

It’s ok. Thanks.

[quote=“Uncle Frank, post: 40923, member: 28116”]I can confirm fractal13’s findings and I am pretty sure it’s still an issue in current SVN (r2908).

Our setup is kind of similar having Windows 7 AND logical partions.

sda1: primary NTFS Windows 7 (100 MB boot partition)
sda2: primary NTFS Windows 7 (C: partition)
sda3: extended partition
sda5: logical NTFS (D: data)
sda6: logical NTFS (E: ubuntu in an image file using WUBI)

Kind of a weird partition layout I know but it’s what we got right now… As we use WUBI we don’t have GRUB installed right on disk! So I don’t need to worry about that and therefore choose OSID 5 (we run Linux yes but from FOG’s point of view it looks like Windows only).

I fixed the problem for us with this very simple change in fog.upload:
[CODE]— src/buildroot/package/fog/scripts/bin/fog.upload (Revision 2908)
+++ src/buildroot/package/fog/scripts/bin/fog.upload (Arbeitskopie)
@@ -239,7 +239,7 @@
fi
elif [ “$imgType” == “mps” ]; then
hasgpt=hasGPT $hd;

if [ "$hasgpt" == "0" -a "$osid" == "50" ]; then if [ "$hasgpt" == "0" ]; then have_extended_partition=`sfdisk -l $hd 2>/dev/null | egrep "^${hd}.* (Extended|W95 Ext'd \(LBA\))$" | wc -l`; else have_extended_partition="0";

[/CODE]

Although I have to admit that I CANNOT test if this is working for everyone else (other Windows or Mac OS X) I wonder why extended/logical partitions should only work with Linux (OSID 50)??

Would be great if others could test this “fix” and provide information if this works in their environment.

Thank you![/quote]

Thanks for reporting.

Your patch has been added and hopefully will work for yours and others items.

Hello,

I’ve upgraded to SVN 2906 and this problem is resolved.

I now see a sensible page if I call up the login history.

Thanks
Alasdair

Dear Tom,

I can close this problem. Thanks for the support!

What I’ve done or learnt -

I’ve upgraded to svn 2906 just to be sure I have the latest and greatest.
I rechecked everything I had to patch to get it going on a SuSe platform. Although I didn’t find anything, Doing it again, I might have missed out a mistake I made last time.

I’ve found that if I enter
[QUOTE][url]http://localhost/fog/management/index.php[/url][/QUOTE]
then the redirect keeps the 'index.php
but if I enter
[QUOTE][url]http://localhost/fog/management[/url][/QUOTE]
then the redirect follows
However, this doesn’t appear to be a problem as the redirect now works and I get the page I expect.

I found that the new version needs me to enter the PHP SSL extension otherwise I get the error
[QUOTE]PHP Fatal error: Call to undefined function openssl_pkey_new() in /srv/www/htdocs/fog/lib/fog/FOGCore.class.php on line 522[/QUOTE]
in the apache error_log.

Installing this extension required me to restart the apache server.

Upon retrying, it all burst into life 🙂

Thanks again.

Onto the next challenge.
Alasdair

Thanks Tom. I get it. Yet upgrading to 1.2 will help, but not entirely. I actually did try upgrading and got an error upgrading the database so I reverted to my 0.32 snapshot in an effort to avoid conflating the issue.

Junkhacker-your comment makes sense.

So now the question, when I remove all of the partitions during the Windows install, then allow windows to reformat in MBR I get the copy error I described earlier from FOG?

I don’t want to get too far off track, but now that i’m squared away with 1.2.0 and things are working, do you recommend I move to the SVN?

This is a pushing topic right now and we are currently working on this but new information will be posted in the forum and here in the wiki.
[url]http://fogproject.org/wiki/index.php/Multicasting[/url]

[quote=“Irton, post: 40877, member: 28056”]Consegui mudar no meu dhcp, mas ainda continua com o erro.
[SIZE=16px][COLOR=#212121][FONT=inherit]I managed not to change my dhcp , but STILL continues with the error.[/FONT][/COLOR][/SIZE][/quote]

Si no puede editar o cambiar la configuración del servidor DHCP tiene que utilizar DNSMASQ proxy servir a su archivo de arranque y el servidor.
[url]https://translate.google.com/translate?hl=en&sl=auto&tl=es&u=http%3A%2F%2Ffogproject.org%2Fwiki%2Findex.php%2FUsing_FOG_with_an_unmodifiable_DHCP_server%2F_Using_FOG_with_no_DHCP_server%23DNSMASQ_settings_for_iPXE[/url]

If you can not edit or change settings on the DHCP server you need to use DNSMASQ to proxy serve your boot file and server.
[url]http://fogproject.org/wiki/index.php/Using_FOG_with_an_unmodifiable_DHCP_server/_Using_FOG_with_no_DHCP_server#DNSMASQ_settings_for_iPXE[/url]

That is actually not enabled. I guess I should have specified rebooting when there is a task, like changing the host name, or something. The reason I ask is that I logged in to some of my lab machines today to install some software that couldn’t be deployed. The machines all rebooted within a few minutes of logging in. The local Fog log showed that Fog was attempting to join the machines to the domain, but they had all been imaged 2 days ago.

Is it possible for a Fog task to get “stuck” in a queue? I read this thread: [url]http://fogproject.org/forum/threads/fog-client-weirdness.11942/#post-38669[/url] that seems to point in that direction. There have been many task false starts in the past week or two, where the task was cancelled before being completed.

Where does the actual mysql db for Fog reside?