Is fog service running on the system? Double check that the fog client is installed and see if that helps you out.

Do do this go to the webpage:

[url]http://<your-fog-server-ip>/fog/client[/url] and download and install the client on the machine. Then try deploying the snap-in.

If this doesn’t work, for some reason, I’m currently building a kernel based on 3.10.6. It’ll be a little bit, but the file will be called:

bzImageNEW when it’s done.

Try downloading this one and using it:

[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]

You should be able to do it with a wget command. Maybe, to be exact, as I have self-signed certificates:

wget --no-check-certificate [URL=‘https://mastacontrola.com/fogboot/kernel/bzImage’]http://mastacontrola.com/fogboot/kernel/bzImage[/URL]

This kernel is based on 3.10.5, It’s also the kernel.core config setup. I am working to build an all kernel right now.

You’ll download this file to:

/tftpboot/fog/kernel/

So full steps would be:

Open terminal on fog server as root:

type:

cd /tftpboot/fog/kernel

mv bzImage bzImage.orig

then wget --no-check-certificate [URL=‘https://mastacontrola.com/fogboot/kernel/bzImage’]http://mastacontrola.com/fogboot/kernel/bzImage[/URL]

What kernel are you using?

Try updating to a more recent one and see if this helps you out. If worse comes to worse, I can probably build one that has all possible options available, though that would be a kernel around 35 MB’s, or possible larger.

I don’t know much about sysprep, other than it’s a method of putting a windows system, very nearly, back into Out Of Box status. After a sysprep is completed, it basically is as if you just started the system for the first time. There are different methods of sysprep, but most usually will, also, include the generalize option with basically removes all driver associations of the particular system so you could place that image onto any machine without issue.

I don’t know how many times you can use it from the current base image setup. Then again, when I recreate an image, I start completely from scratch so I’ve never had to worry about a number limit.

This is really odd, it looks like you uploaded two images at the same time, or had the image setup for Multiple Partition Image, All Disks and it just so happened that both Disks had, very nearly, the same information. Maybe check this setting out as well. Do you have, more or less, the same OS on two disks in the same system that you can switch in the BIOS?

I’ve got a busy week ahead of me at work, but I’ll try to look more into this this following weeked. I’ll add the components to my init.gz fog script to rewrite the mbr after the upload and after the reload of sys.img.000 and rec.img.000 and see if this works.

No problem man, it’s what we’re all here to do. Learn, and make life easier.

In dealing, today even, with the dreaded problem with no configuration issues, I’ve also seen this issue occur when a network has been affected by a broadcast storm. Essentially what ends up happening is the network is being flooded by another switch, kind of like a loopback into itself. (I know that sounds funny) However, the fix for this particular issue was to reset all mini-switches within the path of the network with a simple power down, power up. Then, as needed, reset the Layer 3 Switches if they became too bogged down by the broadcast error messages.

I hope this helps. The particular issue I saw with one of my systems is that the cable has a break in it somewhere. It had enough signal to boot the kernel and init.gz, but when fog tries to reset the device after boot up, the signal is lost and nothing can be found. Then we got the hdparm issue. Connected the system to a good connection from another area and all worked fine. It wasn’t the system, but the network. Check that this other system isn’t having many Multicast devices attached (iPads, Smartphones, Apple TV, etc.) Reset the switches, and reboot any miniswitches. You may narrow the problem down further this way. If your setup worked elsewhere, chances are it isn’t a configuration issue and I was just trying to help. I’m sorry if I lead you in the wrong direction, but hope that this helps you out.

the / marks are slashes. Many times, I’ve seen the pxe default file looking for web:

<IPADDRESS>/fog rather than <IPADDRESS>/fog/ <- (This is the trailing slash as it trails at the end.)

The default file is generally located in:

/tftpboot/pxelinux.cfg/

the file is just called default.

You can edit it however you want, but just make sure the slash is in the file and in the fog settings.

[quote=“Tom Elliott, post: 14178, member: 7271”]darkapec,

What type of pxe setup are you using? gpxelinux or pxelinux. In either case, your file should not be setup, as far as I can tell, with a prefix of: tftp:/ . Even if this is an okay header portion, try tftp://. If that isn’t working, and you’re using gpxelinux, make sure your file is accessible via a webserver. Then change the tftp:/ parts to http://

One other think that’s standing out, is the kernel line.
[FONT=Consolas]KERNEL linux.c32[/FONT]

[FONT=Consolas]Is this actually your kernel? It doesn’t look like it to me. Usually the kernel is vmlinuz or bzImage[/FONT]
Try using:
[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas] MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas] KERNEL tftp:/192.168.1.145/opt/ltsp/i386/boot/vmlinuz[/FONT]
[FONT=Consolas] append initrd=tftp:/192.168.1.145/opt/ltsp/images/i386.img ro quiet splash[/FONT]
If this doesn’t work try:
[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas] MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas] KERNEL [url]http://192.168.1.145/opt/ltsp/i386/boot/vmlinuz[/url][/FONT]
[FONT=Consolas] append initrd=[url]http://192.168.1.145/opt/ltsp/images/i386.img[/url] ro quiet splash[/FONT][/quote]

Also, just as I’m reading a little bit more, if this chainload is supposed to be happening as such maybe the lines should read:

[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas]MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas]KERNEL linux.c32[/FONT]
[FONT=Consolas]append initrd=tftp:/192.168.1.145/opt/ltsp/images/i386.img ro quiet splash[/FONT]

[FONT=Consolas]Remember, that you’ve already loaded a kernel, so loading vmlinuz shouldn’t work to my knowledge[/FONT]

One of the things I’ve learned with building a custom kernel is to Read the friendly Wiki page or (RTFW) as other so like to display.

If you’re building the kernel on a 64 bit system, make sure your make commands are:

make ARCH=i386 <command>

So when you’re doing the menuconfig do:

make ARCH=i386 menuconfig

Then make your changes and save the new config.

Then when you create the bzImage file do:

make ARCH=i386 bzImage.

I would almost recommend making this an actual part of the WIKI rather than just a note, as it wouldn’t hurt anything to do this from any platform whether i386 or 64 bit.

Thank you,

On the localboot line try:

localboot 0x80

Usually it is set to:

localboot 0 which doesn’t seem to work with ahci and gpxelinux.

darkapec,

What type of pxe setup are you using? gpxelinux or pxelinux. In either case, your file should not be setup, as far as I can tell, with a prefix of: tftp:/ . Even if this is an okay header portion, try tftp://. If that isn’t working, and you’re using gpxelinux, make sure your file is accessible via a webserver. Then change the tftp:/ parts to http://

One other think that’s standing out, is the kernel line.
[FONT=Consolas]KERNEL linux.c32[/FONT]
[FONT=Consolas] [/FONT]
[FONT=Consolas]Is this actually your kernel? It doesn’t look like it to me. Usually the kernel is vmlinuz or bzImage[/FONT]
Try using:
[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas] MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas] KERNEL tftp:/192.168.1.145/opt/ltsp/i386/boot/vmlinuz[/FONT]
[FONT=Consolas] append initrd=tftp:/192.168.1.145/opt/ltsp/images/i386.img ro quiet splash[/FONT]
If this doesn’t work try:
[FONT=Consolas]LABEL Ubuntu LTSP 12.04[/FONT]
[FONT=Consolas] MENU LABEL LTSP - Ubuntu Desktop[/FONT]
[FONT=Consolas] KERNEL [url]http://192.168.1.145/opt/ltsp/i386/boot/vmlinuz[/url][/FONT]
[FONT=Consolas] append initrd=[url]http://192.168.1.145/opt/ltsp/images/i386.img[/url] ro quiet splash[/FONT]

For the hdparm issue, check your FOG Configuration->FOG Settings->Web Server and make sure the web root has the trailing slash. Also check that this information is corresponding to the PXE Default file web={IP}/fog/ portion. If it doesn’t have the trailing slash, it can cause this issue, as the FOG scripts actually run the system as:

${web}service/<file>

Without the trailing slash, it will search for something like:

192.168.1.1/fogservice/<file>.php which obviously wouldn’t exist. Some systems seem to not care and add the trailing slash, but a majority of them do this is in this fashion from what I’ve seen.

Maybe I’m wrong, but it couldn’t hurt to check.

Also, if it keeps being deployed, check your /tftpboot/pxelinux.cfg folder. If there are no tasks, you should only have the default file. Chances are, and I’m only guessing, you’ve got a file that is representing that system’s mac address in the format of 01-XX-XX-XX-XX-XX-XX where the X’s correspond with your systems mac address. Delete this file and you should no longer have this issue.

Thank you,

I’ve found that any time I’ve had the hdparm: ioctl 0x304 failed: Inappropriate ioctl for device issue, it’s not necessarily a driver issue, though it could very well be one. However, check your PXE file.

Make sure that the web part of the pxe server: does not look like this:
10.0.7.1/fog

Make sure you add the trailing slash otherwise you’ll see this issue.

On the same note, make sure your FOG Settings Page :
FOG Configuration (? Circle Icon) -> FOG Settings -> Web Server section -> Web Root also has the trailing slash as this is used to create the boot file for the hosts when tasks are setup.

Hopefully this helps.
[COLOR=#000000]10.0.7.1/fog/[/COLOR]

so no luck so far with Single Disk, Resizeable. It feels like it’s not making/rewriting after upload a copy of the mbr. For UEFI this shouldn’t be required, but that’s a different story. 105906 is the right start point for part 2. Remember I’m nobody so I was just testing different things. Maybe force the file to copy the mbr before resize, then resize image/upload, then resize back and write mbr back?

I know that’s a lot, but the script could do it all. I just don’t know where to begin.

Thanks,

I think I’ve found out the issue to the single disk, resizable not operating. I believe it’s due to the start of the 2nd partition being input improperly. It is set in the init.gz /bin/fog file as part2start=105906 but in actuality, the part2start could be found by the fdisk command, hence making it operable for, basically, an windows ntfs system. fdisk -lu will output the partitions in their sector start/end positions. This might help us out a little, maybe. I’ll do some more testing before posting results.

AHCI Drivers wouldn’t create the problem necessarily, though many people opt to keep the BIOS setup as IDE. I haven’t seen any issues with either.

I have played with FOG and Sysprep, and I found that you can only do sysprep the first time on windows 7 for the Single Disk, Resizeable option to work with 0.32 and your system. The caveat to this is that it will not work after you’ve activated and licensed windows for the first time. Windows will let you sysprep whenever you want, but FOG does not enjoy this.

The way I got around this is by doing the base install. Once it’s at the screen asking you for username and machine name, I do a CTRL+ALT+SHIFT+F3 (just to be safe, I never remember which is the actual combination so I do them all) to drop down into Audit mode. Then I can install all the software I need, updates, drivers etc… Then I sysprep and reboot, right after setting the machine to create upload task. I’ve not had any issues with this method.