Posts made by george1421

@imagingmaster21 For debug mode, you need to terminate the current task that is running. Since imaging didn’t complete then the previous task didn’t close out.

When you schedule a new task. Just before you hit the submit button there are a few options you can choose for the job, like wake on lan or debug. If you click debug and then submit the job, when you pxe boot the client it won’t start image capture right away. This is what we want.

But now that I see you are using virtual box, let me look through the settings to see if something is obvious.

We’ve been tracking a bug in 1.4.4 that is giving unpredictable results on an upload. We are not sure if its a Windows change (as in CBB 1703) or something in 1.4.4. Since this system is not in production yet, I wonder if we could get you to update to FOG 1.5.0RC9. This is a development release of FOG 1.5.0 that hasn’t been released yet.

Actually, before we go down that rabbit hole, since your error is a bit different than the other ones, I’m wondering if you could do the following.

1. Cancel this upload task.
2. Create a new upload task, but before you submit it, press the debug check box.
3. PXE boot the computer
4. After a few screen fulls of information, the target computer OS [FOS] should drop you to a linux command prompt.
5. key in the following command lsblk and post the results here.

Also just for completeness. Can you tell us a bit more about the target system?

1. Hypervisor used,
2. EFI or BIOS (legacy mode).

@psycholiquid Pssst… to adjust the small font size try this FOS kernel parameter vga=792

vga=792 should be 1024x768x24 video mode, and clean your monitor, please!!!

ref: https://unix.stackexchange.com/questions/71231/grub2-and-kernel-vga-parameter/114980

@ch3i Yes that process will work to upgrade to the dev branch where the RC’s live.

Well you have quite a few options here as we can probably make the ability for you to image using your current business network or if you insist have an isolated imaging network and then as you mentioned have a second nic connected to your business network. Both setups can be done.

I would have to ask you a few questions.

1. Does your target computers need to connect to AD during the imaging process?
2. Do you have a conflicting dhcp or pxe booting configuration on your business network (i.e. your voip pbx needs pxe booting to configure your voip handsets but fog requires its own pxe settings)?
3. Do you need an isolated imaging network to avoid overloading your business network during imaging?
4. Will you use the fog client for post imaging system management?
5. Do you have a mix of bios (legacy mode) and uefi systems in your environment?

Can we get one of you guys to install the RC9 release of FOG 1.5.0 to see if the issue has already been addressed? The process is this to update to an RC release.

If you don’t have the local install files, use git to pull them down using this process.

sudo -i
git clone https://github.com/FOGProject/fogproject.git /opt/fogproject
cd /opt/fogproject
git checkout dev-branch
cd bin
./installfog.sh

If you already have the git install files on your fog server then do this

sudo -i
cd <where_ever_your_install_files_are>
git checkout dev-branch
cd bin
./installfog.sh

Now when its time to switch to the stable branch once fog 1.5.0 stable has been released you will do this:

sudo -i
cd <where_ever_your_install_files_are>
git checkout master
cd bin
./installfog.sh

Telling git to checkout the dev-branch or master is the key to switching to an RC release.

I must warn you that upgrading to 1.5.0 is a one way street. If you upgrade you can't roll back to 1.4.4 because of the gui changes. So consider this well. 1.5.0 RC9 is stable and works well. You shouldn't have any concerns about updating.

Well first the bad news, the OEM EULA doesn’t allow you to create a master image and then replicate that image to multiple computers. That is not allowed. You need to purchase a Volume License Key for that. You are only allowed to install the OEM version from the original OEM media unaltered.

The better news is that you only need to purchase 1 volume license key per OS version you plan on cloning. For example, if you want to deploy Win10 pro and Win10Edu, you need 2 VLK keys regardless of how many of each you want to deploy. You need this vlk key if you want windows 10 to activate. MS changed this to protect against OS pirating.

@smcadm said in HP X360 11 G1 EE:

HP ProBook X360

It looks like that probook has a built in ethernet adapter (a good thing) that is based on a realtek chip (Realtek RTL8111HSH). So at least you should have a network adapter that is supported for uefi pxe booting.

I don’t know the HP models, but do you need to enable uefi pxe booting in the firmware? On the Dells, pxe booting must be enabled in the firmware for uefi mode.

It sounds like this isn’t a FOG issue since the notebook isn’t getting an IP address at all. What device provides your dhcp addresses on your network?

When you open the scheduled tasks view the web gui stops. When that happens please inspect the apache error log via the linux console on the fog server. The apache error log is located in /var/log/http directory. Just tail that file and post the error here, please.

@abrowning just for clarity, there is an issue between the linux kernel, uefi mode, and Dell systems using the intel sata adapter when the sata adapter is in “raid-on” mode. Switching the sata adapter to achi mode will (mask) the issue. This is a documented linux kernel issue and not specifically a fog issue. Commercial linux distributions suffer from the same issue.

@psycholiquid Just search the tutorials forum I have a few posts out there about dnsmasq.

First of all, great job on the documentation. The more we know and share the more we ALL will know.

Second I looked into the MS dhcp server and it doesn’t look like (on the surface) we can use uuid to set a policy event.

I did think of 2 alternates that might work.

1. Use the mac address to help identify the client. The first 6 bytes of a mac address is the nic vendor manufacturer number. We can key in on that element when creating a dhcp policy.
2. Give up on MS Dhcp server delivering pxe boot information to your network and use dnsmasq on the FOG server. DNSMasq will be configured to only provide pxe booting information only. IF the fog server goes off line for some reason, there is no harm since the clients will just bypassing pxe booting. A current version of dnsmasq (2.76) supports the advanced stuff you are wanting to try.

These are only 2 alternate ways I can think of to give you the answer you seek. You DO have a functional solution right now so just keep these ideas in the back of your mind.

OK so now what I would do is see if you can identify the hardware by the uuid value? For example a surface pro 3 has a uuid of xxxx, pro 4 yyyy, hp (whatever) zzz. Once you have that, looking at the fog wiki page you should be able to create additional test conditions like with the arch 7, 9, whatever. And then combine them into a new policy like in step 6. That new policy may be arch7 and uuid xxxx == file name aaa (sorry about all of the abstractions but I don’t have a solid answer just yet). It seems logically like it should work.

@psycholiquid said in BIOS and UEFI Coexistence HP 850 G3 i219v nic:

Option: (60) Vendor class identifier
Length: 32
Vendor class identifier: PXEClient:Arch:00007:UNDI:003010
Enter the above in the vendor class all the way to the UNDI just breaks it and the client defaults back to the default efi file in DHCP.
Example of Surface Pro4:
Option: (60) Vendor class identifier
Length: 32
Vendor class identifier: PXEClient:Arch:00007:UNDI:003016

Warning: I don’t have an immediate answer to your situation, but first I have 2 comments.

1. The wiki doesn’t need to be fixed, in a way its not wrong. It just doesn’t cover what you are trying to do because its beyond the scope of the fog project. (snark not intended here).
2. I do have an issue with the wiki because its using the wrong measuring stick to come up with an answer that just by chance happens to work. The UNDI bit of the vendor class (i.e. UNDI:003016) actually describes the UNDI (Universal Network Driver Interface) version with the first 3 bytes being major version and the last 3 bytes being the minor version. So to translate my example above that is UNDI version 3.16. Its highly likely that multiple hardware from multiple vendors will use UNDI version 3.16 in Arch type 7.

Now back on point.
What would be more telling is if the hardware vendor filled out dhcp option 97 UUID. That is intended to be a unique hardware identifier value. Unfortunately the use of and how its used is up to the hardware manufacturer. I can tell you Dells use this field consistently.

So you might ask, in the windows realm how to do I know what the hardware manufacturer is using? Your fog server (or wireshark) can help you understand by eavesdropping on the pxe booting process of your target hardware. If you follow these instructions: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue you can capture a pcap of the pxe booting process. That pcap can either be reviewed by you using wireshark or you can upload it to a google drive and share the link with us and we can tell you if there is something unique about the hardware. The only requirement is if you us the fog server, the target computer must be on the same subnet as the fog server so tcpdump can see the pxe booting process.

Once we know if the dhcp option 97 is unique for your hardware then we will have to see if we can make windows dhcp server add a second filter to say if its arch==7 and uuid == xxxxxx send file name yyyy. That part still needs to be worked out. But without knowing if the uuid value can be used the second part is not useful.

@tom-elliott While I’m not sure what I can add to this thread, I do have to say I have several 4K sata drives that were purchased before I realized that ESXi didn’t support 4K drives (yet). If you need me to test anything (under linux or ms windows) I have the facilities to do so.

@sebastian-roth Bump back

I did come across an old linux project I worked on years ago. Here is how they presented the overlay fs for their rootfs .

@tom-elliott said in Changing fog server IP address problems:

Notice how there’s no hostname?

Great eyes, I just saw that too. That is the key to why it’s not working.

@xcvtop Rats!! I thought it would have given a bit more info than what is displayed on the screen.

During the execution of the installer, it writes an install log into a directory in the same directory as the fog installer installfog.sh There should be an error log in that directory as well as an install history for each version of fog that has been installed. Look in the error log there to see if we can understand why it had an issue backing up the database.

Hint: If you us putty from a windows computer to connect to the fog server it might be easier to copy and paste information.

@x23piracy we can then close the issue?