Posts made by george1421

What version of linux is your fog server running on?

There are 2 ways to go about enabling the dhcp server.

1. Manually install your distribution’s version of isc-dhcp and then using this config file: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Example_1 (I like this method the best).
2. Fiddle with the .fogsettings file and update the following 2 values.

        dodhcp='N'
        bldhcp='0'

to be

        dodhcp='Y'
        bldhcp='1'

Then rerun the fog installer. The fog installer will use the previously saved answers in this file every time you run the installer.

I just found this link in another thread: https://forums.fogproject.org/topic/10556/failure-to-expand-shrunken-resizeable-image-from-linux-machines It appears to discuss your problem too. The solution is to either upgrade to 1.5.0RC9 or keep working with 1.4.4 stable until 1.5.0 stable is released.

@bigredcherokee I’m not sure what to tell you. If you followed the process I outlined and then reran the installer at the end it should be working.

That process will be consistent when you upgrade next time. That is why we need to be sure to fix everything based on the .fogsettings file. You can change the password to what ever you like using the process, but its best to just let the fog installer pick a complex password for the service account and then not touch it afterwards.

I’m glad you have it working now!! Well done.

@bigredcherokee That’s very strange. The fog installer should set the linux user fog back to what ever value IS found in the .fogsettings file. password should have never been the default password for the linux user fog.

@aksl Just interested to know if the 3020M, since you are in uefi mode, what is the disk configured as? Is it achi or raid mode? There IS an issue with linux and uefi and raid-on mode with most hardwares.

If you use your postinstall scripts to do different things and not the fog client you have some options. You can also use the fog client to do some things but you may need to use persistent groups to set some default actions. (yes I know I’m talking in circles. The answer depends on how you are currently going about it.) You will have the most flexibility if you use the post install scripts to connect to AD.

With your post install scripts you do have access to FOG run time settings. So you can craft your post install script to act differently depending on image name, or values of custom fields like primary user, other 1 and other2 fields. Based on the values in those fields you can alter the client’s behavior during oobe by updating the unattend.xml file, or adding or changing the setupcomplete.cmd file dynamically. The thing to remember is that the postinstall script runs in linux so you can’t run applications or interact directly with the windows environment. You can only install “things” that windows will find during installation.

You could append to the section of the unattend.xml script to create users during oobe. That way they will be created before your setupcomplete.cmd file is run.

@markus1204 With FOG there are 2 parts to the images. The first part is the raw data files stored in /images/<image_name> (this is what you have today). The second part is the meta data that is stored in the data base (what you are missing). If you know the settings you can manually recreate the meta data by filling in the proper settings to point to the raw physical files you have in /images/<image_name> directory.

@aksl

1. As long as next server points to your fog server that field is correct.
2. The BIOS name is correct.
3. You should probably add in uefi 32 bit of i386-efi/ipxe.efi
4. And finally uefi 64 of ipxe.efi

Is the source image LVM based? AFAIK you can’t resize (or more correctly fog can’t) resize a disk that has been created as LVM. FOG should have copied it as raw partitions. You can test this by deploying to a disk bigger than the source disk. Does the new target use the entire disk or is it constrained to the same allications as the source disk?

@bigredcherokee Well my google-fu is failing me right now so I’ll have to retype it. Screen shots are not required at this time. Unfortunatly this is a common occurrence (reusing the fog system account for other purposes).

1. Login with another user account that has sudo rights.
2. Inspect the file /var/fog/.fogsettings (its hidden)
3. Collect and document the value of password in the document. That is the password the fog account should be set to.
4. Reset the linux fog user account to that password defined in step 3. You will use passwd fog to reset the account. Hint: If you log into your fog server using putty you can copy and paste text much easier than using the linux console.
5. From a windows computer confirm that you can ftp to the fog server. Login with the user fog and the password collected from step 3. If successful proceed to the next step.
6. Goto the FOG Web gui and FOG settings. Ensure the user ID in the tftp section says fog and the password matches the value collected in step 3.
7. Go to the storage node configuration for this FOG server. Ensure the management id is fog and the management password is the same as you collected in step 3.
8. Now go back to the fog server linux console and rerun the fog installer (./installfog.sh) to realign the remaining bits.
9. Done.

@bigredcherokee To avoid issues in the future, I would surely use a different user account for system administration. Let me get the process to fix this.

Have you or do you use the linux user fog for system administration and/or changed the password to the account? If you do that is the root of your problem. We can get you back in sync, but you will need to use another user account for system administration.

@taspharel said in FOG with UEFI - rEFInd Error: Failure booting legacy (BIOS) OS:

, I would prefer to use UEFI since it allows me to use the TPM in order to Bitlock

I don’t know this is mutually exclusive. I know with our dells, the TPM chip is active in even Win7. We don’t currently use bitlocker so I can’t say for absolute if there is another requirement beyond that. But TPM is functional in Win7 even in bios mode. I can say for sure that secure boot does require uefi mode.

Off-Topic: In regards to this, I would create each arch type listed on that document. It will save you headaches when you get new hardware. But I can say 90% of the time your hardware arch type will be 0 for bios and 7 or 9 for uefi.

@taspharel First the non-point bit. If your dhcp server is a windows 2012 or newer then you can use this process to make bios/uefi booting a bit more dynamic: https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence just follow the Windows section.

Please understand that bios (legacy) mode and uefi mode are two different critters. Hardware access is different between the two. If your hardware is in uefi mode then you MUST load a uefi based operating system. That counts for FOS, linux or windows. Once you load a uefi operating system you can’t switch the firmware back to bios mode. If you do the system will not boot. In my case I have one Win10 reference image captured in bios mode and one Win10 image captured in uefi mode for deployment.

Now in the case of FOG it uses two different exit modes to chain load the target computer OS when exiting from iPXE. For the bios mode the default is SANBOOT, which works pretty well for most situation. For uefi mode computers rEFInd works the best. Using rEFInd as an exit mode for bios computers won’t work well.

What hardware are you having difficulties with?

First the off-point question. What do you use as your dhcp server? There may be options to have your dhcp server automatically switch between the uefi and bios iPXE boot files. That would address your pxe booting issue.

The second for rEFInd. rEFInd should work well for you but only fur UEFI systems. You should set the default for bios mode to SANBOOT. When trying to boot a uefi system and its not finding the hard drive, you may want to update the refind.conf file by enabling this parameter.

scanfor internal,hdbios,external,biosexternal

From the default scanfor setting. Set uefi deep scan back to default. See if that improves your results.

@aziraphale OK then we might have a path forward. Understand I haven’t had to do this before so there may be something that will go sideways on us.

But the concept with split horizon dns is to create an A record entry in each dns server. On the dns server on the staff network you will create an A record fogserver.domain.com (or whatever name you choose) that points to the nic on the staff network. You will do the same for the students network. That A record for fogserver.domain.com will point to the nic on the students network. That way a client on either network will always resolve to an interface on the right network.

Once that is setup now you need to get in and tweak the FOG configuraiton. Anywhere in the FOG Settings that refer to an IP address you need to replace it with fogserver.domain.com. Also in the storage node configuration for your FOG server, replace the fog server IP address with its fqdn name.

Now there is one other place you will need to edit by hand. In /tftpboot/default.ipxe exchange the fog server IP address with the fqdn name.

Understand this setup is not supported by the FOG Project and the next time you upgrade your fog installation, the installer may overwrite certain configurations for you. Most will stay the way you put them.

Now the only gotcha here is that there are some pxe boot roms that that are pretty dumb and will not translate the fqdn name to an ip address because they ignore DNS resolution. You are going to have to try it to see how well this setup works for you. It may be just as easy to setup a second fog server on the students network so you don’t have to deal with this complexity.

Since you have isolation between your staff network and your student network, then you can configure something called a split horizon DNS.

Now for the questions:

1. Can we confirm that each network has its own DNS server?
2. Is there any type of routing between the staff network and the student’s network?

I agree this is a hardware “issue”. You probably can ignore these messages. or set the kernel parameter to disable ACPI commands (which appears to be the root of the messages above).

Also this issue may have been addressed by the hardware manufacturer. Make sure the firmware is up to date on this system.

@tom Well I would start out by changing that value of bzImage412 in FOG_TFTP_PXE_KERNEL back to the default of bzImage. Then reboot your target computer and see if you can register it.

@tom Well as they say… There you go. You found the smoking gun.

Did someone try to create a custom kernel for some reason?