Posts made by Chris Shipley

Thanks for the warning, but that’s not the case. /images does indeed point to the 177G volume here in this implementation. There are about 20GB of data in there, and if you were correct I’d have 30G free on the volume you’re concerned about. We’re good in this sense. I just didn’t check my syntax on the SCP command, which admittedly I rarely use, and pushed all the files into a single filename * when I made the copy command. I’ll update after I get the files in and see if I can get it to work.

Nah, /images actually points to the 177 GB volume

OK wow, it looks like the results of the ls show why, my code for copying was wrong, it put all files into a filename called *. Any way to separate those or do I have to wait for the download to occur again? I was using SCP

[root@localhost Win7Image]# ls -lahRt /images/Win7Image
/images/Win7Image:
total 13G
-rwxrwxrwx.  1 root   root  13G Aug 26 20:58 *
drwxrwxrwx. 13 nobody root 4.0K Aug 26 17:34 ..
drwxrwxrwx.  2 root   root   14 Aug 26 17:31 .

and the other command

[root@localhost Win7Image]# df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   50G  2.5G   48G   5% /
devtmpfs                 1.4G     0  1.4G   0% /dev
tmpfs                    1.4G     0  1.4G   0% /dev/shm
tmpfs                    1.4G   17M  1.4G   2% /run
tmpfs                    1.4G     0  1.4G   0% /sys/fs/cgroup
/dev/mapper/centos-home  177G   19G  158G  11% /home
/dev/sda1                497M  170M  328M  35% /boot
tmpfs                    282M     0  282M   0% /run/user/0

It is, and works fine from FOG 1. Here is a link to the screens that show up to give an error when trying to deploy it:

(this static image also viewable as video here)

I have two FOG hosts at the latest GIT pull. I’m trying to move a single image from server 1 over to server 2. I am able to copy the files fine and I took the steps Tom suggested (in another post to

touch /images/{.mntcheck,dev/.mntcheck}
chmod 777 -R /images

I then went into the FOG Images area and created a new image, pointing it to the new location in /images/Win7Image (this is not the name of the folder from the original FOG 1 server, I’ve renamed this on FOG 2).

This is not an operational image. We get an NTFS resize error when trying to deploy it and it gives no bump to the storage chart on the dashboard (still remains the size before copying) and is missing the data for size on Client.

Any advice on how to troubleshoot this, or properly move files between FOG servers? I’m not looking to replicate all of my images, that’s inappropriate. I just need this one.

Fixing the chain bootloading issue on the other thread i posted here also fixed this kernel panic issue. thank you Tom.

@Tom-Elliott That did the trick, thank you.

@Wayne-Workman Apologies, I’m new to this forum and didn’t realize I’d had other replies below the ones I was responding to. Both of these settings are correct, but thank you for alerting me.

@Tom-Elliott The IP address is fine. Its when the system gets to the chain command in PXE that it breaks. It isn’t loading the chain command correctly. This is a vanilla fresh git trunk install on Centos 7.

@Tom-Elliott using git trunk version. OP says I’ve tried both bzImage32 v 4.6.2 and v 4.5.3

We only have the single installation at this site with Centos 7, new install, git trunk.

I can confirm this happens on a Lenovo Thinkpad W530 as well as the Dell Latitude 3450.

This is also the installation with the problem for chainloading that I am “getting around” by going into the iPXE system and writing my own “chain http://10.10.2.18/fog/service/ipxe/boot.php” command to get to the boot menu. (see here: https://forums.fogproject.org/topic/7879/pxe-boot-issue-video-included)

yes, DHCP is using undionly.kpxe - I don’t actually run any 0.32 versions anymore. The oldest I run is 1.2.0

This might be a problem with the Dell systems I’m trying to image. should i repost in the hardware area?

FOG version trunk as of yesterday. Its a Dell Latitude 3450.

No, unfortunately not. This is a brand new install on a new centos 7 system with trunk - the one you helped fix the install script for. But not an upgrade.

I’ll take a look there, but it appears that the IP address is fine, but the path might not be.

after chain loading boot.php and getting the menu, when I select registration and it loads the kernel (I’ve tried both bzImage32 v 4.6.2 and v 4.5.3) I get a kernel panic.

Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)
Kernel Offset: disabled
—[ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0)

the system halts and i have to hard shut it down, start it up, hard shut it down, start it up and it will boot to the PXE card again.

(PS - not a FOG novice, been using it since version 0.32 but this is the first time I’m using the trunk version)

OK, so if someone can tell me where the PXE subsystem system chooses how to run “chain http://10.10.2.18/fog/service/ipxe/boot.php” then I can update the installation so I don’t have to do this manually.

@george1421 I’m pretty sure that’s a result of the URL being too long for the amount of characters available and it didn’t put it in right. I could be wrong, though. In any event, the storage area didn’t have any folders for iPXE. the TFTP server settings area has a location /var/www/html/fog/service/ipxe/ for PXE kernel location, but when i changed it to just fog/service/ipxe/ there was no difference in behavior.

If I go to the iPXE shell and run:
chain http://ip.fog.server/fog/service/ipxe/boot.php
it will continue and load normally. So i think the path is wrong, where can I change that? In FOG config?

Hey so now that I have my shiny new trunk install of FOG running, I ran into a chainloading issue. I have a video link for the system booting PXE: https://drive.google.com/open?id=0Bykgcf4jRmVeaFNnMDJwLVZYNFU

Here is a screenshot of the final error message (after I set the pause to 10 seconds over 3, heh): https://drive.google.com/file/d/0Bykgcf4jRmVeQjB5eXFBYkt3dm8/view?usp=sharing

The error message reads:
tftp://10.10.2.18/default.ipxe… ok
http://10.10.2.18service/ipxe/boot.php… Error 0x3e11613b (http://ipxe.org/3e11613b)
Could not boot: Error 0x3e11613b (http://ipxe.org/3e11613b)
Chainloading failed, hit ‘s’ for the iPXE shell; reboot in 10 seconds