@Andy2244 No luck with the new qemu version either, sorry. Is there another log I can look into to provide more information on the coredump?
The cause seem to-be: qemu: uncaught target signal 4 (Illegal instruction) - core dumped
which indicates a problem executing the cross-compile test files in qemu.
My guess was a 32bit vs 64bit host system problem, but in my VM ubuntu 32bit had no problems. Are your by any chance compiling on a real 32bit CPU or whats the reason you cross-compile on a 32bit Ubuntu?
Can you make sure you have qemu not installed as Ubuntu package on the host and uninstall it if you have or maybe try 64bit host?
Without being able to reproduce this problem its hard for me to guess, since it could be a lot of things.
PS: I could not find a 32bit server Ubuntu 18.x so i assume its some community version?
@Andy2244 I just upgraded my existing 16.04 LTS ubuntu to 18.04. That one was available as 32-bit and the OpenWRT guide recommends a 32-bit linux machine, so I built one. I am going to install a new 18.04 machine and start over (it may take some time before I get back). qemu is not installed in my Ubuntu vm so that is not the problem.
Where is 32-bit buildhost recommended???
(I have always used the 64bit Ubuntu, and that works ok. Openwrt itself is usually 64bit, so I believe that things go more smoothly with a 64bit buildhost (as sometimes there has been linking/header leakage, where the build has used some headers from the host.))
I am pretty sure it once was on the openwrt.org documentation somewhere, maybe years ago. I've been building my own openwrt images for 6 years or so and never had any trouble with my 32-bit build vm 
@avbohemen yeah sorry samba4 is a special case, no other package cross-compiles this way, but as noted i had no problems on my 64 or 32bit hosts, so something else is going on.
@hnyman:
Openwrt itself is usually 64bit
No, actually mostly it is not. ar71xx (and ath79), brcm63xx, ramips and even ipq806x are all 32-bit targets. I have not seen any home routers with more than 4GB of RAM so it is not needed either. Only x86_64 and a few arm64 boards are 64-bit.
@Andy2244 However, I made a new VM with 64-bit Ubuntu and recreated my build environment. Guess what: still the same error. Which made me think about the following: Illegal instruction, is that maybe caused by qemu requiring a fairly new cpu architecture? Mine is running on an old Westmere cpu (Core i7 920). Is it possible to configure or compile qemu for older cpus?
@avbohemen I build qemu in usermode and disable any advanced feature, yet i could not find a specific hardware requirement in this mode. There are 3 options that i had trouble researching and if they do anything in usermode. You can try comment those 3 options or go one by one and see if this helps. Its the first bug report i get with a qemu related problem, so can only guess atm.
# does this do anything in usermode?
CONFIGURE_ARGS:=$(filter-out \
--disable-hax \
--disable-kvm \
--disable-blobs \
, $(HOST_CONFIGURE_ARGS))
It seems the qemu host package did compile, so there should be a bunch of ./staging_dir/hostpkg/bin/qemu- bins.
Try directly invoking a different compiled binary like this:
./staging_dir/hostpkg/bin/qemu-mips -L staging_dir/target-mips_24kc_musl/root-ar71xx/ staging_dir/target-mips_24kc_musl/root-ar71xx/usr/sbin/smbd -V
Replace smbd with any binary that did compile and see if you get the same error. If so there are a few extra options of note:
-cpu model
Select CPU model (-cpu help for list and additional feature selection)
-d item1,...
Activate logging of the specified items (use ’-d help’ for a list of log items)
Environment variables:
QEMU_STRACE
Print system calls and arguments similar to the ’strace’ program (NOTE: the actual ’strace’ program will not work because the user space emulator hasn’t implemented ptrace).
PS: I think we have a old Core i7 920 at work, so can try recreate your environment, but if you can run Ubuntu in a VM than qemu in userspace mode should work as well.
@Andy2244 Ok, a few more tries... ./staging_dir/hostpkg/bin/qemu-mips -L staging_dir/target-mips_24kc_musl/root-ar71xx/ staging_dir/target-mips_24kc_musl/root-ar71xx/usr/sbin/smbd -V results in the same coredump/error 4/illegal instruction with every already compiled binary I have. Qemu-mips is compiled fine, and with every -cpu option I tried (4Kc, 24Kc, 74Kf, mips32r6_generic) it just won't run a mips binary.
Second, I moved my VM to a newer system (cpu is a i7-4720HQ - much newer), and I still get the same coredumps. So, the host cpu does not seem to be the problem, it is just that qemu on my system won't properly run anything.
@avbohemen oki that's really strange and i'm running out of options here. Can you open a issue on the git-feed, so i can track this better?
I would like to reproduce this problem, so can you post your exact VM/distro versions/settings and maybe all the shell steps you take up until the error, including your config diff on the git-hub issue?
So if i understand this correctly you moved your already build Ubuntu VM to a newer i7-4720HQ and still got the same error? What's the VM you use and was the original on the older cpu also a VM or some native linux box? (Hyper-V, VBOX, VMWARE ..?)
I made a new build yesterday, and it worked without any issues as usual.
just want to check with people who are testing this, do you see issues with files larger than 2GB?
I was testing the Samba 4.8.0 version on entware site: http://bin.entware.net/mipselsf-k3.4/samba4x-server_4.8.0-1_mipsel-3.4.ipk, it seems files larger than 2GB will fail. (more details are here: https://github.com/Entware/Entware/issues/77 )
1 Like
Fail in what way? With read or write?
Just tested this and had no issues with a 2.9 GB file (read/write) on a F2FS formatted drive using smb3.1. Did you try change/check if the reported filesystem type is NTFS, which should be the samba default?
Under windows the share properties page should list filesystem as NTFS.
## reported filesystem type (NTFS,Samba,FAT)
fstype = NTFS
Works just fine without fiddling with reported filesystem type (ext4)
That said, it's a 3rd party repo and seems to use hbl0307106015's version given the package name and not yours along with a very old kernel. Given that we don't have the source code it might be that it's lacking Large File Support for whatever reason?
1 Like
Thanks for the confirmation. That one was built by Entware team. Looks I need to learn how to build one myself to fix this 
Can someone build this for the ramips/mt7620 target?
In all honestly I wouldn't even bother as you need at least 16Mbyte of storage as Samba itself is about 6Mbyte (and that's without dependencies) not to mention that it would struggle as far as performance goes. You're much better off using NFS and/or Samba 3.X on such hardware. Being realistic I'd say that anything with lower performance than MT7621 (MIPS dual core 880Mhz) is unsuitable if you want acceptable performance and at least 128Mbyte of RAM (perferably 256+).
Update: I disabled netbios by default now, since Windows 10 in Workgroup mode isn't using it anymore. As a replacement i added a Web Services on Devices Name Service Daemon (wsdd2), which is enabled/build by default.
This means you should now see your samba shares in the explorer similar to Windows 10 created shares.
You can disable/stop the wsdd2 service if you don't need/want it and map your share via path (\\routername\sharename) to a drive letter as usual.
Thanks for everyone's help, I've built the samba 4.8.3 ipk package successfully. Since the package size is not small, I figured the best place is probably use opkg to install on USB drive. But it seems the package installation tries to modify some system files and failed due to root fs is read-only.
I guess the package is meant to be used as part of firmware, not optware/entware? Is it possible to tweak the build settings to make it suitable for optware/entware if so?