@nrey What version of Ubuntu are you running?
Have you tried rerunning the installer since?
@nrey What version of Ubuntu are you running?
Have you tried rerunning the installer since?
@DBCountMan If I recall correctly, this is on purpose. It’s been a while since I looked at it, but we set LDAP users to a specific set of identifiers and filter those out of the view because things you can do with local users (change password, etc…) you should not be able to do with LDAP based users.
@xsibit666 We don’t have a specific procedure per say:
https://docs.fogproject.org/en/latest/management/web/storage-node/
shows you how this can be done. In high level at least.
What can you use:
https://wiki.fogproject.org/wiki/index.php?title=Location_Plugin
While the documentation is outdated, it’s relatively unchanged from version to version beyond keeping operationally.
@jmeyer Some “drivers”, of which I’m guessing you’re using ipxe.efi as the boot file?, use a “firmware” injection methodology to load the device. This firmware approach can change - usually temporarily or until another driver forces the overwrite of that segment of the firmware ROM - cause a change.
I might suggest, changing the ipxe boot file to be card specific if possible. This should help prevent this flipflop sequence after booting.
Similarly, For this one device, does Exit Type: EXIT produce any better results?
@sopinv Deploying images, is exactly what the queue is for. Registering is just data entry into a database.
In what sense do you want:
“Only 10 computers are ever allowed to be registered on this server”?
That’s where I think we’re getting confused.
As for registering, again, this is data entry. What I think you’re asking for is, if there’s 10 tasks, and somebody else boots in, don’t allow registering the system…
The thing is the database isn’t that heavily used, so I don’t understand the “why” here.
@Florent For removal of the FOG Client, a connection to the server is not needed.
The only reason it’s needed during install is because it’s communicating to the fog server to get the certificates needed from the server. These certificates are not necessary to remove the software.
@astrugatch I don’t know there’s a script to remove a fog client, but it is just an MSI, so the typical “msiFilename -uninstall” should work
@gabrielzeit IPXE is a 3rd party software. When we say it may not be compatible with iPXE, I believe @george1421 was referring specifically to UEFI.
There are three (main) things to attempt:
snp.efi - SNP standard driver plus a few “custom normal drivers” from iPXE developers.
snponly.efi SNP standard driver, and that’s it. It’s using the SNP stack on the network card itself and that’s it.
ipxe.efi IPXE with standard ipxe built drivers that seem generally good.
As neither of these files seem to be working for you you could attempt to build a firmware specific EFI file such as realtek.efi or intel.efi but this is outside the scope of direction we could possibly give you.
If pxe booting works with legacy, and you don’t mind having a configuration of dhcp that doles out the correct boot file for a specific boot type (UEFI vs Legacy), why not just keep that device in Legacy BIOS mode?
@gabrielzeit https://forums.fogproject.org/topic/10160/virtualbox-pxe-boot-no-configuration-methods-succeeded
Can you please try maybe using the ipxe.pxe for the boot file for these VirtualBox machines?
There is a weird known that warm reboots will not always work with VirtualBox, this isn’t something I or our team can control, but in the past I was able to continually use ipxe.pxe as the medium and things appear to have worked.
@danieln The checksums are at the file level.
This would seem more likely to indicate the node that is consistently ahving issues might be having a failing HD?
@dellborg82 What was the issue? This way somebody else who may be having a similar issue can also be helped?
@dellborg82 Can you look at the event logs and see if anything shows up for that timeframe that the script actually runs.
@dellborg82 I printed the actual code as an image in my post because for some reason the code syntax is joining lines in appropriately here.
@dellborg82 You seem to have a typo, that or because it’s not in code format (triple back ticks) we’re losing context.
Your script should be:
$NetworkPath = "\\starbase\Artemis_Files\Artemis Versions\Mod\Artemis 2.8 TNG Mod"
$LocalPath = "C:\Artemis 2.8 TNG Mod"
$username = "starshipfrontier\wbadmin"
$password = ConvertTo-SecureString "USSWhiteBuffalo33247" -AsPlainText -Force
$creds = New-Object System.Management.Automation.PSCredential $username, $password
New-PSDrive -Name "S" -Root $NetworkPath -PSProvider "FileSystem" -Credential $cred
If (-Not (Test-Path $LocalPath)) {
Write-Host "Creating $LocalPath" -ForegroundColor DarkCyan
New-Item -ItemType Directory -Force $LocalPath
}
Write-Host "Copying Artemis to Local Computer" -ForegroundColor DarkCyan
Copy-Item S:\* -Destination $LocalPath -Recurse -Force
Write-Host "Copy Complete" -ForegroundColor DarkCyan
Remove-PSDrive -Name "S"
Why it’s not showing the full appropriately lined strings I don’t know.
@anwoke8204 I believe this is because your script is logging into a network share that may not have machine\system level access.
Snapins run as the local system’s system user account.
When you’re accessing the network location named starbase, that’s the user who needs to be able to access the share drive. Everything else, I believe, should work just fine.
@anwoke8204 Bad HDD on the FOG Server?
@anwoke8204 To @astrugatch as well:
So “Search Base” is where it’s going to begin searching for Users.
Group Base is where it’s going to being looking for all the groups.
Does the Group (your admin group) named fog admins, exist in the OU FOG Access of your domain tree?
Does testuser exist as “fog admins”?