@mandrade I’m glad you settled on a solid choice here.
The thing you have to remember is the fog 1.2.0 is almost 3 years old. The devs have put great effort in getting the trunk build to the point it is today at the expense of delaying the official release of 1.3.0. They felt it was vital to build support for Win10, uefi support, and gpt disks into the trunk build since 1.3.0 is the last (intended) release of FOG until FOG 2.0 comes out.
@Wayne-Workman I agree. You can’t play with the format (sizeable vs non-resizable) once the image has been captured. If you capture it resizable you must deploy resizable. The same for non-resizable capture.
@SteveB689 OK so this is just research then. Fair enough.
I’m sorry you had so much frustration setting up FOG. I know it is a complex environment especially for those coming from a purely MS Windows background. Hopefully you found the support you needed in the FOG forums.
On a positive note it sounds like Arrowhead-IT has personal experience with this hardware so you have someone that already went down the path you are on.
@MikkyMike Just for clarity, FOG 1.3.0 has not been release yet, but the release canidates have, you can follow this procedure on either a new system or an upgrade to bring you up to date. https://wiki.fogproject.org/wiki/index.php/Upgrade_to_trunk
Cross linking post: https://forums.fogproject.org/topic/7851/intel-raid0-image-capture
We now know what is going on with this and there is a work around pending.
Yes, in short you copied the files but didn’t update the database on fog sever 2. If you go into the image management on fog server 1 and then use the export function to export the database into a file, then from the same browser go to fog server 2 -> Image management and then import the image database into fog server 2 you should be all set.
If you put a dumb (unmanaged switch) between the HP Probook 650 and the building switch does it pickup an IP address?
The trouble sounds like the FOS engine is not picking up the dhcp address (which could be a driver issue or something else). If you schedule a debug deployment (select debug when you schedule a task). Does it pickup an IP address after a bit from the command prompt ip addr show?
If you have one of these target computers already running windows, can you get the vendor and hardware ID of this NIC?
@THEMCV First understand this this script won’t copy and paste correctly. For some reason the FOG Forum pages eat the spaces around the conditional tests, but I wanted to get it out here for viewing. I’ll upload the file in a minute.
Tom: the only question I have is if NO partitions match will the test if [[ ! $? -eq 0 ]]; then still trap it?
#!/bin/bash
. /usr/share/fog/lib/funcs.sh
[[ -z $postdownpath ]] && postdownpath="/images/postdownloadscripts/"
case $osid in
5|6|7|9)
clear
[[ ! -d /ntfs ]] && mkdir -p /ntfs
getHardDisk
if [[ -z $hd ]]; then
handleError "Could not find hdd to use"
fi
getPartitions $hd
for part in $parts; do
umount /ntfs >/dev/null 2>&1
fsTypeSetting "$part"
case $fstype in
ntfs)
dots "Testing partition $part"
ntfs-3g -o force,rw $part /ntfs
if [[ ! $? -eq 0 ]]; then
echo "Skipped"
continue
fi
if [[ ! -d /ntfs/windows && ! -d /ntfs/Windows && ! -d /ntfs/WINDOWS ]]; then
echo "Not found"
umount /ntf >/dev/null 2>&1
continue
fi
echo "Success"
break
;;
*)
echo " * Partition $part not NTFS filesystem"
;;
esac
done
if [[ ! $? -eq 0 ]]; then
echo "Failed"
debugPause
handleError "Failed to mount $part ($0)\n Args: $*"
fi
echo "Done"
debugPause
. ${postdownpath}fog.drivers
. ${postdownpath}fog.ad
umount /ntfs
;;
*)
echo "Non-Windows Deployment"
debugPause
return
;;
esac
@Wayne-Workman I don’t happen to have a vm template of centos 6 any more, but I can spin up a new vm tonight with centos 6 on it and test.
BUT my recommendation to the OP (for what ever its worth), if they have a virtualization environment I would spin up a new Centos 7 vm and then install 1.3.0-rc2 on it clean. Yes that will mean that they will have to recreate the FOG environment all over, a lot can be done by copy and pasting and then transferring the /images directory over. So it will be some work to do. BUT what it will give you is a fall back system in case of difficulties with the new version of FOG. If the new FOG server falls down the old one is still there, all you need to do is power it on.
With that said, I can spin up a new centos 6 vm tonight and see if fog 1.3.0-rc2 installs without any monkey business. Understand this will not be an exact match for the OPs environment since the OP is upgrading fog from 0.30.
@Wayne-Workman has a script for a mobile fog server that should do what you need.
@dustindizzle11 Its not clear in my mind, is it time that fixes the issue or manually bringing up the interface?
If its manually brining up the interface (or time for that matter), you “could” create a custom init.xz (i.e. init_asus.xz) that executes the ifup command during the initialization stage of the FOS Engine startup. Then assign this new init_asus.xz to those systems that have this mobo installed. Its not the cleanest solution but then at least you could automate system imaging with this kind of mobo. If you know what needs to be done the actual update will take you about 15 minutes to copy and modify a new init.xz and push it out to these clients settings in the FOG gui.
[edit] changed "15 minutes to create a new init.xz " to "15 minutes to copy and modify a new init.xz " to give a better understanding of what must be done.
If you are trying to connect to the FOS engine (the high performance customized linux OS that captures and deploys images on the target computer)? If so you can’t ssh into it without FOS being in debug mode. If its in debug mode, and you set root’s password then you can ssh into FOS.
@egregers What I would recommend (along with what Tom posted) is to pxe boot into the FOG iPXE menu and then run the compatibility tests. This will confirm that the FOS Engine can see the local hard drive. This compat test will tell is where the problem isn’t. (FYI, since you are upgrading from 1.2.0 to 1.3.0 the background of the FOG iPXE menu will look different)
@Wayne-Workman said in Replicating drivers across FOG servers:
Two approaches here.
Create a fake image and make its path
/images/driversand setup the fake image so it’s shared with the other servers via groups or whatever way you have the images set up.
This is the option we use. You should also be able to set this “fake image” to disable so someone won’t try to deploy it, but enable replication so the drivers will be sent to the remote fog/storage nodes.
@george1421 Can we actually get a screen shot of what is going on just before the kernel dump? The question is 3% of what? Booting FOS, partclone pushing the image to disk? A picture of the screen just before the 3% would say a bit more about the context of the system before the kernel blows up.
for a deploy ensure that /images contains the mntcheck file too.
@egregers said in Are PCIe ssd hard drives on client machines supported?:
@Tom-Elliott
Should we use the AHCI instead of raid for FOG? Will FOG not see it when Raid is on.
At this point no. We can use that as a fall back stance. But that will require you to reinstall the OS on that computer to be able to capture and deploy in achi mode.
(Understand I’m not speaking for Tom here, but I’d like to see you do this).
checkedfdisk -l and lsblkFor the output of the commands, you can either retype what is on the screen or post a clear screen shot taken with a mobile phone.
@Sebastian-Roth Is there any chance that an older kernel will work here? I’m going to assume that both Mint and Kali are using older kernels that do work (which may not be a solid test since @Wirefall is not pxe booting either OS platforms).
There is a lot of details here, but I want to clarify.
As you noted, the i8042 error is not an error, just a warning. So not an issue here. I’m going to guess your network adapter is not supported by the FOS kernel of 4.1.2. We can try 4.8.x to see if that will work. But if your systems use uefi firmware, gpt disks or NVMe disks you will need to upgrade to FOG 1.3.0 to get that support.
@ttrammell If your fog server, dhcp server and pxe booting client are on the same subnet we can use tcpdump to capture the pxe booting process to see if you are getting another dhcp offer packet.
sudo tcpdump -w output.pcap port 67 or port 68 or port 69 or port 4011