What is the OS you’re server is running on?

In Ubuntu (Debian Based), NFS requires nfs-kernel-server nfs-common and portmap. In Fedora/Centos (Redhat based) NFS requires rpcbind and nfs (yum install nfs rpcbind; chkconfig rpcbind on; chkconfig nfs on; service rpcbind start; service nfs start)

Check your /var/logs/messages files for errors that may lead you in the right direction. Also Check your /etc/my.cnf file for the binding address. my.cnf deals with the mysql side of the house and if it’s bind address is set to 127.0.0.1, and the system you’re trying to load is outside of the network your server is on (outside being vlan, subnet, etc…) it won’t be able to connect to the sql server properly to get the NFS information and load it to the client for mounting. (WHEW that’s a long sentence)

I don’t know what else to ask so chad or anybody else with other ideas, or if I’m just plain an idiot, please feel free to step in.

The default pxe file with all stock settings (less our passwords of course).

There haven’t been any kernel parameters added. To my knowledge, 0.32 doesn’t use initramfs. If it did, that’s news to me. What kernel parameters are you using? What does the kernel panic message state?

I’ve been building my own init.gz files for the last month, for fog 0.33, of which, I know is using ext2 filesystem, and no compression. The compression is performed by hand with a simple gzip -9 < output/images/rootfs.ext2 > init.gz

Also, to help in troubleshooting, what is your setup? Are you on VM? When did you start having problems with fog? When was the installation performed? Is the storage node on the same server or separate?

This is your own custom kernel?

And init.gz is a compressed ext2 filesystem, not cpio.

If this is a custom kernel, how was the kernel created? 3.8.8 is the latest released by fog. Having a custom kernel is fine, especially if you have special hardware within your setup.

Add the caveat for custom kernel, is the system you created it based on 64bit? If it is, when you run the make commands, don’t forget to do it with make ARCH=i386 menuconfig and make ARCH=i386 bzImage

Notice the ARCH in the make command as without it, it is going to try to build your image based on your systems current architecture which the init.gz system does not recognize.

I use 3.2.4 at work, and we’ve tested (working) 3.8.8, just we don’t use the 3.8.8 kernel as video on our laptops doesn’t work.

I’ve not noticed an issue with 2.6 headers and 3.X kernels. We use 0.32 on our systems and have tested kernels all the way up to 3.10.7 (so far as I’m currently building 3.10.9)

It seems to me, possibly, that you’ve got a custom init.gz file? I don’t know all of those details.

I’ve been building my own custom init.gz for use with FOG 0.33b and the option for cpio filesystem is unchecked, with the 0.33b REV 899 fog.buildroot.config file. I’ve not tried using cpio enabled in my building, but I don’t think all of your information is correct. The init.gz files compressed, but not with cpio. It’s compressed with gzip.

The quickest way to modify the init.gz file system is to:
cd /tftpboot/fog/images; gunzip init.gz; mkdir tmp; mount -o loop init tmp

Once completed with your modifying the files in init.gz You will simple perform
umount tmp; gzip -9 init

From the sounds of it, you went from a layer 2 switch (just a typical 5 or 8 port , possibly more) that just helped connect networks to a managed switch. Check that your managed switch is passing the traffic on to the proper route to your DHCP server.

Is the DHCP server on a separate network segment that your current network can’t communicate with?

Good luck then.

The IOCTL error isn’t particularly important then. I see it with my home-made kernel because it has RAID drivers built in, but the devices don’t have raid drives. If you’re having issues with imaging a specific drive, it may point you in the right direction, but by itself it’s perfectly fine.

Sorry all,

I forgot to read that you guys were having the issue with FOG 0.33b. I posted all of this information on FOG 0.33 Bugs forum as well.

You’re welcome then!

It sounds like the file /images/780/d1p2.img.001 does not exist? Can you very if this is indeed there?

I don’t know of a method of confirming the actual svn revision. Maybe somebody else can be of more help in this regard.

What version of FOG were you using when this happened to you? I haven’t seen any issues with this as we, in 2011, had received systems with Windows 7, but were, at that time, supporting Windows XP. We created the Windows XP image and uploaded to the relevant system and had no issues that I’m aware of. We were using FOG 0.32, and still are.

Okay,

The FOG 0.33 hdparm, not registering issue you’re seeing, I don’t know how to help out with that completely, unless you can let me in remotely to assess the issue, but even if you’re able to get past the hdparm issue, you still won’t be able to register the host. 0.33b has removed the host association of the OS field, and now the OS is assigned to the image file itself. This makes perfect sense, except the auto.register.php file still has references to inputting the hostOS which it fails because that table doesn’t exist. I’m going to upload my auto.register.php script, this file goes in:

<fogwebdir>/service/auto.register.php

Also, if you know how to modify the init.gz system -> follows:

cd /tftpboot/fog/images; mkdir tmp; gunzip init.gz; mount -o loop init tmp; cd tmp/bin

Then you’ll have to modify the fog.man.reg file to remove the hostOS input field. I’ll post a copy of that file as well.

You can remove the file fog.man.reg then do:

vi fog.man.reg

Then type the letter i

Then paste the contents fog.man.txt file here into that file. (sorry i can’t just give fog.man.reg, but they don’t allow uploading an extension of .reg)

Once pasted in:

Type the key esc, then type:

:wq

Then:
chmod +x fog.man.reg

Then:
cd …/…/
umount tmp
gzip -9 init

Then you should be good to go without inputting host os.

If all of the init.gz editing seems too complicated, at the very least get rid of the auto.register.php file in fog/service/ and insert the one I’ve provided.

When I first started with fog 0.33b I had the same hdparm issue as you are experiencing, but my exact issue, seemingly, was due to the system not reading the right areas because of my pxe default file missing the trailing slashes as needed. Then I ran into the full registration issue with it and found out about the hostOS field missing from the hosts table in the fog database.

Hopefully this helps you out.

[url=“/_imported_xf_attachments/0/387_auto.register.php?:”]auto.register.php[/url][url=“/_imported_xf_attachments/0/388_fog.man.txt?:”]fog.man.txt[/url]

So I found out, today, why It isn’t creating the sys.img.000 file. It’s because, with my custom init.gz, it doesn’t recognize the /dev/sda2 partition. I don’t know why it doesn’t, but it doesn’t. I think it’s because the device_table.txt file, isn’t actually set in the config to use the static table versus the dynamic one, but for whatever reason, it only cares about it on the single disk, resizable option. I’ll keep testing to try to narrow it down. I’ve removed the references to partclone as it doesn’t build for some reason. It could be I haven’t got a clue (most likely) or because fog actually manually writes it’s partclone files to the system any way. I’m building now with static table reference.

Just for posterity, I think I need to add this here. To add the fog components to the menu system, after you copy customize to package in buildroot, don’t forget to add source “package/customize/Config.in” somewhere in package/Config.in file. I added mine at the top, right above busybox. Don’t place it outside of a menu reference, so my source line is the 2nd line in the file.

Also,

When editing the default file,

You’ll find the first PASSWD line as:
MENU MASTER PASSWD <YOUR ENCRYPTED PASSWORD> <-This controls when somebody hits the ESC key>

and the menu options (full host reg, quick img, etc…) as:
MENU PASSWD <YOUR ENCRYPTED PASSWORD> <- When trying to enter a menu option.

For your knowledge, you shouldn’t need them to be encrypted, but, if you prefer to have it encrypted fog has a utility to do that for you which is located in:

/opt/fog/utils/

To run the command type in a terminal:

/opt/fog/utils/md5pass <YOUR [B]UNENCRYPTED [/B]PASSWORD>
Then copy the line printed out which will look something like:
$1$aobkelGl$gX3rr1kioMdm12KvCCW7N0 (this is the md5pass of password)

Copy that line, and paste it in your desired spots.

The location for the file is in /tftpboot/pxelinux.cfg/default

To my knowledge that update system has not worked. You could try by making sure the pxelinux.cfg folder and files are writable by apache just to see but I’m not 100% sure.

No problem and I hope all is working for you now.

That’s a problem with partimage, not with the fog system. It is rather annoying, but I don’t know how to get that to correct itself.