Posts made by ianabc

The short answer is I think you have a problem with your tftp server (it might not be running or accepting connections), the long answer is…

Some of the relevant files seem to be…
[LIST]
[]fog/management/js/fog.about.kernel-update.js
[]fog/management/js/fog.about.kernel.js
[*]fog/management/ajax/kernel-fetcher.php
[/LIST]
Looking at them, the kernel file is downloaded to a temporary location then moved into fog/services/ipxe when it is ready. It is moved by tftp so if you have a problem with your tftp server you are going to hit problems.
As a first step I would give the machine a quick reboot, then CONFIRM that you have disabled any firewalls (iptables/ufw whatever) and SELINUX disabled. After that we need to confirm that your tftp setup is OK, the best way to do this would be to follow the code in kernel-fetcher.php you could try doing the tftp commands manually and see where the problem lies. If that isn’t an option I would try some simple tftp get commands just to confirm that it is running, e.g. on your fog server
[CODE]
$ yum install tftp
$ cd /tmp
$ rm -f undionly.kpxe
$ tftp IP.OF.YOUR.FOG.SERVER
tftp> get undionly.kpxe
$ ls -lhrt undionly.kpxe
-rw-r–r–. 1 root root 100K Jul 14 22:46 undionly.kpxe
$ ps -ef | grep tftp
root 2854 1139 0 22:46 ? 00:00:00 in.tftpd -s /tftpboot
[/CODE]

Does 17:25 sound sensible to you for when you updated the image? Could you try giving it a different name just to make sure that your webserver is creating the file, e.g. bzImage-TomE

The kernel updates are usually very quick, I’ve never seen it take more than a minute or so. Is this a prebuilt kernel or one that you are creating yourself?

If I do [Fog configuration]->[Kernel Update], then click the download icon under “[FONT=Ubuntu][COLOR=#555555]Kernel - 3.14.2 TomElliott[/COLOR][/FONT]”, I get a dialog for the new kernel name, I give it the name “bzImage-TomE”, then hit next, about 15 seconds later I get a message that my new kernel has been installed. If I look in the tftp root on my fog server I can see it
[CODE]
$ ls -lhrt /var/www/html/fog/service/ipxe/
-rwxr-xr-x. 1 fog apache 44K Jul 12 10:24 bg.png
-rwxr-xr-x. 1 fog apache 503 Jul 12 10:24 advanced.php
-rw-r–r–. 1 fog apache 11M Jul 12 10:24 init.xz
-rwxr-xr-x. 1 fog apache 5.9M Jul 12 10:24 bzImage32
-rwxr-xr-x. 1 fog apache 756 Jul 12 10:24 boot.php
-rwxr-xr-x. 1 fog apache 1.8M Jul 12 10:24 memtest.bin
-rwxr-xr-x. 1 fog apache 25K Jul 12 10:24 memdisk
-rw-r–r–. 1 fog apache 9.2M Jul 12 10:24 init_32.xz
-rwxr-xr-x. 1 fog apache 230K Jul 12 10:24 grub.exe
-rw-r–r–. 1 fog apache 5.9M Jul 12 10:24 bzImage
drwxr-xr-x. 2 fog fog 4.0K Jul 14 21:33 backup

-rw-r–r–. 1 fog fog 5.9M Jul 14 21:33 bzImage-tomE
[/CODE]
My new kernel is at the bottom (5.9M). How does this compare to your setup?

If your new kernel doesn’t show up there I would suspect permissions on the web directory, but you might find some useful information in the webserver logs (/var/log/httpd/error_log).

N.B. If you are running under ubuntu rather than CentOS the paths in the post above might be incorrect (your web root is probably /var/www/fog/service/ipxe and your error log is probably /var/log/apache2/error.log)

Hi Lindsay,

The “Cannot allocate memory” messages look a bit worrying to me. Does the machine have enough RAM? Could you try running “free -m” in a command window? e.g. here is my fog server
[CODE]
total used free shared buffers cached
Mem: 996 565 431 0 11 382
-/+ buffers/cache: 172 824

Swap: 2043 0 2043
[/CODE]
My fog server is a virtual machine with 1GB of ram, from the numbers above I have 431Mb free and around 400Mb in cache.

OK, in my case the problem is fixed and it was my network (sigh…:). The short story is, I should have started testing at the most basic level by trying to transfer anything by multicast, I’ve found omping and udpcast useful in doing this. If someone has a good understanding of multicast I think some debugging examples for using udpcast or omping would be a nice addition to the wiki.

Now for the long answer…

My test setup uses a KVM/QMEU network along with 3 KVM guests: One fog server and two client machines. All the guests are networked together on 192.168.222.0/24 which is NATed to give access to the outside world. The NATing is done by iptables on the KVM host via libvirt and has a PREROUTING chain which looks like
[CODE]
$ iptables -t nat -nL
…
RETURN all – 192.168.222.0/24 224.0.0.0/24
RETURN all – 192.168.222.0/24 255.255.255.255
MASQUERADE tcp – 192.168.222.0/24 !192.168.222.0/24 masq ports: 1024-65535
MASQUERADE udp – 192.168.222.0/24 !192.168.222.0/24 masq ports: 1024-65535

MASQUERADE  all  --  192.168.222.0/24    !192.168.222.0/24   

[/CODE]
The problem is the first of those lines, which applies only to 224.0.0.0/24, when I want it to include all mutlciast addresses 224.0.0.0/4. Making this change allows omping, udpcast and [I]of course[/I] fog to use multicast without the hanging problem!

[quote=“rhythmtone, post: 32953, member: 57”]Hi all,
Have you guys tried a FOG installation without a SQL password?
[/quote]

I have one system with and one without a mysql password set. I get the same results either way. Can I just ask you to confirm that you are multicasting to more than one machine in a group. I can multicast with a single group member but not with 2 or more. In my case it looks like the problem is with udpcast itself not fog.

I’ve just tried 2039 and 2046 and I still get stuck at “Starting to restore image”

[ATTACH]1159[/ATTACH]

Doing a “multicast” to a group with a single member works as expected, but with two members in the group I get the message above on both machines. I got to the same behaviour on a physical network as well, but I can’t rule out the network as the source of the problem in either case - I’ve never had multicast working, I didn’t use it in 0.32.

I’m starting to think the actual issue is with udpcast. I’ve done some tests and I can’t get it to work on either virtual or physical setup. The problem is the same, multicast to a single machine works, multicast to two fails.

[url=“/_imported_xf_attachments/1/1159_multicast.png?:”]multicast.png[/url]

Thats right, all you would need to change is “bootfile pxelinux.0” to “bootfile undionly.kpxe”.

As for which version I would recommend 1.2 personally, I switched our systems about a month ago and the changes have all been positive for me: I found the linux handling is vastly improved and iPXE seems much more flexible. The front page of the wiki ([url]http://fogproject.org/wiki/index.php/Main_Page[/url]) has a summary of some of the more important changes.

Incidentally when I put up my fog server I also thought I wouldn’t be using it a lot, but I ended up using it ways I wasn’t expecting (system rescue, “backing up” or migrating hardware), I leave it up all the time now

From your screenshot it looks like the filename was wrong when trying fog 1.X. Fog 0.32 use pxelinux.0 and fog 1.x uses undionly.kpxe, if you want to use fog 1.X you have to make that change in your DHCP.

Ok, I’m testing on revision 2039 at the moment.

My single partition ext4 system is shrinking and growing perfectly - it now grows to fill the underlying disk geometry.

I’ve also just tried a system with a few partitions (/boot, / and swap all primary partitions), initially I thought it wasn’t working but it was me being dumb. It worked perfectly.

It looks like the fill_disk function in /usr/share/fog/lib/partition-funcs.sh allocates any free space according to the ratio of the original partition allocation.
[CODE]
(/usr/share/fog/lib/partition-funcs.sh:358)
partitions[part_device, “newsize”] = (new_variable*p_size/original_variable)
[/CODE]
So if in your original image the disk was 20Gb and you allocated a /boot partition with 1Gb and a / as 19Gb then downloading on to a 40Gb disk gives a 2Gb /boot and a 38Gb /.

I guess this means someone needs to pick a new name for the “Single partition ([B]NTFS Only[/B], Resizeable)” image type. I’ll keep testing the various partitioning schemes I use but this is looking really good to me.

Good luck!

That is just my personal recommendation, not a Fog recommendation! The desktop installer generally installs a bunch of stuff I’ll never use on a fog server. I actually use CentOS for my fog servers but most people seem to choose Ubuntu and both should work.

I’m struggling to remember now but I think that even when you install from liveCD it might as you if you want to “upgrade” rather than reinstall. You definitely want to avoid that! As I said above, you want treat the system as a completely new install.

You should do a full reinstall from the CD or DVD, running the wizard will usually try to preserve some of your configuration files which seems to be causing the problems. Make sure you backup anything that is on there you want to keep then boot from a CD or DVD. Ubuntu has a server image which might be a better fit than the live CD.

[url]http://releases.ubuntu.com/12.04[/url]

[url]http://releases.ubuntu.com/12.04/ubuntu-12.04.4-server-amd64.iso[/url]

I can’t remember the install process in detail but if you are asked what software you want to install just make sure you don’t install a web server or mysql or anything like that. There might even be a “minimal” option.

Once it is installed give the fog installer a go again.

[quote=“NDNtech, post: 32845, member: 23658”]Okay. I had issues with my install too. I couldn’t do a regular install for some reason. I had to boot into the live OS and install from there. In the normal install I kept seeing messages in the command area saying it didn’t have permissions to do things, and then it would error out and say it didn’t know where to install GRUB.

I had a feeling that maybe it’s because I’m using RAID, but I couldn’t find any supporting info on that. I’m using RAID5 on a Dell PowerEdge R610 if that makes any difference. lol[/quote]

I have similar hardware but I’m using CentOS instead of Ubuntu. If you configure the RAID5 in hardware then I think you can just pretend like it’s a simple SATA disk in the installer (i.e. Don’t tell it about the RAID configuration - let the hardware manage that). The installer messages sound weird, what do you mean by the “normal install”?

I’d be interested to see the contents of the /etc/init.d/apache2 file if you have it before you reinstall though.

I think I agree with Tom about the install, you would probably be able to fix the install but a reinstall might be less of a headache. When you are running the ubuntu install DVD just tell it you don’t need a webserver installed - the fog installer will do that for you later.

[quote=“NDNtech, post: 32834, member: 23658”][CODE]root@SC-Image:/opt/fog_1.1.2/bin# sudo /etc/init.d/apache2 start

• Usage: /etc/init.d/apache2 {start|stop|graceful-stop|restart|reload|force-reload|start-htcacheclean|stop-htcacheclean|status}
  root@SC-Image:/opt/fog_1.1.2/bin# ps -ef | grep apache
  root 19158 5377 0 18:26 pts/1 00:00:00 grep --color=auto apache
  [/CODE][/quote]

That’s a problem, the startup script (/etc/init.d/apache2) isn’t exiting correctly.

OK, I think apache is working but that your php setup might be broken. That script should be getting executed on the server, not offered for download. You might need to apt-get install the php packages again.

Could you just confirm that the apache startup script is indeed working, first press Ctrl-C to kill off the apache debug session, then run the actual startup script, here is the output from my system
[CODE]
$ sudo /etc/init.d/apache2 start
$ ps -ef | grep apache
root 20307 1 0 16:21 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 20312 20307 0 16:21 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 20313 20307 0 16:21 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 20314 20307 0 16:21 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 20315 20307 0 16:21 ? 00:00:00 /usr/sbin/apache2 -k start
www-data 20316 20307 0 16:21 ? 00:00:00 /usr/sbin/apache2 -k start

root 20337 19912 0 16:21 pts/0 00:00:00 grep apache
[/CODE]

Once we know that apache is fine we can[S] start fixing php [/S](looks fixed by Toms previous post)

If it is sitting there apache should be running, so I’m not sure why the startup script isn’t working. While that command is still running (cursor is flashing) try pointing a web browser at the IP address of the machine, e.g. [url]http://10.120.88.146/fog[/url]. When you are finished you can stop the command by pressing “Ctrl-C”, that will kill off apache.