6285 - Kernel panic not syncing when trying to image
-
@MRCUR If you want to give it a shot, maybe.
-
@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.
-
@MRCUR Can you post a pic of the panic?
-
-
@MRCUR How many devices have you tried on? Just this laptop?
-
@Wayne-Workman This exact error is what I’m getting as well…hardware worked previously so it’s in the code.
-
@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?
-
@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.
-
@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.
-
@MRCUR So it works on one, but not the other?
-
@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.
-
@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.
-
#!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```
-
@MRCUR can you, for now, disable hidden menu, and see if this fixes the problem?
-
@Tom-Elliott Same issue.
-
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.
-
@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.
-
@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.
-
@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.
-
@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.