6285 - Kernel panic not syncing when trying to image

[MRCUR]

After talking to @Wayne-Workman, this seems like it might be an issue with the symlink being used to make /var/www/html work on Ubuntu where the root is really /var/www.

@tom-elliott I see in .fogsettings there’s a line for “docroot”. If I update that to be /var/www/ instead of /var/www/html/, will that work?

[Tom Elliott]

@MRCUR If you want to give it a shot, maybe.

[MRCUR]

@Tom-Elliott Changed the docroot to /var/www/ and didn’t have any success. Tried the 4.4 kernel as @wayne-workman suggested without success either. Same issue.

[Tom Elliott]

@MRCUR Can you post a pic of the panic?

[MRCUR]

@Tom-Elliott

[Wayne Workman]

@MRCUR How many devices have you tried on? Just this laptop?

[Hanz]

@Wayne-Workman This exact error is what I’m getting as well…hardware worked previously so it’s in the code.

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