Community discussions

 
andret
newbie
Topic Author
Posts: 37
Joined: Fri Apr 17, 2009 11:08 am

ESXi 6.5 U2 - Kernel panic on disk resize [SOLVED]

Sun May 05, 2019 7:24 pm

Hi,

I installed Mikrotik CHR from ova file downloaded from Mikrotik's website.

It seems to run perfectly fine until I want to change the disk size.

From the console it says 'resizing disk' and then I get the attached image as an error in a continuous boot loop - any ideas?

Edit: I tried it on VirtualBox and get the same result...
You do not have the required permissions to view the files attached to this post.
Last edited by andret on Wed May 08, 2019 8:02 pm, edited 1 time in total.
 
elbob2002
newbie
Posts: 46
Joined: Tue May 15, 2018 8:15 pm
Location: Ireland

Re: ESXi 6.5 U2 - Kernel panic on disk resize

Mon May 06, 2019 10:30 pm

You need to resize the disk before powering on the VM for the first time.

It should automatically resize on the first boot.
 
andret
newbie
Topic Author
Posts: 37
Joined: Fri Apr 17, 2009 11:08 am

Re: ESXi 6.5 U2 - Kernel panic on disk resize

Mon May 06, 2019 11:09 pm

You need to resize the disk before powering on the VM for the first time.

It should automatically resize on the first boot.
Thanks, I thought of this also but tried it again just to make sure - the same result...
 
Sob
Forum Guru
Forum Guru
Posts: 4530
Joined: Mon Apr 20, 2009 9:11 pm

Re: ESXi 6.5 U2 - Kernel panic on disk resize

Mon May 06, 2019 11:16 pm

Send a bug report to support. They may see it here, but officially it's only user forum, so they can miss it.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
andret
newbie
Topic Author
Posts: 37
Joined: Fri Apr 17, 2009 11:08 am

Re: ESXi 6.5 U2 - Kernel panic on disk resize

Mon May 06, 2019 11:22 pm

Send a bug report to support. They may see it here, but officially it's only user forum, so they can miss it.
Thanks, just did that :)
 
andret
newbie
Topic Author
Posts: 37
Joined: Fri Apr 17, 2009 11:08 am

Re: ESXi 6.5 U2 - Kernel panic on disk resize

Wed May 08, 2019 8:02 pm

Send a bug report to support. They may see it here, but officially it's only user forum, so they can miss it.
Thanks, just did that :)
This has been solved with help from support to re-read the information here https://wiki.mikrotik.com/wiki/Manual:C ... stallation

I somehow missed that one has to set the disk to IDE Master even though the ovf imported using the SCSI interface.

So it runs fine on the SCSI interface until you need to resize the disk then it fails - changing the drive type to IDE (PATA) solves the kernel panic and CHR completes the resize and starts up perfectly fine.

Just thought I'd post the solution here in case someone else has a similar issue.
 
Sob
Forum Guru
Forum Guru
Posts: 4530
Joined: Mon Apr 20, 2009 9:11 pm

Re: ESXi 6.5 U2 - Kernel panic on disk resize [SOLVED]

Wed May 08, 2019 9:58 pm

Honestly, it sounds kind of stupid to me. Both having to use IDE disk and RouterOS crashing like this and it not being a bug. And in fact, none of my CHRs have IDE disk, I have SCSI everywhere and it works great. Although it's true that I didn't use OVA, I just took disk image and when I needed to resize it, I did it with qemu-img before I first connected it.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
Sob
Forum Guru
Forum Guru
Posts: 4530
Joined: Mon Apr 20, 2009 9:11 pm

Re: ESXi 6.5 U2 - Kernel panic on disk resize [SOLVED]

Thu May 09, 2019 1:20 am

There seems to be something wrong with virtual disk in OVA.

I normally download CHR in "raw disk image" format and then I convert it to vmdk myself. I don't exactly remember why, either there wasn't vmdk at the beginning at all, or there was some problem just uploading it to ESXi as bare file. I think it was the latter, it complained about wrong format or something.

I do this (adapter_type=lsilogic is only because qemu-image doesn't like pvscsi):
qemu-img.exe resize -f raw chr-6.44.3.img 128MB
qemu-img.exe convert -o adapter_type=lsilogic,subformat=monolithicFlat -f raw -O vmdk chr-6.44.3.img mikrotik-chr.vmdk
Then I upload resulting mikrotik-chr.vmdk and mikrotik-chr-flat.vmdk to ESXi (they get merged into one, at least in UI) and select it as new disk (connected to pvscsi controller). And it works great. Even resizing works. Shut the VM down, set larger disk size, start it again and it will occupy new free space. I can repeat it again and again and it still works. So in fact my initial img resizing should not even be necessary, it's a relict from the past when I think CHR supported resizing only on first start and not further, and I wanted to be sure that I will have enough space for the future.

But here's the thing, now I tried to skip the first step (qemu-img resize) and only converted MikroTik's original img to vmdk. And surprise, the resulting vmdk crashes CHR when resized, exactly as the one from OVA.
People who quote full posts should be spanked with ethernet cable. Some exceptions for multi-topic threads may apply.
 
andret
newbie
Topic Author
Posts: 37
Joined: Fri Apr 17, 2009 11:08 am

Re: ESXi 6.5 U2 - Kernel panic on disk resize [SOLVED]

Thu May 09, 2019 7:40 pm

There seems to be something wrong with virtual disk in OVA.

I normally download CHR in "raw disk image" format and then I convert it to vmdk myself. I don't exactly remember why, either there wasn't vmdk at the beginning at all, or there was some problem just uploading it to ESXi as bare file. I think it was the latter, it complained about wrong format or something.

I do this (adapter_type=lsilogic is only because qemu-image doesn't like pvscsi):
qemu-img.exe resize -f raw chr-6.44.3.img 128MB
qemu-img.exe convert -o adapter_type=lsilogic,subformat=monolithicFlat -f raw -O vmdk chr-6.44.3.img mikrotik-chr.vmdk
Then I upload resulting mikrotik-chr.vmdk and mikrotik-chr-flat.vmdk to ESXi (they get merged into one, at least in UI) and select it as new disk (connected to pvscsi controller). And it works great. Even resizing works. Shut the VM down, set larger disk size, start it again and it will occupy new free space. I can repeat it again and again and it still works. So in fact my initial img resizing should not even be necessary, it's a relict from the past when I think CHR supported resizing only on first start and not further, and I wanted to be sure that I will have enough space for the future.

But here's the thing, now I tried to skip the first step (qemu-img resize) and only converted MikroTik's original img to vmdk. And surprise, the resulting vmdk crashes CHR when resized, exactly as the one from OVA.
I can confirm that I have reproduced this problem within the limitations outlined which says it actually has a minimum disk size requirement of 128MB even though the OVF imported and created and successfully booted from a 64MB disk?

It booted successfully with the original 64MB disk image that comes with the OVF but as can be seen below when increasing it to 128MB it causes a kernel panic as was the origin of my original post.

To make things further confusing is that editing the VM again and increasing the disk size to 256MB results in a successful resize and subsequent boot of CHR as can be seen on the attached images... so there's definitely a bug lurking in there somewhere especially given that my resized 256MB disk boots successfully from SCSI and I did not need to reconfigure the hard disk to emulate IDE... say what?





Thanks, so there is some or the other bug lurking around in there somewhere... perhaps I was just unlucky enough to get stuck with that. Obviously following the original instructions at the link provided causes me to nuke the original install and start from scratch so it could be that I need to skip something to reproduce the error
You do not have the required permissions to view the files attached to this post.
 
wombatonfire
just joined
Posts: 1
Joined: Sat Jul 20, 2019 4:02 pm

Re: ESXi 6.5 U2 - Kernel panic on disk resize [SOLVED]

Sat Jul 20, 2019 4:23 pm

My experience with CHR deployed from the official OVA template:

Disk size 64MB (default) - successful boot.
Disk size 128MB/127MB/65MB - kernel panic.
Disk size 129MB - sucessful boot.

So, it seems, any value less than or equal to 128MB leads to a failure (except the default 64MB). I didn't check all the possible values between 64 and 128, but the pattern is pretty clear.

Bus type is SCSI in my case.

Who is online

Users browsing this forum: No registered users and 3 guests