Black screen when attempting to Perform full registration and inventory on Dell Latitude 5580

lukebarone

Hi all,

FOG 1.4.4, Kernel: bzImage Version: 4.13.4, bzImage32 Version: 4.13.4

Using Dell Latitude 5580. If I attempt to boot from the network, and choose either Legacy or UEFI booting over the network, then choose “Full host registration and inventory”, I am presented with a black screen.

I can perform a Quick Registration, then rename the host within the web interface (among the other options). The goal is to do the registration, image selection, group selection, all in one area.

I know the Latitude 5580 will image, as I’ve been working with them for the past few weeks. But the full host registration seems to not work when booting from the network on these devices.

Thoughts?

lukebarone

@tom-elliott Me are stupid -.-

Under the Fog Configuration -> iPXE Menu Configuration -> fog.reginput -> Boot Options:, I had " pci=noacpi" added for some reason. I removed it (after seeing that it wasn’t there on Quick Registration), and I can now boot directly to the Registration screen!

I can’t wait for the spare time to just rebuild a FOG server from scratch and copy over the machines I need… -.- Sorry to have wasted so much time with everyone on this issue

george1421

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.

lukebarone

@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.

Sebastian Roth

@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.

lukebarone

@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.

Sebastian Roth

@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!

lukebarone

@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…

Sebastian Roth

@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.

lukebarone

@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.

george1421

@lukebarone I know these are super new, but are there firmware updates for these ? Are you on the latest release?

lukebarone

@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.

george1421

@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 MENU

The 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.

Tom Elliott

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)

lukebarone

@tom-elliott As far as I know, it happens every time. Same result on 3 different laptops of the same model/shipment.

lukebarone

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

george1421

@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 bzImage and confirm the kernel release.

george1421

@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-released

I’m only raising the issue because you may have an old install with old kernels causing this strange behavior.

lukebarone

@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 VGA

I’m out of my network right now, so I can’t confirm from the web site… But I think I may need to chown those files to www-data for the FOG management portal to update… Am I right?

george1421

@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.

lukebarone

@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.sh script 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

Black screen when attempting to Perform full registration and inventory on Dell Latitude 5580

166

12.0k

17.3k

155.2k