Messages

Legacy BIOS (seabios) has fewer coreboot configuration options and is probably the safest option? For UEFI (edk2) there is the choice of mrchromebox fork or original for example.

But using ,,current" (UEFI) solutions seems like a good idea. :) Should I just choose the default selection for UEFI (which is: edk2 - mrchromebox fork)?

So we can chose either edk2 OR seabios payload and we should be re-booting fine?
So what should I choose? :)

I want to switch from AMI Bios to coreboot on my Topton N150 box, which is currently running opnsense 25.7 (barebone).

So I am configuring coreboot (v25.12) for my mainboard (Topton ADL: TWL (X2E_N150)) on a fedora box and I am currently stuck at figuring out what payload I should choose.
This is what gpart sais about my nvme disk containing opnsense:

Code Select Expand

$ gpart show
=>       40  488397088  nda0  GPT  (233G)
         40     532480     1  efi  (260M)
     532520       1024     2  freebsd-boot  (512K)
     533544        984        - free -  (492K)
     534528   16777216     3  freebsd-swap  (8.0G)
   17311744  471085056     4  freebsd-zfs  (225G)
  488396800        328        - free -  (164K)


AFAIK, I can not use seabios payload as it requires an MBR partition...or does it? Do I have one? Maybe it is hidden?
Sorry if this is a stupid question - but when I flash this coreboot.rom I'd REALLY like my router to boot up again... :)

Also the temp values jump around quite a bit (for me on a n150 at least). Just check the sysctl a view times and you may get +/-5°C each time. :)

vvd@mrqu:~ $ cpuinfo
dev.cpu.0.freq: 955
dev.cpu.0.temperature: 48.0C
dev.cpu.1.freq: 1171
dev.cpu.1.temperature: 48.0C
dev.cpu.2.freq: 1389
dev.cpu.2.temperature: 47.0C
dev.cpu.3.freq: 1511
dev.cpu.3.temperature: 47.0C
vvd@mrqu:~ $ cpuinfo
dev.cpu.0.freq: 1876
dev.cpu.0.temperature: 54.0C
dev.cpu.1.freq: 1664
dev.cpu.1.temperature: 53.0C
dev.cpu.2.freq: 1612
dev.cpu.2.temperature: 51.0C
dev.cpu.3.freq: 1612
dev.cpu.3.temperature: 51.0C
vvd@mrqu:~ $

Ah ha. Yes that makes sense.


Will there be a way that you can stop it looking for IPv6, maybe after a short timeout, if it's not available?

Probably not. Then it would stop trying for legitimate ipv6 setups that have a temporary failure.

The serial console spams the login prompt when I initally connect to it (putty). Once I hit enter it stops and I can login and use it normally.
Should I be worried? Anytging I should check? Thanks!

Maybe @franco or another developer can chime in on this. Seems like we have some air for improvement here. :)

Well, when you select multiple targets for a pass rule then there are multiple rules created in the background, one for each target (or source in your case). When you invert the meaning for the target (or source) you basically get an allow all ruleset. Because the second rule passes traffic that the first one did not allow.

I also think that this is an issue.

To not break current rulesets the only solution that I can see is to reflect the fact that there are multiple rules created in the background in the UI (you can have a look at /tmp/rules.debug). Like showing those rules indented and slightly greyed out below the rule. That way you get a hint why it does not work as you may have intended.

I think it is better to keep using aliases for this usecase, as you end up with only one rule.. which results in better lookup performance.

I am not sure if this is a bug. It is certainly not working as you and I expected. But changing the behavior now (like using an automatically created alias) would potentially break existing rulesets... even though that would probably ,,fix" what this feature intends to do, but currently does not? I don't know.

Maybe there is a developer reading this :)
Anyway, it is always good to have one good, working Boot Environment other than the default, running one!
It's a good safety net, should you mess up

Why aren't they called boot environments though? Or bootable snapshots?

Did you set a ,,DHCP Unique Identifier" and enabled ,,Prevent release" in Interfaces->Settings?
For the unique identifier you can use the ,,insert existing DUID" below the input field.

I don't actually know if it will work, but I had the same issue. But since I set the DUID yesterday, I ll get the same prefix after a reboot. Hope it will stay that way...

This explains the DUID: https://datatracker.ietf.org/doc/html/rfc8415

I just got one of those Topton Intel N150 4 port fanless mini PCs from AliExpress to replace my APU2D4 (160 Euros inkl shipping).
I feel I've made a good choice. I've added 16GB DDR5 and a "low power" nvme SSD (WD Green SN350 250GB 2G0C).
I just renamed all occurences of igb to igc in the config.xml and imported it, resetted tunables and added some for RSS and Intel Speed Step or whatever (PowerD is disabled).
So far no issues and a blazing fast web interfcae :)

It doesn't have a BIOS to limit the CPU voltages. But the box is not running hot:

Code Select Expand

$ sysctl -a |grep temperature
hw.acpi.thermal.tz0.temperature: 27.9C
dev.cpu.3.temperature: 50.0C
dev.cpu.2.temperature: 49.0C
dev.cpu.1.temperature: 47.0C
dev.cpu.0.temperature: 48.0C
You cannot view this attachment.

It could be used for the ,,This Firewall" and (self) UI rules...hmm

They are not used anywhere (it seems) but I have two of those: one includes all ipv4 node addresses and the other all ipv6 node addresses.
Using OPNsense v25.1

The policy based routing rule did not work as a solution (as you may have suspected). Basically it was a allow all rule that routed all traffic to the wan (including everything that would normally route to local networks). XD

So I created a nested alias and using that works as expected.

But shouldn't a selection of multiple target aliases create a new alias automatically?
The problem is: You see one rule in the UI but get multiple rules in the back which behave differently than expected.
Either that, or all the created rules should be visible in the UI as well.

@Franco is this something you would agree to?