Quick registration Kernel Panic - Not Syncing
-
Here’s a screen shot. Thanks.
[url=“/_imported_xf_attachments/0/769_photo.JPG?:”]photo.JPG[/url]
-
If you’re running the latest (1.0.1) of FOG, make sure if you followed the FAQ steps for getting a kernel, you follow the appropriate steps. Such as, bzImage is 64 bit kernel, bzImage32 is a 32 bit kernel. If your systems trying to boot as 64 bit (as my guess here is) when you downloaded the new kernel, did you do [code]wget -O bzImage https://mastacontrola.com/fogboot/kernel/bzImage32[/code] or did you [code]wget -O bzImage --no-check-certificate https://mastacontrola.com/fogboot/kernel/bzImage[/code]
Have you tried other kernels?
-
Hi again.
Thanks for the reply. Unfortunately that hasn’t fixed my issue. In the steps below, you will see that I have tried kernel from v0.32.
To recap a bit, in my previous posts, I was asking about issues with regards to the new FOG iPXE timeout and Kernel Panic issues. To put it all in perspective:
- The iPxe timeout stopped me from seeing the FOG menu
- And the Kernel Panic was caused by a bzImage or (bzImage32) failing to be loaded onto my FOG client
My FOG server is:
- HP Tower DC7100, Ubuntu Desktop 14.04 LTS, FOG 1.0.1
Image to deploy:
- image name: Linux-testimg1, 40GB ( with 3 partitions 1GB for /boot (/dev/sda1), 2GB for /swap (/dev/sda2), and the rest for root / (/dev/sda3) )
- image OS: Linux OS, Ubuntu Server 12.04.1 LTS, 32-bit
- image FS: ext4fs
My Fog client is (This is the one that I am desperately trying to deploy the image to):
- HP DL360e Proliant - SATA (non-RAID), two 500GB HDDs.
In the following steps, I used workarounds to circumvent all these issues, but I still have problems (I have captured a short video (2min:19) [media=youtube]xnUX74Dlhno[/media]
As per my other thread that I had started:
1/ To boot the client onto Fog server’s iPXE, I press F12 (Network boot) (see video at about 00:34sec).
Then iPXE goes on and to circumvent the timeout issue, I press PAUSE|BREAK on my keyboard (see video at about 00:52sec).
I wait for about 4sec after the PAUSE|BREAK keypress then press ESC2/ bzImage and init.xz then get loaded … ok
NOTE:- I had to overwrite fog 1.0.1’s bzImage with fog 0.32’s bzImage
- I had to rename fog 0.32’s init.gz to init.xz then overwrite fog 1.0.1’s init.xz
Without these 2 hacks, step 2 caused a Kernel Panic crash when the original fog 1.0.1’s bzImage and init.xz were loaded on my Fog HP Proliant client. The 0.32’s bzImage and init files do not cause it to crash.
3/ Fog 0.32 boots up and tries to deploy my Linux-testimg1, but it unfortunately fails (see video)
Thanks for any help,
Subtitling
-
[quote=“subtitling, post: 27216, member: 24179”]My Fog client is (This is the one that I am desperately trying to deploy the image to):
- HP DL360e Proliant - SATA (non-RAID), two 500GB HDDs in mirror configuration[/quote]
Wouldn’t this absolutely mean it is in RAID? (RAID 1 or 10 to be exact?)
[quote=“subtitling, post: 27216, member: 24179”]In the following steps, I used workarounds to circumvent all these issues, but I still have problems (I have captured a short video (2min:19) [media=youtube][URL='[media=youtube]xnUX74Dlhno[/media][/media]):
As per my other thread that I had started:
1/ To boot the client onto Fog server’s iPXE, I press F12 (Network boot) (see video at about 00:34sec).
Then iPXE goes on and to circumvent the timeout issue, I press PAUSE|BREAK on my keyboard (see video at about 00:52sec).
I wait for about 4sec after the PAUSE|BREAK keypress then press ESC[/quote]Can you try the latest ipxe.kpxe or ipxe.kkpxe as a replacement to your current undionly.kpxe?
[quote=“subtitling, post: 27216, member: 24179”]2/ bzImage and init.xz then get loaded … ok
NOTE: - I had to overwrite fog 1.0.1’s bzImage with fog 0.32’s bzImage
- I had to rename fog 0.32’s init.gz to init.xz then overwrite fog 1.0.1’s init.xz
Without these 2 hacks, step 2 caused a Kernel Panic crash when the original fog 1.0.1’s bzImage and init.xz were loaded on my Fog HP Proliant client. The 0.32’s bzImage and init files do not cause it to crash.
3/ Fog 0.32 boots up and tries to deploy my Linux-testimg1, but it unfortunately fails (see video)
Thanks for any help,
Subtitling[/quote] 0.32’s bzImage will not work because it’s a 32bit kernel. In FOG 1.0.1, 32 bit goes with 32 bit init, 64 bit goes with 64bit init.
If you want the “hacks” to work, simply relabel the existing FOG init_32.xz as init.xz and bzImage32 as bzImage in service/ipxe as the init’s between versions are completely different from each other.
- HP DL360e Proliant - SATA (non-RAID), two 500GB HDDs in mirror configuration[/quote]
-
Sorry, ignore the previous ‘mirror’ comment, that was where I failed to delete the text after double checking the server config.
Thanks.
-
Further, I put all the original files (inits and bz files) back from the default installation then ran:
wget -O bzImage --no-check-certificate [url]https://mastacontrola.com/fogboot/kernel/bzImage[/url]…but I still get the panic.
For good measure I ran this as well:
wget -O bzImage32 --no-check-certificate [url]https://mastacontrola.com/fogboot/kernel/bzImage32[/url]Would you point me to what you mean by the FAQ on kernels, I am unsure what you mean?
Thanks
-
In my signature:
Kernel Issues: [url]http://fogproject.org/wiki/index.php/FAQ[/url] -
Based on what I saw in the video there, you’re not FOG 1.0.1. It looks like it loaded everything through FOG 0.32. The image it’s recognizing is in partclone format so it doesn’t write anything to the drive because it’s not in the right format. Where you, at one point in time, able to upload an image?
-
I just rebuilt my kernels with HP iLO Processor channel interface built in. I don’t know if this will work, but it’s likely a driver issue on the server. Hopefully these help.
[url]https://mastacontrola.com/fogboot/kernel/bzImage[/url] (64 bit) to be used with init.xz (original one packed with FOG 1.0.1)
[url]https://mastacontrola.com/fogboot/kernel/bzImage32[/url] (32 bit) to be used with init_32.xz (original one packed with FOG 1.0.1) -
Sorry, I missed your signature, but I just tried now but sadly I still have the issue. Thanks for your effort; however, I’m going to have to call it a night now.
Cheers.
PS - We didn’t get the issue with 0.32, but sadly it doesn’t support ext4.