Minnowboard MBT-4220 & 2.5.0
-
loader.conf.local should never get overwritten at upgrade. It's the installer that creates that and adds the i915 lines.
It is possible to disable loading modules manually at the loader prompt should it ever get added.
It's something I do so infrequently though I forget the exact syntax.
Steve
-
Then I gotta say this option provides the best choice for MBT boards. ZFS provides more resiliently than UFS in the event of crashes or power failures and, at least in my book, the serial console is easier to deal with than a separate HDMI display and USB keyboard.
Thanks you Steve for all the insight, answers, and rapid responses. It is most appreciated!
--tom
-
Thanks @stephenw10 :)
I reinstalled 2.4.5 against the auto UFS partition scheme, then upgraded to 2.5.2, and now the MBT-4220 boots successfully. As you mentioned months ago, the issue was loading ZFS at boot caused the error. It required too much space than what was available. -
Why commenting out the line like this:
#i915kms_load=YESand not do this:
i915kms_load=NOJust curious...
Also, I don't seem to have ANY /boot/loader.conf.local file after 2.6.0 update...
...but am likely affected, because the system won't boot anymore since the attempt of updating to 2.6.0 -
@rcfa Either commenting out the i915kms_load variable or setting it to NO will accomplish the same thing.
The key issue issue here is that you cannot use both the ZFS file system and the i915 driver because of lack of adequate buffer space during boot.
-
@trickyt Thanks!
So is 2.6.0 auto-loading drivers based on some plug&play type thing? Because as I mentioned I don't even have the /boot/loader.conf.local file, and the /boot/loader.conf file has no mention at all of the i915kms at all.
So it seems to get loaded despite no instructions telling it to load the driver. That leaves me two options:
(re)moving the /boot/kernel/i915kms.ko so it's not found, or to create the /boot/loader.conf.local file, and explicitly set i915kms_load=NOI'm still a bit puzzled why that file is totally missing...
...particularly, since the driver is loaded despite no instructions, why would commenting out the line work, because that should be equivalent to not having the file, and yet I end up with a VGA console. -
It should not get loaded by default. The installer has to specifically detect the MBT boards and creates the loader.conf.local file in order to load it.
What board do you have? Are you are actually seeing the module loaded or just zfs failing to boot?
Steve
-
@stephenw10 I can't say what is or isn't being loaded, but since the 2.6.0 is an upgrade from 2.5.x, and I always had the VGA console AND zfs file system active before, I must assume that's the issue.
Or is there a way to get a VGA console without the i915 driver being loaded?I described the situation and posted a screenshot of where things end here:
https://forum.netgate.com/topic/170869/mbt-4220-update-to-2-6-0-failed-twice/7
Also, just to make sure: that /boot/loader.conf.local file is something that ends up in the final install, right? So it's not something the installer creates, to generate something that gets dumped into the bsd-boot partition, and then is deleted?
Because neither of my two pfSense installations (one an old DELL server, the other the MBT-4220 has a /boot/loader.conf.local file, they both just have a /boot/loader.conf file. -
Yes, you can still use the console without the i915 driver (and with ZFS) as long as it's connected at boot. The driver enables HDMI hot plug, without it you cannot just connect a screen to do some troubleshooting without rebooting.
Yes, /boot/loader.conf.local is created by the installer on the target drive when it detects a Minnowboard. So you would not expect it on a Dell box. If it's not there for you check the reported product ID:
[2.6.0-RELEASE][admin@4220.stevew.lan]/root: kenv smbios.system.product Minnowboard Turbot D0/D1 PLATFORMThat's what the installer uses to determine it's running on an MBT. That unit has an updated BIOS with a new ID.
Steve
-
@stephenw10 OK, so then all is fine in that regards, the HDMI-VGA adapter is permanently attached, so hot-plugging HDMI is really the least of my concerns.
Seeing that none of the updates ever seems to have added the /boot/loader.conf.local file, not even the 2.6.0 update, that would indicate, that something other than the conflict between zfs and i915 drivers is the problem.
But what? Now I'm really frazzled...
...because from all I could tell, the update proceeded without seemingly significant errors, just failure on boot.
I was able to boot once from the old kernel, and attempted to reinstall everything according to the troubleshooting instructions, and although there seem to have been no errors that would indicated a non-bootable system, I get these panics.
A complete log of that update session is attached.
Of course, this second update, overwrote the old kernel, so now, I can't boot that system anymore, other than booting into a rescue session from the USB stick that came originally with the MBT-4220. -
Yeah, loader.conf.local is only added at install by the installer. So if you never had it in the first place it would never have been added.
When you install 2.6 clean does it install and boot as expected?
I assume it does as UFS?Does it as ZFS if you comment out the i915 lines before rebooting after the install?
What you're hitting appears to be something unrelated to that issue.
Steve
