OpenWrt Forum Archive

Topic: Trouble Booting Openwrt x86 and/or x64 on Qotom mini PC

The content of this topic has been archived on 24 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Hello,

I have been attempting to install openwrt x64 or x86 (64 prefered, I have 8GB of RAM) on a Qotom mini PC.
I originally purchased this to run pfsense on, and it installed fine, but gaming and pfsense do not agree. So I wanted to try Openwrt instead.

I installed using instructions I found  on we.riseup. I cannot post links or I would link to it

It basically has me booting up on a linux distro live Cd (I used Lubuntu). Then used zcat to push the image to the disk.

When the machine boots, openwrt hangs at "net: registered protocol family 24". Fail safe does the same. I have tried both the latest stable and the lastest trunk build, these failed at the same spot.

The Qotom PC has the following specs:

Onboard CPU:Intel Celeron Processor 3215U (2M Cache, 1.70 GHz, Broadwell)
Memory:SO-DIMMs Support DDR3L 1333/1600 MHz,1.35V 1 x DDR3 DIMM Memory Slot ,Max. Support up to 8GB Memory
Hard Disk:support SSD ( MSATA / SATA) - support HDD (2.5 inch SATA HDD )
Onboard VGA:Intel HD Graphics
Onboard LAN:4 x Intel I211-AT- 10/100/1000 Controller
Audio Solution:Realtek ALC662 6-Channel HD Audio

Front-Panel Connectors
power on/off button
2 x USB 3.0 Ports
2 x USB 2.0 Ports
1 x HD Video Connector
1 x Serial port

Internal Connectors
1 x Minipcie port (for mSATA SSD)
1 x Minipcie port (for WIFI/BLUETOOT Module)
1 x DDR3L SO-DIMM Memory Slot
1 x SATA Port
1 x SATA power connector
1 x Automatically boot jumper

Back-Panel Connectors
1 xDV 12V DC input
HDD LED, Power LEDs
4 x Intel RJ-45 Ports
1 x Speak Out Connector
1 x Mic In Connector

I used a 64GB transcend msata drive, and an 8GB DDR3 Crucial RAM module.

I appreciate any help. What other information can I provide?

Do you think I could get around this by building a custom image, is msata supported in Openwrt? I appreciate any help. Thanks in advance.

I'd be working out why pfsense and gaming don't agree.  IMO if you have that kind of hardware available I wouldn't be bothering with OpenWRT.

you need post boot log.

Felipee07
thanks, I would be happy to.

However, I am having some problems doing that, I have used the settings from here:

wiki.openwrt.org/doc/howto/log.essentials

and I am trying to write a log file to /var/log/messages/sys.log

but nothing ever gets written there,

it seems to delete the message after every boot. I am attempting to read the log file by booting into lubuntu so I can access the files on the system, and the Log folder is always not there, even when I create it myself and reboot.

npkamen:
I have done extensive troubleshooting with pfsense, over the course of a few months. I have reached out to the forums there, and found that there really is no way to get it working with multiple gaming consoles, and can connect back to each other and play together. 

The Underlying problem is that pfsense is built on BSD packet filter, which is only able to create a symmetrical NAT. This type of NAT is completely unsupported by console gaming systems. I can resolve it for one of them by creating a static port mapping for my gaming sub net, however, this still has problems with machines communicating with each other. 

I need a cone NAT, which simply cannot be created using packet filter (pf). This was confirmed by senior members at the forum. I could make it work perfectly for external connections, but I just cannot get it working so we can play in one party.   All my setups include using upnp as well, and I have confirmed it is working, however because a symmetrical NAT creates one UDP connection per destination, not per port. It also only allows traffic back through those  ports from destinations that those ports connected to, which will block xbox live traffic, since consoles try to communicate though the same ports that you originally connected to xbox live on. This happens regardless of your firewall rules, I have made the most open firewall rules imaginable, and it is still not able to make it thought the NAT, so it never makes to to the firewall. 

I also have native ipv6, so I tried that, It didn't seem to work, then I went one step farther and disabled ipv4 traffic on my network. The xbox could connect to live, but the game said I had no internet connection. Then I found a post from a developer that stated that the game did not support ipv6, even though the system did. So that was out. (My roommates started saying that we needed to smash the "pfchang box" or whatever it was called.)

I also looked into getting Untangle, or Sophos. But those are even more enterprise oriented than pfsense, they do not have a upnp implementation at all.

I have seen posts here that indicate that openwrt uses a cone NAT, and since it is based on iptables, and iptables can create a cone NAT, I thought it would work better.

(Last edited by jax7778 on 26 Oct 2016, 15:04)

I think you should try and download the openwrt-15.05-x86-64-combined-ext4.img.gz image and then just dd it to the disk. If it boots, then you can resize the rootfs afterwards quite easily (just use parted to delete the partition and recreate it with a larger size, although be sure to first convert the ext4 to an ext2, then resize partition, then use resize2fs to resize the filesystem, then add the journal with tune2fs to make it ext4 again).

This should eliminate whether your install procedure causes the problem or whether it's due to unsupported hardware.

npkamen wrote:

I'd be working out why pfsense and gaming don't agree.  IMO if you have that kind of hardware available I wouldn't be bothering with OpenWRT.

I have even more powerful hardware and still run openwrt. It's much more customizable, supports a wider range of hardware and has many, many more packages. I don't think pfsense lives up to its hype...

The problem is for anything in this class of hardware you need to be able to build it.  OpenWrt is deliberately thin to fit on small flash\ram embedded platforms and one needs to load support for everything.

While pfSense may not work for this application, there are other open source distros like ipFire.  They come with (most) all the drivers are a couple hundred MB which is trivial for even a small HDD or SSD.

RangerZ wrote:

The problem is for anything in this class of hardware you need to be able to build it.  OpenWrt is deliberately thin to fit on small flash\ram embedded platforms and one needs to load support for everything.

While pfSense may not work for this application, there are other open source distros like ipFire.  They come with (most) all the drivers are a couple hundred MB which is trivial for even a small HDD or SSD.

Agreed - I run a roll-my-own Openwrt that has kernel config changes more appropriate to a larger 64-bit system and use glibc. Definitely need to be able to build the system for this class of hardware. Never looked at ipfire....

Some of my bias is perhaps due to long familiarity with Openwrt and the fact that I can usually get it to do what I want it to do, so there are only marginal benefits to be gained by moving to another disto that are likely outweighed by the learning curve and reconfiguration time I'd need to spend making the new system do what my Openwrt system does (hardware assist crypto, selective vpns - both openvpn and strongswan, netflow agent, remote logging into graylog, snort, decent QOS, RBL blacklists, modified bonding driver for aggregating two internet links, easy wireless configuration and VLANs, IPv6 that just works out of the box). And most of the time I edit firewall rules manually due to long experience with iptables, so a pretty iptables GUI is not much of a draw for me.

The only real gripe I have with Openwrt is way too much focus on adding new features and new kernel versions and almost no attention to the "stable" branch and accompanying patches, bug fixes etc. I need to watch out for and patch bugs myself (for example, the recent CVE-2016-5195). Trunk is usually so buggy and unstable that it requires constant updates, something that becomes onerous when running a heavily modified distro as frequent upstream changes need to be merged into the modified code.

Anyway, I suspect we're reaching the point of hijacking the OPs thread...:)

To the OP, just noticed this thread - maybe you want to give it a try. Looks impressive, although haven't tried it myself. With a 4.5 kernel it is likely to support many hardware configs out of the box.

dl12345  , That looks great! I will download and run that image and see how it goes. Thank you very much for your suggestion.

The discussion might have continued from here.