Posts made by Szeraax

Start-Transcript -Path C:\$([Environment]::Is64BitProcess).txt
"Is 64?"
[Environment]::Is64BitProcess
$pwd
if ([Environment]::Is64BitProcess)
{
	
	$a = Get-BitLockerVolume -MountPoint C: 
	$a | Out-File C:\file.txt -append
}
else
{
	$arguments = "-ExecutionPolicy Bypass -NoProfile -File temp.ps1 "
	start-process C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\powershell.exe -ArgumentList $arguments -Wait -WorkingDirectory $pwd
}

I know its not pretty, but its a proof of running 64 powershell. In essence, I need the 32bit to launch a 64bit version of powershell. Can’t just run powershell.exe because it goes still into x86.

AH HAAAAAAA

"Is 64?"
[Environment]::Is64BitProcess

Output is

Is 64?
False

This means that the 32bit fog service is running powershell snapins as a 32 version of powershell. If you’ve used powershell recently, you’ve almost certainly been using the 64 bit… cause 32 bit sucks. Doesn’t run modules hardly ever, etc. this is the cause of my problems. All I need to do is get the 32 bit process to run the 64 bit powershell and I win!

Time to test.

I’ve decided to use Snapins as a sort of declarative state configuration (similar to DSC). As a result, my group of computers is scheduled to run all snapins every hour and is starting to make the snapin history page a bit largish. Is the best way to clear that via the database? Or have I missed something that can be done to clear it? Especially automatically would be cool. I’m assuming that I’ll need to make myself a script for cron to run though.

If curious, my configuration does stuff like pulling the Primary User from FOG and making sure that that is the ONLY admin besides the 2 local admin accounts on each computer (adding/removing as needed). Also pulls bitlocker recovery information from the machine if its not already stored in FOG (or will enable bitlocker automatically if not presently enabled when I solve that debacle). You may be thinking, WTF??? And I agree with you. This deployment is interesting and they don’t have domain admin control. Not even GPO control. The office is part of a MUCH larger org, and fog has turned out to be best administrator solution.

Hmmm, something funky.

PS > ls C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\Modules\bitlocker\bitlocker.psm1

Directory: C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\Modules\bitlocker
Mode LastWriteTime Length Name
-a---- 3/18/2017 2:59 PM 302052 bitlocker.psm1

PS > Import-Module bitlocker

WARNING: The names of some imported commands from the module ‘bitlocker’ include unapproved verbs that might make them less discoverable. To find the commands with unapproved verbs, run the Import-Module command again with the Verbose parameter. For a list of approved verbs, type Get-Verb.

PS > Get-BitLockerVolume -Mount C:

Unable to find type [Microsoft.BitLocker.Structures.BitLockerVolumeLockStatus].
At C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\Modules\bitlocker\bitlocker.psm1:483 char:37

• … -eq [uint32][Microsoft.BitLocker.Structures.BitLockerVolumeLockStatus …
  +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
• CategoryInfo : InvalidOperation: (Microsoft.BitLo…olumeLockStatus:TypeName) [], RuntimeException
• FullyQualifiedErrorId : TypeNotFound

Might have found the key:

ls C:\WINDOWS\sysnative\WindowsPowerShell\v1.0\Modules\bitlocker\bitlocker.psm1
ls C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\bitlocker\bitlocker.psm1

Loading bitlocker normally uses system32. But SYSTEM on a 64 bit machine can’t find that path. Doing more testing now.

I’m writing a powershell script to use as a snapin. Works fine as user, works fine as admin, works fine as admin from a -noprofile, works fine from user as -noprofile. I get an error from the snapin when trying to load modules like Bitlocker, Microsoft.PowerShell.LocalAccounts, etc. This happens whether I use the module name, a command from within the module (get-localuser, get-bitlockervolume, etc.), or the full path to the module .psm1 file. I am using windows 10 1709.

The error I get is: the specified module XXXXXX was not loaded because no valid module was found in any module directory
Category info: ResourceUnavailable
FullyqualifiedErrorID: Modules_ModuleNotFound

@sebastian-roth Well, I suppose that we can mark this solved at this point.

Not because it is solved, but because I will just have to wait for a magical time in the future when FOG has support for booting NVMe hard drives decently.

As a follow up from your last comment, with my test hardware (we had to get a new demo computer), clover boots to windows fine without any configuration at all. No panic/freezing. Weird I know. This is the exact same zbook model, just with different ram/hdd configuration. Also, I still cannot get the clover settings file to get loaded, so I am unable to customize the clover menu. Since by default clover lists your boot options and doesn’t have a autoboot timeout, using clover at default settings means that I would have to hit enter on each physical machine each time I boot it.

My solution for now is to make the bios boot to HDD instead of network and then configure the option “WOL boot to network” in order to be deploying.

Thanks again for all your help, and @george1421 too! Y’all are great.

@sebastian-roth Don’t believe so, but I’ll try again to double check. I’ll check in with them. Great idea. Dunno if any of them will know the differences between booting off USB and booting off PXE. Here’s to hoping!

@sebastian-roth

Additionally, I’ve tried MANY different configurations (no options file, manually set options, use options file (can’t get Fog to load the options file)) and EVERY TIME, it has been consistant that boot from USB -> CLover -> WIndows and no panic. Boot from fog -> Clover -> Windows PANIC!.

@sebastian-roth Nope!

If I put Clover on USB, I can chain to windows just fine.

Loading Clover via Fog causes windows to freeze on login screen.

@sebastian-roth

If you have any ideas for me to try, I do still have the hardware and can test.

@sebastian-roth No.

My current situation is that no matter what I do when booting off USB, it boots windows fine and no kernel panic (freeze .5s after logon screen appears). And no matter what I do when booting from pxe (Fog -> Clover), windows 10 still freezes .5s after logon screen appears.

I have no idea what the cause is.

@Tom-Elliott Okie-tay! Closing ticket, marking solved. Thanks Tom!

@george1421 @Sebastian-Roth Ok, now that just not fair!!!

If I ONLY have DriveRoot/EFI/BOOT/BOOTX64.efi on the USB drive and boot it with the default options, it works fine. Default options means that I am not doing any ACPI DSDT flag setting, no CPU flag setting, etc. I copied that same .efi file onto fog! So all that stuff that config.plist was supposedly fixing is now out the window since the USB just works regardless of the configuration set.

So that totally chops up both of the things I was going to investigate next. Thoughts?

@george1421 Ok, I can remove all files from the USB drive except for these two files and have windows boot fine:

DriveRoot/EFI/BOOT/BOOTX64.efi
DriveRoot/EFI/CLOVER/CONFIG.plist

If I leave config.plist in that folder and rename it to new.plist, when I boot to USB, that config file is NOT found. Does this suggest that clover has a hardcoded path it looks for a config under? Maybe we can pass it an argument that tells it where its config is at.

Current things I want to check out:
-Run same settings as what config.plist sets and see if it’ll chainload to windows fine from fog
-Find out if I can pass arguments or get the clover.efi to find the config file that is present

@george1421 Looks like it still worked the exact same.

Clover menu looks the same as when I chain’d from fog. Still get kernel panic after about 1s on windows login screen. When I exit clover and return to efi shell, imgstat shows config.plist with the right number of bytes and default.ipxe at 452 bytes (script)

Going to try enabling some of the options from config.plist to see if I can avoid kernel panic. Also going to try removing extra things from USB to check if there are other external dependancies to just the clover.efi and config.plist.

I would think it best if we figure out how to get clover to read the config.plist, but I am unsure what the next steps to do that would be.

@george1421 haha, I went grepping through /var/www/html and did this exact same thing via ssh before you posted. I made a new menu entry as a copy of $refind

file: /var/www/html/fog/lib/fog/bootmenu.class.php

            'refind_efi' => $refind,
            'clover_efi' => $clover,

and

        $refind = sprintf(
            'imgfetch ${boot-url}/service/ipxe/refind.conf%s'
            . 'chain -ar ${boot-url}/service/ipxe/refind.efi',
            "\n"
        );
        $clover = sprintf(
            'imgfetch ${boot-url}/service/ipxe/config.plist%s'
            . 'chain -ar ${boot-url}/service/ipxe/clover.efi',
            "\n"
        );

And edited /var/www/html/fog/lib/fog/service.class.php

            'refind_efi',
            'clover_efi',

From my test of this and via running the EFI shell manually, config.plist downloads fine. However, the clover boot menu looks totally different when booted from the USB, suggesting to me that when I exit to clover from fog, it is still not reading the config.plist file (which changes graphic modes and other settings that obviously work). imgstat looks good, etc.

I am going to try adding the exit type with a different name via the web UI as you suggest and report back.

I have no idea if they are from me or from fog install script or other, but my /var/www/ has:

fog (symlinked to html folder)
fog.ori
fog_orig
html

and the html sub dir also has

fog
fog_orig

So what gives? Am I the idiot that made all of those during some testing once upon a time? Or are they intended to be there? Can I delete them all?

@sebastian-roth @george1421 So if I put clover on a USB drive and boot it with the default config.plist, windows starts fine and seems to have no issues. It may just be that we need to transfer the config.plist with the efi file and that exit type would work great.

@george1421 Regarding your statement about booting rEFInd into a command shell via USB, I think I can probably do that fairly easily. What commands would you want the output of to get a better idea?

Of course, the fact that fog can do single part, resizable imaging on this computer means that it must not be TOO crazy of hardware otherwise I wouldn’t be able to see the disk and such.