ISEmedia / Clone glibc Upgrade — Checkpoint (2026-08-24)

Status: glibc 2.17 built and tested on Clone. make install NOT yet run.

What's done

• Clone (CentOS 6.10, VMware Workstation local guest) confirmed stable: SMF, MySQL, network all working, SELinux disabled, fail2ban disabled.
• yum repo access confirmed live via vault.centos.org (Live's yum.repos.d copied wholesale onto Clone). exclude=kernel* added to /etc/yum.conf on BOTH Live and Clone (cleaned up from 3 duplicate lines down to 1 each) — kernel packages permanently excluded from any yum update on both boxes.
• Toolchain installed on Clone: Development Tools group, glibc-headers, kernel-headers, bison, gawk, texinfo. devtoolset-2 (gcc 4.8.2 + matched binutils 2.23) was already present and used for the build instead of system gcc 4.4.7.
• glibc 2.17 source built successfully:
  • configure initially failed with a misleading "--no-whole-archive" error. Root cause (found in config.log, NOT what configure reported): a raw assembler incompatibility — gcc 4.8.2 was invoking the SYSTEM's old as (via default -B/usr/bin/) instead of devtoolset's matching one. Fixed by setting CC="gcc -B/opt/rh/devtoolset-2/root/usr/bin/" before re-running configure, forcing gcc to use devtoolset's assembler AND linker consistently.
  • configure then passed clean.
  • make -j2 completed with no errors (some warnings, normal for old source + newer compiler).
  • make check completed. Andrew chose not to review the pass/fail summary in detail (backups exist regardless) — if a close read of check.log is ever wanted later, that's the one open verification step skipped.
• Andrew is taking a fresh VM-folder backup of Clone (powered off cleanly) RIGHT BEFORE make install, as the best-known-good checkpoint — better than the earlier pre-toolchain backup, since this one is post-build/ post-check.

Decided

• Live's glibc is NOT being touched, ever — this whole exercise is Clone-only. Live was never meant to run torch; the intended architecture has Live doing only cheap cosine-similarity math on precomputed embeddings, with actual CLIP/Whisper inference happening on a separate box.
• The NUC (where Clone currently runs) will NOT become the permanent ISEmedia inference host — Andrew declined to open it up since it's also his personal/private-use machine.
• Plan: buy a separate dedicated machine for permanent inference duty (~16GB RAM, 8 cores, 1TB SSD, budget-conscious — refurbished/second-hand considered), running Ubuntu Server LTS (not CentOS) under VMware Workstation, specifically to avoid ever repeating this glibc-upgrade exercise. No GPU planned/needed — CLIP ViT-B-32 and Whisper-base are both fine on CPU-only for this workload (incremental cron indexing, not training or real-time inference).
• Not yet decided: exact new-machine spec/budget, whether it's new or second-hand, timeline for purchase.

Attachment backlog — now measured (was previously unknown)

• Combined across attachments + attachments2: 4321 files, 5668.6 MB total. Of that: 2417 image files (1037.0 MB) — what CLIP will process — and 24 video files (626.4 MB) — what keyframe extraction + Whisper will process. This is the number needed to estimate real indexing runtime once the inference box exists; no per-item timing benchmark has been run yet, so total runtime is still not calculated.
• A combined/sorted version of Andrew's attach_filetypes.sh (merges the two directories into one report instead of two disconnected tables) was written and delivered; Andrown put it on Live as a replacement (harmless, read-only script).

Immediate next step when resumed

1. Andrew finishes the pre-install VM-folder backup of Clone.
2. Run make install on Clone (the actual point-of-no-return: overwrites system glibc 2.12 with 2.17).
3. Immediately after, in the SAME still-open terminal session (don't close it): test ls, bash --version, cp --version before anything else.
4. If those survive, test rpm/yum, MySQL, Apache, SMF page load.
5. Then the actual point of the whole exercise: python3 -c "import torch", import open_clip, and a real CLIP embedding test against one of Andrew's actual uploaded test images.
6. If anything breaks badly: restore from the fresh pre-install backup.

Still open / parked, not urgent

• Clone's Webmin MySQL module was reported as "undoing fixes" to some my.cnf-related setting — parked mid-session, not resolved. Worth revisiting: check /etc/webmin/mysql/config vs my.cnf for drift, and whether Webmin's apply-on-load behavior is overwriting manual edits.
• attachments/attachments2 folder consolidation (SMF's built-in "Transfer attachments" maintenance function + id_folder DB update) was discussed in detail but explicitly dropped as "too much mucking around" — not planned unless revisited.
• MediaIndexer.py's two stubs (resolve_attachment_dir(), attachment_id derivation from filename) are still unwired to the real attachment DB/ dir layout — this becomes relevant again once there's a real inference box to run indexing on.