Workstation does not reboot after imaging
-
What’s the formatting for adding more than one arg?
try the fourth option of a space between the variables.
-
@george1421 I’d put money on you being right. If your theory is correct and it “internally switched it self back to bios mode”, there is no evidence of this in the BIOS; BIOS shows UEFI with legacy boot options disabled. I have an E5450 and a 5590 in front of me and both show UEFI yet they were imaged with the method I described. Furthermore, what lends credence to me thinking these are booting UEFI, we don’t see the Windows logo on boot like you do with a BIOS boot, we get the Dell logo with the hula-hoop of circles then the logon screen.
-
@george1421 @Sebastian-Roth thank you both so much. I am heading home for the night and will pick this up again tomorrow and report back. I have started toggling through the reboot= options, though I put them in the universal Kernel Args settings under FOG Configuration > FOG Settings > General Settings > KERNEL ARGS since the hang is happening to all of our active models. reboot=efi made the screen vomit and ended in “Fixing recursive fault but reboot is needed!” I’ll try some more options tomorrow to see what I get. I have provided a screenshot to better flesh out what I mean by vomit
-
@george1421 Let me start off by offering my apologies for sending you down a rabbit hole regarding BIOS/UEFI image capture. I looked through the procedure and found the images are being created in VMWare as UEFI, then the sysprep, shutdown, boot to BIOS, change to Legacy boot then capture. From there, we deploy to the physical workstation with legacy enabled, then switch to UEFI on first boot. So you are absolutely correct; our images are being created as UEFI. I was going by memory from a year ago and should not have wasted your time.
@george1421 @Sebastian-Roth I have begun toggling through the reboot= options because I won’t sleep tonight unless I have tried each one. So far reboot=warm and reboot=hard leaves the system hung at restarting system and reboot=efi giving an actual error as shown in the previous post.
-
@george1421 @Sebastian-Roth Well, I used all of the reboot= options and they all had the same results; HOWEVER, it lead me to remove acpi=off from KERNEL ARGS and it fixed the problem with it hanging after the post install script! So that one is fixed.
I am still having a problem with the 5500 stopping at the blue “Just a moment…” screen with the hula-hoop of circles spinning around. So far none of my other machines are doing this. After about 15 minutes, the screen goes black, so I thought it rebooted, but it turns out the laptop display just went to sleep. Gesturing on the touch pad wakes it up to “Just a moment…”. Alt+Tab produces no results. If I hard power off from here, the workstation does boot into the OS, but SetupComplete.cmd never runs. I don’t have anything other than a network cable and a power adapter plugged in (non-USB-C) Any thoughts?
-
@greichelt said in Workstation does not reboot after imaging:
I am still having a problem with the 5500 stopping at the blue “Just a moment…”
What drivers are you installing in your base (golden) image? I’m wondering if there is a Windows driver that is almost compatible but not really. If you are using a post install script and the pnputil program to inject the drivers into the image, that would come at almost the end of the OOBE process. Where its hanging I believe is at the very beginning of OOBE. But I don’t have any basis to say. With sata drives, when it would hang like this, I would pop the sata drive out and add it in as a second hard drive in another computer. In that second computer I would look at the log files in the c:\windows\panther directory to see where it was hanging. Not sure how to do that with nvme drives.
-
@greichelt Great to hear you were able to figure out what was causing the reboot hang on the machine. Maybe you can put in the kernel parameter
acpi=offonly for the machines that really need it. Probably someone added it for a good reason. But doing this as a general option caused some/most to hang…Would you mind opening a new topic for the hang on first boot issue? We try to keep things a bit organized so other people find answers more quickly and might be able to help themselves. I will mark this one as solved now. If you open a new one, I can move your last to posts over to the new one.
-
To elaborate, I recall acpi=off being useful for rather old machines (who’d often have buggy implementations), but the exact opposite for newer machines who rely upon ACPI.
-
@Sebastian-Roth Doing it now. Thanks again.
-
@george1421 George, at @Sebastian-Roth 's request, I am opening a new topic for this. To answer your question, we install no drivers in our golden image, not even VMware tools. Whatever drivers are installed are included in the Windows 10 1803 base install.
-
@george1421 I setup dnsmasq as you have suggested as I was not able to get my VMware VMs to EFI PXE; however, I am getting the as shown in the screenshot below when I legacy boot. EFI no longer functions on my working Dells. I am using Ubuntu 16.04. My FOG server is 172.31.0.2 (I updated all 5 entries in the script in the link you provided). I’m not sure where to go from here.
-
@greichelt This one is an interesting one because it looks like all of the bits are in the right spot. But something is off in the config file. No worries we can get this sorted pretty easily. I know the config file if used exactly from the tutorial works perfectly. There are some boot roms that need an additional tweak but I haven’t come across those systems in a few years.
There is two things I need.
- Post the entire ltsp.conf file here
- If the lstp.conf file doesn’t give us the clues I have another tutorial that we can capture the pxe boot process: https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue I can either tell you how to decode this file with wireshark or you can upload it to a file share site and post the link here. Once I review the file you can take it down from the file share site.
-
@george1421 Thank you so much for the quick reply. I figured this part out. I ran sudo apt-get install dnsmasq and didn’t really pay attention to what was going on. It told me the latest version for LTS 16.04 was already installed, so I was still on 2.75. After a bunch of googlefoo, I check the version with dnsmasq -v and saw my error. I followed this - https://wiki.fogproject.org/wiki/index.php?title=ProxyDHCP_with_dnsmasq and installed 2.76. Now, it’s working! This unfortunately broke DNS lookups on my FOG server and I’m not sure how to fix it. I can ping 8.8.8.8 and get a response, but can’t nslookup.
-
@greichelt On your fog server itself, there is a config file
/etc/resolv.confthat file should list your name servers (DNS servers) used for the fog server to do name lookups. A quick google-fu will show you the parameters needed for that file. Typically on ubuntu that file is managed by the network manager application. Just be aware of that because it may overwrite any settings you add. For the network manager application that is typically an application on the tool tray that deals with network configuration (sorry I’m a rhel guy, so I can’t give exact instructions for ubuntu).
