Posts made by Tom Elliott

Alright man,

Sorry I wasn’t able to help out too much but good luck. Maybe I can help with your other issues then.

It sounds like it’s your kernel.

I’ve build a, relatively small, kernel, that (yet to be fully tested) doesn’t rely upon your video card, so shouldn’t cause a green screen.

You can download it at:
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url] (~6.5MB)

If using wget use the command:

wget --no-check-certificate [url]http://mastacontrola.com/fogboot/kernel/bzImage[/url] (~6.5MB)

It’s based on PeterSykes Config with a few modifications for proc and is based on 3.10.9 if you want to try that.

Give me about 15 minutes as I’m currently performing updates on my servers.

EDITED TO REFLECT PROPER LINK: Missed kernel after fogboot (sorry)

I’ve tried a diff of my init.gz and the FOG built init.gz, and, really, the only main differences I’m finding are binaries that I’m using are slightly more modern. Things like pigz is 2.3, clamav is set for 0.97.8, my customized chntpw-source-110511.zip, parted-3.1, the buildroot packaged version of ntfs-3g and tools, and gptfdisk from the buildroot system. It just seems strange that a customized version of init.gz would lose a partition after partimage runs.

I’m still not having any luck with a custom init.gz file.

I’ve followed the instructions on the WIKI page, but it just doesn’t seem to work with even the direct copies from what the WIKI page states, or with my modified versions. If I fix all the minor issues with the absolute instructions given, or if I use my own, uploading an image will only copy the rec.img.000 file when I set the system to do a Single Disk, Resizable image. I’ve modified the fog script so output information and sleep at various times, at it seems, with the custom built init.gz system, after it finishes copying rec.img.000 it, seemingly, removes the ${hd}2 variable from availability, but right before it does the first partition copy, it does exist. If I use the init.gz file that FOG has already created, all works fine. I’m just trying to figure out what the main differences are.

Can anyone help?

Clamav isn’t the problem its the script that fogs using to do the scan. The scripts error checking is only allowing NTFS.

Yes but you may be better off looking at the init.gz file and find which controls clamav scanner and make a few tweaks to allow it to scan the fat32 parts. If you have it there it could get a virus.

Fat 32 is not NTFS and I’ll bet the fog source is requiring NTFS.

Also don’t be afraid to try local boot 0x80

Yes, our storage node is set to allow 15 clients as well as the other two places specified, but it still doesn’t work in our setup. It’s not a huge deal for us though, as our images are fairly small and everything is gig-e.

The questions that need to be answered are:

When you receive your systems, do they come with a restore CD and are they, if you turn them on, preinstalled?
Are the systems you receive, more or less, the same system?
Are the systems you receive SLP keyed
If you where to use the cd do you have to enter the key or not; if you don’t need to enter a key, you’re systems are probably SLP keyed.

The reason these are asked is I can tell you a simple answer. If the systems are SLP keyed and have licenses for each system, you can upload an image of one system, and push that image to all clients of the same make and model. No Sysprep or anything.

I’m sorry. And I’ve noticed, with FOG 0.32, this doesn’t matter. We have all of our configs (even if deprecated) set for max of 15 clients, but as soon as 10 clients are downloading, the limit is met and anything after just queues up. We’ve restarted the server to make sure it wasn’t just a service needing to be restarted, and this didn’t help. It seems like the queue is set at 10 no matter what we do. Now I haven’t looked into funcs.sh or the /bin/fog script so maybe I’m just being silly, but it seems like it’s a constant that we can’t change for now.

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.