Minnowboard MBT-4220 & 2.5.0
-
@stephenw10 I was just wondering...
When you consider the features of ZFS, is there an advantage to it over UFS when using it for pfSense on a little box like a Minnowboard? The reason I ask is because it isn't being used for storage and you can backup & restore the config at any time. -
The biggest advantage, in my personal opinion, is the increased resilience against damage in the even of power loss. Certainly in current pfSense. It also has snapshots etc which we hope to take advantage of on the long term.
-
@stephenw10 Could it be that the CE 2.5.2 installation image (available here: https://www.pfsense.org/download/) does not include some of the modules required to create a ZFS-based installation? When I try to follow the instructions given on https://docs.netgate.com/pfsense/en/latest/install/install-zfs.html I get to the step where I'm asked to select a disk and the list is supposed to include a Virtual Device Type. But no VDTs are included in the list and if I try to select the real on-board SSD disk I get an error saying no disks have been selected (0 < 1 disks).
-
Hmm, it gives you the choice between mirror and stripe though?
The ZFS installer is quite a bit different to UFS. It's sometimes unclear you have to actually select a disk to use in the VDT.
-
Yes, the stripe/mirror/raidXXX menu is shown, as described in the Netgate documentation, and I chose "stripe" . It's the following menu, Select Disks, that differs. No vtbdX (VirtIO Block Device) is listed and of the two choices that are listed, the SSD and the USB memory stick, selecting the SSD gives the error I described.
I'll try going back to my old 2.4.4 installation USB and see what happens. That's how I originally configured my MBT to use ZFS.
-
@trickyt said in Minnowboard MBT-4220 & 2.5.0:
VirtIO Block Device
You would only see that if you're installing in KVM. The docs show it because it's much easier to get screenshots that way. You should be able to select just the SSD and continue.
-
You can definitely do stripe with one disk in 2.5.2. You have to actually select the disk by pressing space though. That's not obvious. Should look like:
Steve
-
Figured the same thing out about the time you were posting your last message. Yes, must select the device using the space bar! Duh. Have now successfully partitioned with ZFS and installed 2.5.1. At the end of the installation process it gave me a chance to invoke a shell and edit /boot/loader.conf, which I did. But there were no lines there referencing the i915 kernel module. And now I'm in the same situation I started with: insufficient EFI staging area that leads to the kernel hanging just after starting. I'm thinking that the path /boot/loader.conf likely was the file on the USB drive and I need to use a different pathname for the file on the MBT's SSD drive. That make sense to you?
BTW, I added the stereo jack serial console connector today. Works GREAT! 5-stars on this idea.
--tom
-
It adds the i915 values to
loader.conf.localfor the MBT. You need to comment them out there. -
Just to wrap things up: My MBT is working fine now, running pfSense Plus 2.5.2 and configured with ZFS partitioning. So I'm confirming the process described in this thread works. I also tried installing 2.5.1 and then upgrading to 2.5.2 and my modified loader.conf.local was not changed by the upgrade process and thus the upgrade went smoothly.
One last question for @stephenw10 though: when, if ever, should I be concerned that doing an upgrade might change loader.conf.local or that the i915 kernel module might get loaded by some other config file? Then I'd be back to my original problem of the MBT hanging during boot. As far as I've determined, there's no easy way to edit loader.conf.local except during the last step of the installation process.
-
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.
