Failure while building for arm64 / NanoPI R4S #264
Comments
|
@turboproc no idea, sorry |
|
Hi @yrzr as you seem to be the expert on this topic, any clue what might be happening above ? |
|
The issue somehow looks familiar. I recall there being a thread on the forums. What worked out for me was downgrading to pkg version 1.16.3 manually (I guess a fresh FreeBSD 13.0 install downloads 1.17.5 atm). Not all packages could be built though (specifically those ones requiring go). I had to build the latter on my arm device. Maybe @yrzr has a better solution. It would be very convenient if someone could simply provide the generic arm64 packages (base, kernel etc.) for 22.1. Unfortunately, I don't have a powerful machine atm and building all ports, plugins, core etc. from scratch took almost 2 days. EDIT: Here is the thread in the forums |
|
OK, that might be worth trying. Just need to find out how to downgrade pkg from 1.17.5 to 1.16.3. Couldn't find that in the thread you referred to. |
|
In your previous post you can see that pkg v. 1.16.3 is being downloaded. Unpack the archive, cd into the folder and run ./configure && make install clean (it's kinda a dirty way to do it, but yeah). I decided to give another try for the 22.1 release. Cross building on an amd64 host for arm64. No issues compiling base and kernel, however, regardless of the pkg version, I run into issues if I build "xtools" prior to "packages". For whatever reason, I get multiple errors. I am currently building the packages. Let's hope all goes well :) |
|
Hi @efetropy , thnx for your support. Let's see how this is going to work. Please keep me posted on your package building. |
|
Didn't encounter any issues so far. It's been almost 24 hours and roughly 25% of the parts are built. Kinda getting impatient as it's taking ages. If I have time, I will look into the xtools issue and maybe will come up with something. |
|
OK, doing here a different experiment: running a complete FreeBSD-aarch64 instance within qemu-aarch64 on a AMD64 host aarch64. Within this instance I can do a full native build. Just a kind of very slow. |
|
@turboproc I canceled the build since it was taking too long, but can confirm that around 350 packages were built successfully (which if I am not mistaken is roughly half the packages that are built for arm64) which roughly took 40 hours on my computer. Also tried to reproduce the error you are getting and my initial guess that native-xtools is the culprit turned out to be the case. I used both the 13 RELEASE and 13 STABLE versions to see whether it's going to make any difference. In either case, I ran into the same error as you did. It builds fine once you move/delete the xtools set. At this point I can't tell whether I really want to build everything in five days or just wait for someone to do the work and hopefully upload the sets. |
|
@efetropy , thnx for feedback. So at least the native-xtools issue has been identified. Would there be any owner to fix this? Moving forward with FreeBSD-13-aarch64 running competely in qemu-system-aarch64 on a AMD64 host. Arrived at 159 packages. Will take some more days. |
|
Actually, I am still facing the problem in issue 258. Are you building the following stages with the official base package from FreeBSD 13? |
|
@yrzr I was facing the very same problem back in December while building the beta (running a recent FreeBSD 13 STABLE build on an amd64 machine). Unfortunately, I don't remember how I fixed it, but I vaguely remember doing something in the device configuration file. Probably related to Furthermore, I also had a look into the verbose messages when you initially run make. With On the other hand, the source tree of the host system I was building on matched the source tree of opnsense. Maybe that's why it worked. No clue, I am no expert in this regards :/ @turboproc I decided to go for a native arm64 build this time. Kinda sucks that there are no 13 STABLE builds available for my device since January, so had to build my own image and sort some issues with nvme. All in all, it's all set and building packages now. UPDATE: After 6 hours, 230 packages built, 1 failed (powerdns-recursor, will rebuild that at a later point), 1 warning (some inconsistency with qemu-guest-agent). Looks promising so far and much faster than cross-building on my amd64 host. |
|
@efetropy Thanks, let me have a try |
|
Here is an update. I successfully managed to build the packages with only 2 errors and a warning on my arm64 device in less than 20 hours. Ran into a kinda expected problem though – the packages set couldn't be created since pkg (1.17.5) claims that no packages (*.txz) can be found. It's a known issue and the only fix I am aware of is downgrading pkg to version 1.16.3 on the host. |
|
@efetropy I have successfully built images here. I will try the images tomorrow. Feel free to use the packages I built. |
|
@yrzr Glad to hear that it worked out in the end and thank you for the link to the repo :) UPDATE: UPDATE 2: Up and running on my ROCKPRO64 |
|
Great news! I have also encountered some failure for some packages |
|
@yrzr Not sure whether these packages support arm64 or not as they are marked as "IGNORE", but here is my two bits regarding rust. Haven't tried cross-compiling it, but from what I read on the internet, you need a machine with a lot of RAM (maybe even swap and unlimited tmpfs?). Since suricata also depends on rust, I guess that's the reason why it's failing. Someone claims to have built rust on a ROCKPro64 (4GB RAM) with -j1 in 14+ hours. Here is a link for reference: |
|
we only need rust for suricata and that is being excluded for arm builds at least from core level (same for beep): https://github.com/opnsense/core/blob/master/Makefile#L126-L127 at a quick glance flashrom and devcpu-data is for intel/amd only... it might make sense to exclude most if not all of these ports IMO it looks like the ignore doesn't work... Line 5 in a99e8b6 |
|
@fichtner I was surprised to see that @yrzr was building those packages. I built the packages set with Either @yrzr is running some test to see which flagged packages are built successfully and can be included or is using configs with different "IGNORE" flags. |
|
@fichtner Yes, I agree. I think the |
|
@efetropy I am using an ARM device with 4 A73 cores and 5G RAM. It seems the RAM is not enough to build rust with 4 threads. I am now trying to build this package on AMD64. |
|
@yrzr Building rust with low RAM is indeed a headache. The guys in the link I posted earlier were building with |
|
Packages stage for aarch64 now built without any errors with the commit #267 |
|
@yrzr thanks, closing now |
|
@efetropy Which u-boot did you use for r4s? The u-boot from the packages |
|
@yrzr I actually do not own a r4s. Only have Pine ROCKPro64 (also based on rk3399). Do you have your own device config for that or are you just writing the bootloader files into the generic image? EDIT: Just checked out your repo and realized that you are using your own device config file. Let me know if you manage to make u-boot work on the R4S. If other bootloader files are not working, it's probably due to additional required conf parameters. |
|
@turboproc did you have any luck building an image for the R4S? |
|
@efetropy Thanks, now I am facing kernel panic. Let me dig into r4s. @fichtner any advice? |
|
@yrzr did you set the parameters from the link I sent you? Here is a link to my OPNsense ROCKPro64 image: https://we.tl/t-wmwApBmSNb |
|
@efetropy After a full rebuild, everything works fine now. Don't know the reason, but still thanks for the help. |
|
@efetropy : started a complete new rebuild last weekend. This time I used the nightly build option. Finished the process this morning and have it up and running. No issues with go or telegram. Just an issue with signing of packages. Packages have been signed by OPNSense is refusing because of an unknown CA. Guess this is not something special but kind find the steps to resolve this. Any hint would be very welcome. |
Spend this week on bringing up a Rock PI 4 and that cause a lot of trouble with U-Boot. The R4S boots without any issue using the standard image been created. (one issue I had with the Rock PI was a bad transfer of the image to a SD card. Switching to the linux dd command solved that problem). |
Getting an error when building the packages (base and kernel work fine). Error message looks like below and occurs for every package:
[20220201072918] ===> License OpenSSL accepted by the user ===> openssl-1.1.1m_1,1 depends on file: /usr/local/sbin/pkg - not found [20220201072918] ===> License BSD2CLAUSE accepted by the user [20220201072918] => freebsd-pkg-1.16.3_GH0.tar.gz doesn't seem to exist in /usr/ports/distfiles/. [20220201072918] => Attempting to fetch https://codeload.github.com/freebsd/pkg/tar.gz/1.16.3?dummy=/freebsd-pkg-1.16.3_GH0.tar.gz fetch: https://codeload.github.com/freebsd/pkg/tar.gz/1.16.3?dummy=/freebsd-pkg-1.16.3_GH0.tar.gz: size unknown fetch: https://codeload.github.com/freebsd/pkg/tar.gz/1.16.3?dummy=/freebsd-pkg-1.16.3_GH0.tar.gz: size of remote file is not known freebsd-pkg-1.16.3_GH0.tar.gz 3744 kB 4202 kBps 01s [20220201072920] ===> Fetching all distfiles required by pkg-1.16.3_1 for building [20220201072920] ===> Extracting for pkg-1.16.3_1 [20220201072920] ===> License BSD2CLAUSE accepted by the user [20220201072920] ===> Fetching all distfiles required by pkg-1.16.3_1 for building [20220201072920] => SHA256 Checksum OK for freebsd-pkg-1.16.3_GH0.tar.gz. [20220201072920] ===> Patching for pkg-1.16.3_1 [20220201072920] ===> Applying FreeBSD patches for pkg-1.16.3_1 from /usr/ports/ports-mgmt/pkg/files /usr/bin/sed -i.bak -e "s|-llzma|-llzma -lmd|g" /usr/obj/usr/ports/ports-mgmt/pkg/work/pkg-1.16.3/auto.def /usr/obj/usr/ports/ports-mgmt/pkg/work/pkg-1.16.3/src/Makefile.autosetup /usr/obj/usr/ports/ports-mgmt/pkg/work/pkg-1.16.3/tests/Makefile.autosetup [20220201072920] ===> Configuring for pkg-1.16.3_1 No installed jimsh or tclsh, building local bootstrap jimsh0 No working C compiler found. Tried cc and gcc. [20220201072920] ===> Script "configure" failed unexpectedly.Any clue what might be wrong ?
Building on a clean FreeBSD 13.0 release and building OPNsense stable/22.1
The text was updated successfully, but these errors were encountered: