6285 - Kernel panic not syncing when trying to image

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

[Tom Elliott]

@MRCUR he initrd line is the issue.

It’s not set right on the production server.

[Hanz]

I’d like to add that my output is the same for my machines…I did the browser test you mentioned and I got the first result…Imaging doesn’t work at all for my sysprep machine…

it just sits here with no kernel panic errors. It looks as though the actual kernel filenames are missing, and only showing directory where file should reside.

[Tom Elliott]

Do both of you use the location plugin? (On production and not on test if that’s your setup?)

[Hanz]

@Tom-Elliott yessir, unfortunatley I only have the 1 setup so that’s why I’m quick to bother you…LOL

[Sebastian Roth]

@Hanz See in your screenshot. Both lines that should download bzImage (linux kernel) and init.xz (init ram disk) are missing the filenames!!! I am sure this cannot work.

Edit: Seams like Tom has found the issue and will update the code soon and let you know I am sure.

[Tom Elliott]

Fix should be pushed. It was, semi, related to location, but indirectly.

The hook that processes for the bootmenu in this case was not setting needed variables first. This should now work as intended, of course please update and test.

[Hanz]

@Tom-Elliott Like a charm, that’s why you are da man sir

[MRCUR]

@Tom-Elliott I’ll apply after school is done today and test. Thanks Tom.

[MRCUR]

@Tom-Elliott This is resolved. Thanks very much Tom.