6285 - Kernel panic not syncing when trying to image

[Tom Elliott]

@MRCUR Is bzImage32_4 a valid file? Meaning is it a full on filename in /var/www/{html,}/fog/service/ipxe/ and what’s the size?

[MRCUR]

@Tom-Elliott It is, yes. Downloaded through the kernel update GUI as suggested by @Wayne-Workman. This also happens with the default 4.4.1 kernel.

@Wayne-Workman This is happening on all of our hardware that I know of. I’ve specifically been using HP ProBook 640’s and 440’s today while testing. I have a 440 sitting at my desk now which is displaying the issue.

[MRCUR]

@Tom-Elliott I should mention that this hardware works fine with my test server (currently rev 6285 on 14.04 LTS, same as production server) using the default 4.4.1 kernel.

[Tom Elliott]

@MRCUR So it works on one, but not the other?

[Tom Elliott]

@MRCUR Also, can you get output from the browser?

http://IP.Of.Fog.37/fog/service/ipxe/boot.php?mac=c4:34:6b:06:5b:20

Of course I don’t know the ip so please change the relevant info as needed.

[MRCUR]

@Tom-Elliott Right. The test server was SVN from the start (not sure what rev I started with), the production server was originally 1.1 or 1.2 and upgraded to svn over the summer and then this week to 62XX series.

[MRCUR]

@Tom-Elliott

#!ipxe
set fog-ip X.X.X.37
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
iseq ${platform} efi && set key 0x1b || set key 0x127e
iseq ${platform} efi && set keyName ESC || set keyName F6
prompt --key ${key} --timeout 3000 Booting... (Press ${keyName} to access the menu) && goto menuAccess || sanboot --no-describe --drive 0x80
:menuAccess
login
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param username ${username}
param password ${password}
param menuaccess 1
param debug 1
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain -ar http://X.X.X.37/fog/service/ipxe/boot.php##params```

[Tom Elliott]

@MRCUR can you, for now, disable hidden menu, and see if this fixes the problem?

[MRCUR]

@Tom-Elliott Same issue.

[Tom Elliott]

Are you sure both cloud versions are the same?

Can you test with some basic moving tricks?

mv /var/www/fog /home/fog/web
rm /var/www/html/fog -rf
rm /var/www/fog -rf

Then rerun the installer?

The only reason I move it first is so if you have any special iso’s we can recover them later on.

[MRCUR]

@Tom-Elliott Same issue after running the installer again.

They’ve been the same throughout the day and were both 6285 when I updated last night when the problem started. The production is 6295 now as I’ve grabbed the latest a few times today.

[Tom Elliott]

@MRCUR As this is about getting into the inits and bzImage files, can you setup a simple debug tasking for both the test and prod servers? Then try booting the same system on both servers? Do both have the same problem?

After that, go ahead and cancel the tasking on both systems and try to do a simple tasking of the same on both servers. Do both systems perform the same way?

Just trying to help narrow down on the issue.

[MRCUR]

@Tom-Elliott On the production server, the client throws the kernel panic with both tasks. On the test server, the client gets into the debug and then shows an “unknown task” error (maybe this is normal for debug?). With a deploy task it boots and begins imaging correctly.

[Tom Elliott]

@MRCUR Can you scp the files from the test to the production server?

Then try the same stuff.

Simple Debug I don’t expect to actually do anything as there is nothing set.

Just want to help get to the bottom of this. I wonder if other kernel params are being passed between the test and production servers though.

[MRCUR]

@Tom-Elliott Took the ipxe directory from the test server and copied it to the production server. Reapplied permissions and same results on the client. Kernel panic with any task.

[Tom Elliott]

@MRCUR With both systems in “tasking”, can you get the output of the test and the prod servers and print them here? I suspect something is different though I haven’t a clue what.

[MRCUR]

@Tom-Elliott Output from where?

[Tom Elliott]

@MRCUR The browser like you did before, but with the host in tasking.

[MRCUR]

@Tom-Elliott First is the production server, second is test.

#!ipxe
set fog-ip 172.16.56.37
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
#!ipxe
kernel http://172.16.56.37/fog/service/ipxe/ loglevel=4 initrd=http://172.16.56.37/fog/service/ipxe/ root=/dev/ram0 rw ramdisk_size=127000 keymap= web=172.16.56.37/fog/ conosoleblank=0 mac=28:80:23:09:28:56 ftp=172.16.56.37 storage= storageip= web=172.16.56.37/fog/ osid= consoleblank=0 irqpoll hostname=TEA-440TEST mode=onlydebug
imgfetch http://172.16.56.37/fog/service/ipxe/
boot

#!ipxe
set fog-ip 172.16.200.10
set fog-webroot fog
set boot-url http://${fog-ip}/${fog-webroot}
#!ipxe
kernel loglevel=4 initrd=init_32.xz root=/dev/ram0 rw ramdisk_size=127000 keymap= web=172.16.200.10/fog/ conosoleblank=0 mac=28:80:23:09:28:56 ftp=172.16.200.10 storage= storageip= web=172.16.200.10/fog/ osid= consoleblank=0 irqpoll hostname=TEA-440TEST mode=onlydebug
imgfetch init_32.xz
boot

[MRCUR]

@Tom-Elliott I did notice on the test server in /var/www, there is a symlink for fog to /var/www/html/fog. On the production server, this symlink doesn’t exist (everything is in /var/www/html/fog).