I’ve been trying to follow the instructions below, which seem out of date as there are no configuration data prompts:
It fails on the ./make.sh build under stage 2 with “Building stage2 chroot: failed to run command ‘env’: No such file or directory” repeated 6 times, and I can’t find any information on my own on how to fix that.
I’ve tried on fresh VM’s with Ubuntu 21.04 and Linux Mint 20.2, both x64 based and the error occurs with and without the linux32 commands specified in the guide.
Hi @phane
Yes, you are right, it is a bit out of date. I will have a look at updating it. You can ignore all the linux32 bits. They are no longer needed as everything works with 64 bit now.
This message means that the extraction of the toolchain was not successfully done.
Try the
./make.sh gettoolchain
command again.
This needs to run successfully before you can do the build step. If the toolchain command fails again then check that zstd is installed. The compression of the toolchain was changed in the last month to using zstd.
Once toolchain has been run successfully then you can do the ./make.sh build
Good luck with your building and just let us know if you need any further help.
I got that far, which is great. Thank you.
Now I try to do follow the instructions here (not sure if they are also outdated):
And run into problems where the make process fails with a missing file (check.mk) that I know is in the archive and subsequent changes to the LFS file don’t seem to be seen when rerunning ‘./make.sh build’
In other words, adding a ./configure line to the LFS file and then running ./make.sh build again ends up with ./configure not running, as if it has the original LFS file cached somewhere and doesn’t look for the modified one.
Edit: Apparently my LFS script had $(DIR_APP)/filename in places and IPFire’s dev build didn’t like it, using cd $(DIR_APP) && dothisandthat worked instead.
Hello James,
the build environment will only build packages that have not been built yet.
The status is stored in the log/ directory. You can delete the file for the package you want to rebuild and run “./make.sh build” again.
I think that the problem was that I wasn’t looking at the console output but was looking at _build.ipfire.log and I didn’t realize that that file wasn’t cleared each time you run make.sh, so I kept looking at the error from the first run attempt.
EDIT: The file under log that is created after a successful make and make install is blank. I don’t know why since the install process obviously installed files under build. The make process also didn’t create the expected packname-source file.
If you are doing a repeat build and and need to see that file recreated in the log directory then you need to do a ./make.sh clean before repeating the ./make.sh build
This will mean that the whole build is repeated from scratch.
Deleting the package log file and repeating the build is useful if you are getting errors in your build and want to change things to see if you can fix them without doing a full clean and build but once you have solved your package build problem then you do need to do a full clean and build to get the correct final package.
That fixed it, thanks. Having to recompile the entire distro 3 times to get an addon to compile seems extreme. Anyway, I got it to work.
So now there is only one remaining issue, that should be easy to resolve. The init.d script as compiled has the following line for the switch case:
. /lib/lsb/init-functions
This seems to be because I compiled it under a Debian distro, but I can’t seem to find the IPFire alternative command to test for start, stop, restart, status.
For addons and for core packages but you have to live with that. This is a consequence of how IPFire 2 was originally constructed many years ago.
IPFire 3, which is being worked on as and when time is available, will allow building of each package individually but that is still work in progress.
IPFire has its own initscripts systems. I used that for the bacula addon and it works fine. Those iniscripts also then interact with the services.cgi WUI screen so you can see the status of the addon on that page.
Here is the link to the template
https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/system/template;h=69dc2a6a2202fb30da61a7fff6625aea531802e9;hb=HEAD
You will also find it in the build in
src/initscripts/system/template
The template acts as a boilerplate and you can look at how other addons have used it by looking in their initscripts which can be found in
src/initscripts/packages
Look in the bacula lfs file to see how to install the initscript in IPFire.
Progress! Thanks for all of your help. The add-on now starts, stops, restarts when I directly call it in the init.d script.
However: It does not show up in the WUI under Status, Services and it does not start at boot. I’d be happy, I guess, if I just created a symlink in rc3.d to start it up under runlevel 3, but I’m guessing that it not showing up in the WUI is a problem?
Yes, you need to add the rc symlinks into your install.sh script. Look at the
src/paks/bacula/install.sh
for an example of the symlinks and at the uninstall script for removing them.
Not a big problem because you can still start and stop the daemon from the command line.
However, I realised why it will not show up in the services page - because you are manually installing the addon and so not all the steps with fully released addons is carried out.
I believe if you create a blank file in the following location - replace addon with the name that you are using for the addon you are building - then it will show upin the services page.
touch /opt/pakfire/db/installed/meta-addon
For a fully installed addon this file also includes a pgp signature so that IPFire can be sure that the file has been correctly installed from the correct place. As you are manually installing your addon I believe that the contents are not used and so you just need the file to be present because that is what the services.cgi perl code looks for.
Did that manually. I don’t need a working install script, I just wanted this working on my own build.
That worked. It’s under the Addon - Services page. Thank you very much, everything is working perfectly now!