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

[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

[george1421]

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

[lukebarone]

@george1421 OK, I have the newest GIT version downloaded… Heading back to the office to install it. Will report back soon

[george1421]

@lukebarone said in Black screen when attempting to Perform full registration and inventory on Dell Latitude 5580:

GIT version downloaded

The context of this confuses me. Does your FOG server have internet access either direct or indirect via a proxy server?

[george1421]

@george1421 If your fog server does have internet access I would prefer if you use this route to install FOG

sudo -i
git clone https://github.com/FOGProject/fogproject.git /root/fogproject
cd /root/fogproject
cd bin
./installfog.sh

[Sebastian Roth]

@lukebarone Interesting turning point in this thread I see. Just want to add another thing to look at. Please run

ls -al /var/www/
ls -al /var/www/fog/
ls -al /var/www/html/

Possibly there is some old link pointing a wrong direction which causes the issue?!?

[lukebarone]

@sebastian-roth

~# ls -al /var/www/
total 32
drwxr-xr-x  6 root     root     4096 Feb  8  2017 .
drwxr-xr-x 13 root     root     4096 Oct 31  2014 ..
drwxr-xr-x 12 www-data www-data 4096 May 31  2016 fog
drwxr-xr-x 12 www-data www-data 4096 Mar 22  2013 fog_orig
drwxr-xr-x 12 www-data www-data 4096 Jul  3  2014 fog.prev
drwxr-xr-x  4 root     root     4096 Jan 15 10:58 html
-rw-r--r--  1 root     root      177 Dec  4  2012 index.html
-rw-r--r--  1 root     root       45 Jul  3  2014 index.php
~# ls -al /var/www/fog/
total 56
drwxr-xr-x 12 www-data www-data 4096 May 31  2016 .
drwxr-xr-x  6 root     root     4096 Feb  8  2017 ..
drwxr-xr-x  2 www-data root     4096 May 31  2016 av
drwxr-xr-x  2 www-data www-data 4096 May 31  2016 client
drwxr-xr-x  3 www-data www-data 4096 May 31  2016 commons
-rw-r--r--  1 www-data www-data 1406 May 31  2016 favicon.ico
-rw-r--r--  1 www-data www-data   50 May 31  2016 index.php
drwxr-xr-x  7 www-data www-data 4096 May 31  2016 lib
drwxr-xr-x 12 www-data www-data 4096 May 31  2016 management
drwxr-xr-x  4 www-data www-data 4096 May 31  2016 mobile
drwxr-xr-x  3 www-data www-data 4096 May 31  2016 public
drwxr-xr-x  3 www-data www-data 4096 May 31  2016 service
drwxr-xr-x  2 www-data www-data 4096 May 31  2016 status
drwxr-xr-x  2 www-data www-data 4096 May 31  2016 wol
~# ls -al /var/www/html/
total 20
drwxr-xr-x  4 root     root     4096 Jan 15 10:58 .
drwxr-xr-x  6 root     root     4096 Feb  8  2017 ..
drwxr-xr-x 11 www-data www-data 4096 Jan 15 11:00 fog
-rw-r--r--  1 root     root       45 May 31  2016 index.php
drwxr-xr-x  3 root     root     4096 Feb  9  2017 ISO

[lukebarone]

@george1421 Yes, that is the method I download with GIT.

I followed the instructions, and now have the latest trunk version, SVN Revision 6077. Do you want me to try the Full Registration again?