In case this problem is of any concern to anyone else and not just myself,
the following is the minimal patch that I could come up with that preserves
the idempotency of /usr/libexec/reorder_kernel and thus does not create any
unnecessary corner cases that need to be taken into account separately:
--- reorder_kernel.orig Thu May 7 10:52:19 2020
+++ reorder_kernel Fri May 29 03:56:58 2020
@@ -46,7 +46,6 @@ if [[ -f $KERNEL_DIR.tgz ]]; then
# stdout again to a new logfile.
exec 1>$LOGFILE
tar -C $KERNEL_DIR -xzf $KERNEL_DIR.tgz $KERNEL
- rm -f $KERNEL_DIR.tgz
fi
if ! sha256 -C $SHA256 /bsd; then
On Thu, May 28, 2020 at 4:25 AM Connor Schech <sch...@gmail.com> wrote:
> It's important to note that the SHA256 hash checked against /bsd stored in
> /var/db each time reorder_kernel is called has no bearing on the integrity
> or consistency of the files present at compile-time for the next reordering
> in /usr/share/relink. If a signed SHA256.sig file (or two, GENERIC.sig and
> GENERIC.MP.sig) for all the individual link-kit objects from the 53mb
> kernel.tgz file embedded in base67.tgz were also present inside base67.tgz
> in the relink dir next to kernel.tgz, all the signatures could be verified
> before relinking for either GENERIC or GENERIC.MP and the objects
> reordered each time from either relink location would be guaranteed to be
> the same ones from the initial release. Then repopulating them if they are
> deleted in either or both locations wouldn't require reordering two kernels
> or maintaining two sets of uncompressed objects, if need be kernel.tgz
> could be extracted again for either configuration and the signatures
> verified before running make once on one set of objects.
>
> On Thu, May 28, 2020, 03:57 Stuart Henderson <s...@spacehopper.org> wrote:
>
>> On 2020/05/27 22:50, Connor Schech wrote:
>> > I compressed the GENERIC link kit with tar czf and it becomes 114MB, all
>> > other things being equal to what is done now. That becomes significant
>> for
>> > users with many instances or embedded devices. There are trade-offs
>> > involved, so to speak.
>>
>> Relinking once is already quite heavy and makes some systems unusable,
>> this at least applies to slower machines using the architectures with
>> wide hardware support in the kernel, i386 probably being the worst case
>> - some of the smaller arches like landisk cope better, partly because
>> there's less in the kernel and partly because they use ld.bfd which
>> uses less RAM. Extracting from tar.gz and linking twice is going to
>> be way too much for these.
>>
>>
