Kernel Panic when Upgrading to 2.8.0 beta
-
@stephenw10 no idea how i only have experience with the web interface might need some guidance
-
Well first the hardware have a serial port you can access?
If so you can just enable it in Sys > Adv > Admin Access initially.
Then you need to connect to it with a serial terminal client of some sort. So that might be putty running on a laptop with a some sort of USB to serial adapter.
Trivial if you've done it before but....
-
@stephenw10 yea i dont have any of those adopters and sounds complicated. I guess no more updates for me :(
-
Well I'd expect it to be possible. We just need to see more logging.
How did you disable isp0 in the end?
Did you try disabling it in the BIOS?
A good option here would be to disable any hardware not in use there.
-
@stephenw10 i just used the command in the web interface to disable it so it would no load on update. I used both the hint and blacklist command
-
Do you have the option of disabling it in the BIOS? Can you test that?
-
@stephenw10 i know i can disable the usb legacy in the bios no shore about the 2400 but i guess i could open it up and pull all cards not in use if any as well then try with no usb enabled ?. If i disable the usb legacy that will mean i wont be able to get back into the bios with the keyboard tho wont it?
-
I just ran into the same issue with the release version. Update went smoothly until it didn't. It presents the same modality and fault codes, but different addresses and hardware details.
I reverted back to 2.7.2.
-
@stephenw10 good news i pulled the card from the server unplugged the keyboard while updateing and all went well. Now on the latest ver thanks for ya help :)
-
@Spacecase said in Kernel Panic when Upgrading to 2.8.0 beta:
It presents the same modality and fault codes, but different addresses and hardware details.
Could be a very different panic then. Do you have the details? Did the console also become unresponsive?
-
When updating from v2.7.2, all looked well until the reboot. The dashboard was still in a 20s loop. At the time, I had no monitor on the console, but it was dark when I connected it. I rebooted the host and, if I recall correctly, there was still nothing on the screen. At that point, I used the installer and could see boot activity on the console.
Here's the screenshot:
It's looking for the WiFi driver.
-
@Spacecase you can try be disabling the wifi card, either in the BIOS or if that is not possible, using a hint, like explained a bit further up in this thread:
https://forum.netgate.com/post/1214869
-
@patient0
Thanks.I've seen what's been posted so far, but reported the event to let developers know there's a bug common to Intel and AMD platforms. For the time being, I need a functioning network. I'll try to find some time to troubleshoot it over the weekend.
-
Yup there's some regression there in at least in the iwlwifi driver. It's failing to load the firmware into the card.
But, yes, disabling that device should allow it to boot normally.
-
@stephenw10
Thanks for looking into the issue. I'm left wondering if it's a corner case or something more widespread. I guess we'll find out soon enough. -
@patient0
I disabled WiFi in the BIOS and am now successfully running 2.8.0. -
-
Thought I'd add I had the same (hard lock) kernel panic due to chipset 'iwm3160fw'.
I disabled it using the hint/config file mentioned above. Much appreciate being able to go forward, rather than back-out.I did periodically use the WiFi adapter, so hopefully BSD resolve the issue(s) with those chipsets in a subsequent update...
-
@manicmoose said in Kernel Panic when Upgrading to 2.8.0 beta:
I did periodically use the WiFi adapter, so hopefully BSD resolve the issue(s) with those chipsets in a subsequent update...
Euh ... for the last ... well, since FreeBSD exists, it's Wifi (adapter) driver support is known as quasi non existent.
For drivers to be created, device hardware details need to be 'public'. A driver will exists of course, and it will be for 'Microsoft' based devices. Remember : if you create a driver, you also have to support it.
Just image : reverse engineer NIC wifi driver not knowing the hardware.Your only option : wait until someone creates a driver, and then wait until the FreeBSD author include that driver into FreeBSD, so Netgate can pull it all into pfSense.
Be ware that FreeBSD is known for not importing crap-ware.
The driver's source code should be 'open'.Making a long story short : you need an AP ? Get an AP.
-
I get all that, but you're missing the point.
That same WiFi chip/adapter has been working with pfsense/BSD for over 5 years...the driver probably just needs slight adjustment for a newer kernel, would be my expectation.
-
@manicmoose said in Kernel Panic when Upgrading to 2.8.0 beta:
That same WiFi chip/adapter has been working with pfsense/BSD for over 5 years...the driver probably just needs slight adjustment for a newer kernel, would be my expectation.
I though you were getting the point that pfSense pfSense 2.7.0 uses FreeBSD 14.x
pfSense 2.8.0 uses newer kernel, 15.x.Sure enough, the same (?) driver recompiled for "15" fails - for you.
If it's part of the new "15" kernel set, then it was working for some one, otherwise FreeBSD (and Netgate ?) wouldn't have included the driver.
If you have a chip set version type or any detail that can identify your wifi NIC, check up stream (freebsd driver support) if the issue is known, maybe a more recent driver exists already, compiled for your processor (x86, x64 or arm) and didn't make it into this pfSense build (using kernel 15.x).I agree, making it work could be very easy. It's just a matter of : the guy who has the same hardware as you and can build/test/write/understand FreeBSD kernel drivers, has to to 'his thing'.
edit : remember :
Office 365 for Windows 10 might work Windows 11.
Office is a user land app.
A kernel driver is totally different. For some 'devices' like a NIC for Windows 10 will not work for Windows 11. Is has to be, at least, rebuild.
As system calls, settings etc etc did change, some source modification are needed for every device driver.