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>
The installer was reading the kernel command line and was looking for
certain values which configured the installer.
GRUB appended a trailing newline character which was not accounted for
and caused that the last parameter was not correctly compared to the
list of possible keys.
Fixes: #12656 - core 157: unattended installation don't work as expected on EFI
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
AWS for some time now has a serial console feature which is enabled by
default on all systems. The VGA console is not enabled for any new
non-x86 instance types and not interactive.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
with kernel 5.10.x also the reading of s.m.a.r.t. data to update
the temperatur graphs is countet as disk read so update the stored
value after reading.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
During the build process, we set capabilities to elevate privileges of
certain progrems (e.g. ping). These have been removed during the build
process because of strip.
This patch collects any capabilities from all files that are being
stripped and restores them after calling strip.
Fixes: #12652
Reported-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
Acked-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
After upgrading to Core Update 157, a few number of users reported their
systems to be unworkable after a reboot. Most of them (the systems, not
the users) were apparently missing the new Linux kernel in their Grub
configuration, causing a non-functional bootloader written to disk.
While we seem to be able to rule out issues related to poor storage
(SDDs, flash cards, etc.) or very high I/O load, it occurred to me we
are not calling "sync" after having extracted a Core Update's .tar.gz
file.
This patch therefore proposes to do so. It is a somewhat homeopathic
approach, though, but might ensure all parts of the system to have
properly processed the contents of an extracted archive. While we cannot
even reasonably guess it will solve the problem(s) mentioned initially,
doing so cannot hurt either.
See also:
https://community.ipfire.org/t/after-update-ipfire-to-157-no-boot/5641/45
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@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>
with kernel 5.10 dhcpcd hung at shutdown if red was a wireless client
becuase there was two running instances. This change repeat the
dcpcd -k call.
Signed-off-by: Arne Fitzenreiter <arne_f@ipfire.org>
This reverts commit 86beff5f75.
This patch breaks reading statistics on systems running a 4.14 kernel.
It seems like it is not dependant on the kernel, though.
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This also moves existing patches into their applications' directory
within ~/src/patches/, if already existant.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
This patch represents the first batch of various patches we do not use
anymore, hence there is no sense in keeping them, polluting ~/src/patches/.
Two coreutils patches have been moved into the already existing
coreutils folder, while one libloc patch has been a duplicate to that
one already existing in ~/src/patches/libloc/.
Cleaning up this dump remains a non-exhaustive attempt, though. There
are several other patches I could not locate in LFS files in the first
place, which means that the amount of files we can drop from this
directory is likely to be greater than this patch currently covers.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
- Update from 2.49 to 2.50
- Update rootfile
- Version 2.50 failed to install capsh - bug raised for this
https://bugzilla.kernel.org/show_bug.cgi?id=213261
patch to fix this bug created and used in this build
- Changelog
Release notes for 2.50
2021-05-24 12:05:16 -0700
Some new capsh features:
--explain=cap_foo: describe what cap_foo does (Bug 212451)
--suggest=phrase: search all the cap descriptions and describe those that match the phrase
Add "keepcaps" module argument support to pam_cap.so (reported by Zoltan Fridrich. Bug 212945)
extend libcap to include cap_prctl() and cap_prctlw() functions to regain feature parity with Go "cap" package. These are only needed when linking against -lpsx for keepcaps POSIX semantics.
this likely requires substantial application changes to make Ambient capability support usable in general, but doing our part for the admin.
Add a test case for recent kernel fix (Bug 212737)
Go pragma fix for convenience functions in "cap" module (reported by Lorenz Bauer. Bug 212321)
Minor man documentation updates
Minor build tree improvements (mostly for maintainer)
Signed-off-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This patch represents the first batch of various patches we do not use
anymore, hence there is no sense in keeping them, polluting ~/src/patches/.
Two coreutils patches have been moved into the already existing
coreutils folder, while one libloc patch has been a duplicate to that
one already existing in ~/src/patches/libloc/.
Cleaning up this dump remains a non-exhaustive attempt, though. There
are several other patches I could not locate in LFS files in the first
place, which means that the amount of files we can drop from this
directory is likely to be greater than this patch currently covers.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This package seems to be unmaintained for at least five years. It's
(former?) upstream traces back to https://section5.ch/index.php/2011/01/13/dpf-hacking/,
but download links to both dpfhack and a patched version of lcd4linux
point to http://localhost/.
http://tech.section5.ch/files/dpfhack-0.1alpha.tgz still serves
something apparently related to dpfhack, but it is unclear whether that
is a previous version than the "0.12devel" we know about, or a
successor. https://tech.section5.ch/files/dpfhack-0.1alpha.tgz, just to
have it noticed, comes with a X.509 certificate not issued for this
FQDN.
dpfhack is solely needed as a dependancy for lcd4linux, which appears to
be unmaintained as well, hence being dropped in a dedicated patch.
Given the status quo, bugs in dpfhack cannot be reported properly,
security issues won't be addressed (by anybody else then ourselves), and
technical questions cannot be clarified aside a reverse engineering
approach.
We should not allow such an add-on to be installed on a firewall system.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
This package has not received any updates or attention within the last
three years. It's sole known upstream URL (https://ssl.bulix.org/projects/lcd4linux/)
returns a HTTP error 404 nowadays, and the author was unable to locate
any upstream source that appears to be still maintained today.
Given the status quo, bugs in lcd4linux cannot be reported properly,
security issues won't be addressed (by anybody else then ourselves), and
technical questions cannot be clarified aside a reverse engineering
approach.
We should not allow such an add-on to be installed on a firewall system.
Signed-off-by: Peter Müller <peter.mueller@ipfire.org>
Reviewed-by: Adolf Belka <adolf.belka@ipfire.org>
Signed-off-by: Michael Tremer <michael.tremer@ipfire.org>
