Jump to content

MrSmith3101

Members
  • Content Count

    7
  • Joined

  • Last visited

Community Reputation

0 Neutral

About MrSmith3101

  • Rank
    Newbie
  1. Hmm thats a good question. Sadly I "destroyed" my first pfsense VM as I tried to change the version branch to experimental. I thought this would fix the boot issues. But it didn't. (exactly same behavior) Besides that the experimental build of pfsense also broke support for my Intel NICs. So I wasn't able to connect to the GUI anymore. Long story short - I had to delete my pfsense VM and create a new one. And now to answer your question --> I think (90% sure here) that my old pfsense VM was configured as seabios. (I previously had boot problems but different to the current "stall" issue) But I'm not 100% sure. Sorry =( My "new" pfsense VM is now configured as OVMF (as this is the standard config) So it looks like it does not make any difference if you choose OVMF or seabios. Sorry that I can't verify this 100% now =/
  2. Thanks for your input bastl. Appreciate your testing time. So different VM configurations do not help in this case. =( I should add that my pfsense VM uses two "real" NICs which are passthrough from the host. (it is a Intel Pro 1000 series card with 4 NICs) But as noted by bastl it does not look like it make any difference.
  3. I just digged up some numbers to compare. You are basically right. 6.8.0-rc8 (and 9) uses the same major kernel version (4.19) as the stable version 6.7.2 (were pfSense was working fine for me) So let me list the kernel changes between three versions. 6.7.2 (pfSense boots) Linux Kernel: 4.19.56 6.8.0-rc9 (pfSense fails) Linux Kernel: 4.19.88 6.8.0-rc8 (pfSense fails) Linux Kernel: 4.19.87 6.8.0-rc7 (pfSense boots fine!) Linux Kernel: 5.3.12 So the possibility is that there were some changes between 4.19.56 and (including) 4.19.88 which led to the issue with pfSense (and this „problem“ was fixed in the 5.x kernel) OR the fault is not the kernel itself but some packages which got up/downgraded. Will try to list some more changes between those versions if it helps. KR,
  4. I have exactly the same problem as described by user beaverly72. Since I updated to 6.8.0-rc8 (and continued with rc9 - same story) my pfsense VM is stalled using 100% processing utilization of one core. I had to forcefully shut it down. It never came up. Rolling back to 6.8.0-rc7 works for me but I decided to leave the testing branch and rollback to 6.7 stable. Any suggestions to fix my issue? I'm worried since the next stable version is close to release and I really would like to use 6.8 as my daily driver. Thanks for your input! KR
  5. Hmm.. I‘m sorry I have only „tested“ this behaviour with the power outage I had. I did not stop the array with the GUI or anything. I thought the array is offline during a parity check which is definitely not right. I forgot I had my array in „auto start“. Nevertheless, it would be really a good idea to be able to run VMs from unassigned devices or cache drives with the array offline. Sorry again = (
  6. EDIT: It is definitely not built-in. I had auto-start of my array enabled so it looked like my VM started without the array. Editing my old post for clarification. Thx itimpi for explaining what happened! ORIGINAL (WRONG): Well, seems like this functionality is already built-in! Sorry for the confusion. I had a power outage due to a short at an outdoor power outlet. I was not at home and suddenly couldn‘t connect via VPN anymore. What really happened is that my server did not automatically boot from the USB-stick. The server was just idling and stalled at the boot screen. After correct rebooting Unraid started array checking which of course shuts down the array. BUT, my pfsense VM was booting up fine! My VM HDD image is located (fixed) on my cache drive. Works perfectly! Thx Unraid
  7. I know this is an old thread but I would really appreciate functionality to run VMs without the array started. Especially for pfSense! Please consider this functionality. Thanks for your time and KR,