Black screen when attempting to Perform full registration and inventory on Dell Latitude 5580
-
Just for clarity. When quick registration, and imaging are running you see text on the screen but when you select full registration nothing is visible??
I would also have to question your kernel, where did you get 4.13.4 from? The current newest supported kernel for FOG 1.4.4 is 4.11.6.
-
@george1421 Quick Registration works as expected - text on screen, and host registers. When I do the FULL registration and inventory, the bzImage file loads, then the screen goes to what looks like a blank DOS window with the blinking cursor. Nothing happens for over 5 minutes.
As for the Kernel, I chose to install the latest kernel offered on the Kernel Update page of my FOG install. I copy-and-pasted the versions into the first message, so I assume they were correct.
-
@lukebarone That sounds really weird. Is this on the exact same machine you are trying both quick and full registration or just “the same model”?
See our script code for both methods (ref 1, ref 2) does disk detection as very first step and you should at least see “Using disk device …” in both cases. I cannot think of why this could behave differently on one single machine.
-
@sebastian-roth Good question! Yes, it’s on the same machine. I had one 5580 that I was imaging constantly, and now have my Windows 10 image setup how I wanted. I grabbed another 5580 out of the box, changed the BIOS settings to match the first, then booted from the network. If I choose Quick, it works. If I choose Full, it stalls out. I see no message about a hard drive getting detected on the Full, it is literally a black screen with a blinking underscore-style cursor in the upper left corner.
-
@lukebarone I am fairly sure there is one very important information missing here. If this issue is reproducible (full reg is stuck but quick reg works on the very same machine) then we are still blind on one eye! I’d ask you to take a video sequence of both processes from start (turn on machine) to end (stall vs. reg begins). Maybe there is a difference there that we can see on the videos!
-
@sebastian-roth Since I need to image 43 more, I can certainly accomplish this Monday morning when I’m back at work. How long do you want me to wait at the black screen on Full? Quick happens pretty quick…
-
@lukebarone Don’t take a video of the hanging cursor on full reg. I think it’s ok to start with bootup and stop at the cursor. But you might want to leave the machine sitting there for half an hour (plus send ICMP ping messages to see if it still responds) just to see if it goes any further.
-
@sebastian-roth Well, this was unexpected…
I put up another Dell 5580 laptop, set it to boot from the network card (Legacy), and starting pinging as soon as I saw the IP address from my computer on the same switch. As soon as the “Full host registration and inventory” task starts, the screen does the black screen with blinking cursor, but the pings stop responding! Tested with UEFI Network Booting, and the same result, except no blinking cursor.
Thoughts where to look next? I have left the machine sitting there for 30 minutes, as requested, with no change.
-
@lukebarone I know these are super new, but are there firmware updates for these ? Are you on the latest release?
-
@george1421 No I’m not, I am installing the update now (Thank you Dell for letting us update the BIOS without Windows!)
Reporting back… with the newest firmware released, the same effect is seen.
-
@lukebarone I guess for me this is a bit confusing since both quick registration and full registration boot the same engine, they only run different scripts inside of FOS.
I can show you what the iPXE menu looks like. I know it will not mean anything to you but you can see the kernel parameters are exactly the same except for the last which tells FOS what to do.
:fog.reginput kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=255000 web=192.168.1.53/fog/ consoleblank=0 rootfstype=ext4 mdraid=true vga=792 storage=192.168.1.53:/images/ storageip=192.168.1.53 loglevel=4 mode=manreg imgfetch init_32.xz boot || goto MENU :fog.reg kernel bzImage32 loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=255000 web=192.168.1.53/fog/ consoleblank=0 rootfstype=ext4 mdraid=true vga=792 storage=192.168.1.53:/images/ storageip=192.168.1.53 loglevel=4 mode=autoreg imgfetch init_32.xz boot || goto MENUThe key is
mode=to tell FOS what to do. So I don’t understand why autoreg works and manreg crashes FOS (because you say after bzImage and init.xz are transferred manreg causes FOS to crash. There has to be something more going on here. -
It’s not even making it to the point of “man reg” so
mode=isn’t even in play. It starts loading, and on release it passes it back. Is there a specific sequence that quick reg is going through that full reg is not following?(For example: Cold Boot on full reg, warm boot on quick reg, or vice versa)
-
@tom-elliott As far as I know, it happens every time. Same result on 3 different laptops of the same model/shipment.
-
In case it matters…
/var/www/fog/service/ipxe# ls -lah total 48M drwxr-xr-x 4 fog www-data 4.0K Jan 24 2017 . drwxr-xr-x 3 www-data www-data 4.0K May 31 2016 .. -rw-r--r-- 1 fog www-data 1.1K May 31 2016 advanced.php drwxr-xr-x 2 fog fog 4.0K Sep 9 2016 backup -rw-r--r-- 1 fog www-data 44K May 31 2016 bg.png -rw-r--r-- 1 fog www-data 756 May 31 2016 boot.php -rwxr-xr-x 1 fog fog 5.9M Sep 9 2016 bzImage -rwxr-xr-x 1 fog fog 6.4M Sep 9 2016 bzImage32 -rw-r--r-- 1 fog www-data 230K May 31 2016 grub.exe -rw-r--r-- 1 root root 16M Jul 16 2016 init_32.xz -rw-r--r-- 1 root root 18M Jul 16 2016 init.xz -rw-r--r-- 1 fog www-data 25K May 31 2016 memdisk -rw-r--r-- 1 fog www-data 1.8M May 31 2016 memtest.bin drwxr-xr-x 2 root root 4.0K Sep 9 2016 old -
@lukebarone I realize that my FOG-Pi server has been hacked up a bit but I’m having a hard time connecting the dots here. You say you have fog 1.4.4, but your files are from jul-sep 2016. I don’t know how you have linux kernel 4.13.4. Can you confirm? On my FOG-I server all of the files are from mid to late 2017. From the same directory where you posted the listing, key in
sudo files bzImageand confirm the kernel release. -
@george1421 According to Tom’s post FOG 1.4.4 was released in Jul 2017
ref: https://forums.fogproject.org/topic/10341/fog-1-4-4-officially-releasedI’m only raising the issue because you may have an old install with old kernels causing this strange behavior.
-
@george1421 That’s a fair point! Good thing I posted that…
/var/www/fog/service/ipxe# file bzImage bzImage: Linux kernel x86 boot executable bzImage, version 3.15.6 (root@debian64) #1 SMP PREEMPT Fri Jul 18 23:58:44 EDT 2, RO-rootFS, swap_dev 0x5, Normal VGA /var/www/fog/service/ipxe# file bzImage32 bzImage32: Linux kernel x86 boot executable bzImage, version 4.1.0 (root@debian64) #1 SMP PREEMPT Tue Jun 23 13:28:27 EDT 20, RO-rootFS, swap_dev 0x6, Normal VGAI’m out of my network right now, so I can’t confirm from the web site… But I think I may need to
chownthose files to www-data for the FOG management portal to update… Am I right? -
@lukebarone Just looking at the dates on some of the files, it might appear that you have FOG 1.3.0RC or even the 1.2.0 trunk build. I can’t personally believe that, its only a guess.
The FOG webgui says you have 1.4.4 installed?
Hold off on updating them until we understand what is going on. The kernels and the inits should be updated at the same time. We will do this via the linux console once we understand what you have installed.
-
@george1421 OK, here’s the history:
Started with FOG 0.32. Upgraded slowly, until last week, to a GIT version of 1.33. I was advised to upgrade to the newest version, so I went to the latest regular build, 1.44.
I downloaded it on my server, unzipped, and used the
./bin/installfog.shscript to install it (accepting the current configuration). Upgraded the database when prompted, then went on my merry way.It should be 1.44, all around. It’s no longer on a GIT version.
Hope this helps
-
@lukebarone Is there any chance we can get you to reclone the git repository and rerun 1.4.4 installer? I know the tarball route works, but I’d like to get us back to a know state and not a patched up one. If we have to get the developers on this issue they will require the system to be in a consistent state. I think we can get there and your issues should go away. We’ll get you back on solid ground now we understand what is wrong.
