This is cosmetic change to have the name of the ISO file similar to the
flash image and also have all parts of it in a reasonable order.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Reviewed-by: Peter Müller <peter.mueller@ipfire.org>
Historically, the MD5 checksums in our LFS files serve as a protection
against broken downloads, or accidentally corrupted source files.
While the sources are nowadays downloaded via HTTPS, it make sense to
beef up integrity protection for them, since transparently intercepting
TLS is believed to be feasible for more powerful actors, and the state
of the public PKI ecosystem is clearly not helping.
Therefore, this patch switches from MD5 to BLAKE2, updating all LFS
files as well as make.sh to deal with this checksum algorithm. BLAKE2 is
notably faster (and more secure) than SHA2, so the performance penalty
introduced by this patch is negligible, if noticeable at all.
In preparation of this patch, the toolchain files currently used have
been supplied with BLAKE2 checksums as well on
https://source.ipfire.org/.
Cc: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Acked-by: Michael Tremer <michael.tremeripfire.org>
This patch uses the new Zstandard algorithm to compress the file system
image on the ISO image. This comes with these advantages:
* Compression is about twice as fast than XZ with the parameters we have
selected here
* We use a lot less memory during compression and can therefore utilise
all processor cores of the build machines
* Decompression (when installing IPFire and when creating the
flash-image) is substantically faster
The downside is that the generated ISO image is slighty larger (~10MiB)
which I am okay with as a trade-off for the points mentioned above.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
we have no supported armv5tel board left so we can switch to the higher
arch. This now can use the vpu (still in softfp calling convention to
not break existing installations.)
this fix many compile problems, also boost is now working again.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
System capabilities are stored in extended file system attributes
which are by default not stored in tar balls.
This patch ensures that they are packaged and extracted.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Since /tmp is now a ramdisk, we move all temporary files into it.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
In order to remove any duplicate files in the tarball, we
have to unpack it again. The whole filesystem is written
to disk twice which is unnecessary.
This patch removes that temporary step and reduces IO
during the build.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
Most of these files still used old dates and/or domain names for contact
mail addresses. This is now replaced by an up-to-date copyright line.
Just some housekeeping... :-)
Signed-off-by: Peter Müller <peter.mueller@link38.eu>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This allows systems to boot the EFI bootloader from the CDROM
file system instead of using the FAT filesystem which is for USB keys.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
For details see:
https://www.gnu.org/software/tar/
Since new 'tar' has changes in commandline option parsing,
it was necessary to adjust 'lfs/Config, 'lfs/cdrom' and
'lfs/core-updates' (thanks to Marcel for diffs and Michael for
corrections).
I have tried to make only the most necessary changes.
As always, please check.
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This caused that the xz command was called without any
extra arguments. This will now create the tar archive
first and then pass the archive through xz with our
command line switches.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Changes since V1:
- Tuned some more 'tar'-command lines
- Included 'lfs/core-updates'
- Some fine-tuning
Hi,
Current results with V2 (clean builds):
'next':
'packages' => 255 MB
'ipfire-2.19.2gb-ext4.i586-full-core121.img.gz => 319 MB
'ipfire-2.19.i586-full-core121.iso' => 218 MB
Total => 792 MB
'xz-tuning':
'packages' => 228 MB
'ipfire-2.19.2gb-ext4.i586-full-core121.img.gz' => 318 MB
'ipfire-2.19.i586-full-core121.iso' => 207 MB
Total => 753 MB (-39 MB)
It would be nice if someone could review and test these. ;-)
If necessary, I can upload a complete patch.
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Hi,
as mentioned in the "list", we're trying to make the archives as small as possible
using 'xz'-compression.
In order to achieve this, this patch tests the size of the memory available on the
host system.
It sets the xz-memory-limit (--memory=[N]Mib) to 70% of the available working memory,
a maximum of four xz-'worker threads' (-T4) and a compression rate of '-8' (-8).
These options are written to the 'XZ_OPT=' environment.
For details see:
https://linux.die.net/man/1/xz
I have set the number of available xz-'worker threads' (-T) to four (-T4), because during
the final tests the '-T0' parameter led to error messages snd stopped: 'cannot allocate memory'.
It wouldn't even run with 90%.
Furthermore, testing with '-T0' led to countless messages filling up '_build.packages.log'.
E.g.:
...
xz: Adjusted the number of threads from 8 to 2 to not exceed the memory usage
limit of 1557 MiB
...
Tests took place on a 32bit-Ubuntu 16.04.4-system with 8 GB RAM and an Intel I7-2600.
Build time was about 04:30 hrs. Perhaps a 64bit-system would perform better (higher
values), but my goal was to make this run on as many systems as possible, so I choosed
these averages.
If minimum requirements (1024 MB RAM) are not met, building stops.
Current results:
'next', untuned:
ipfire-2.19.2gb-ext4.i586-full-core121.img.gz => 332951687 Bytes
ipfire-2.19.i586-full-core121.iso => 228589568 Bytes
'next', XZ_OPT: -T4 -8, 70% RAM:
ipfire-2.19.2gb-ext4.i586-full-core121.img.gz => 329725723 Bytes
ipfire-2.19.i586-full-core121.iso => 217055232 Bytes
These two resulting archives are 14760300 Bytes smaller than before.
Best,
Matthias
Signed-off-by: Matthias Fischer <matthias.fischer@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This reverts commit d404b1dba2.
Intel has pulled these microcode updates because of
random system reboots and systems becoming unstable.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
The build environment is using a number of variables which
occasionally conflicted with some other build systems.
This patch cleans that up by renaming some variables and
later unexporting them in the lfs files.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
