Requests for Roman: the Esperanto archive on mordast

A12 Two permission fixes: the automount script on mordast (from Saturday) and stash's open exports and read-write mounts, plus a fresh snapshot (updated)

/etc/auto.home-select is still -rwxrwxrwx root (checked today). It was edited on 11 Oct at 15:52, the same minute as /etc/fstab, but the mode stayed. autofs runs it as root on every /home lookup, so any account on mordast can take root. Since anyone could have changed it, it's worth one look at its 27 lines after the chmod.

sudo chmod 755 /etc/auto.home-select
sudo cat /etc/auto.home-select    # one look: anyone could have edited it

Mounts on mordast. Only /archive/esperanto and /archive/eng are read-only. /archive/atlassian, /archive/gdrive and /index are mounted read-write (/etc/fstab lines 27–29), and so is /home/github (the systemd unit home-github.mount). /archive/gdrive (the only copy of the Drive export), /index and /home/github (mode 777) pass a write-access check for an ordinary account (checked with [ -w ]; nothing written). Please remount them read-only, or tell me what needs to write there.

On stash (verified from mordast with showmount -e stash, stat and ls .zfs/snapshot): archive/esperanto, archive/esperanto/atlassian, archive/esperanto/gdrive, agentic/index and home/github are exported to everyone (so are the 53 /mnt/tank/home/* user homes), and the top directories archive/esperanto/wasabi, archive/esperanto/lab and home/github are mode 777. Since the Wasabi purge this pool is the only copy of the 2025 uploads, and home/github the only copy of the design repos that were never pushed to GitHub; the only other protection is two ZFS snapshots of archive/esperanto on the same pool (esperanto-archive-2026-04-13 and -05-02). Worth considering: read-only exports limited to the hosts that need them (mordast's fstab mounts atlassian and gdrive read-write, so check what writes there first), 755 on those three directories, a fresh snapshot of both datasets, and eventually a second copy off stash.

# on stash, as root (all read-only except the snapshots and the chmod)
zfs list -t snapshot -o name,creation -r tank
zfs snapshot -r tank/archive/esperanto@handover-2026-10-12
zfs snapshot -r tank/home/github@handover-2026-10-12
chmod 755 /mnt/tank/archive/esperanto/wasabi /mnt/tank/archive/esperanto/lab \
          /mnt/tank/home/github

A02 If any of the old boxes survive: copy these subtrees to stash first, without letting the box delete anything (new)

Only if the answer to A01 is yes, it still exists. stash has about 26 TiB (~28.5 TB) free in its pool (df today), shared with the only copy of the archive and the team's 53 homes, so it isn't enough for everything. Here is the order I'd take things in, thermal-critical first; please stop at about 85% full (zpool list tank), since a full pool would also stall everyone's homes:

1. sc-truenas03 /mnt/tank/backup/A0 (= A0_final): soc_top (9.2 TB), shire_top (5.1 TB), minion_top, pshire_et_block, memshire_west_side (about 18 TB in all), and every pdqa / em_ir directory.
2. sc-truenas01: archive/eng/alilic (archive_ptpx), archive/project/pd/anilm/Work_A0, archive/project/pd/adolfod, archive/exstaff/{klingner,rupeshr,rohiniv,psanchez,ivan,devinp}.
3. sc-truenas02 Veeam file-level restores: the newest PureENG to Truens02 backup point for /eng/{tberg,tbeale,rknath,rajl,shankarj,rsteeves,yhxu,zorans,jenkins} (/eng/mray only if sc-truenas03 is gone: it probably still holds the 22 TB a0_backup.tgz, inferred, which alone would take most of stash's free space); Pure Scratch to Truenas02 for /scratch/noc/A0/Data/{PowerRuns2,PowerRuns,BIGRUNS}; the newest PD point for /pd/mpelham/work/CHIP/INT_A0/TAPEOUT_121920, /pd/anilm/Work_Redhawk_EMIR_* and /pd/release/gpd. (Veeam console: Home → Backups → Disk → the job → Restore guest files / file share, to an NFS or SMB target on stash.) A restore needs Veeam B&R 12 and, if the jobs were encrypted, their password (Michael Ray set them up). Veeam configuration backups from Feb 2023 are in the ET IT Shared Company Folder 0AD0UWR09ToBsUk9PVA (IT-1075; see A04).
4. IO FreeNAS: /mnt/tank/home/data/rknath/ARCHI-4/Data, then /data/{power*,tberg,yhxu,shankarj}.

Before an old TrueNAS goes back on a network, keep it unplugged or, on first boot, disable every task under Data Protection (Periodic Snapshot, Replication, Cloud Sync, Rsync). After a year offline their retention rules would delete expired snapshots on the first run, and those snapshots may hold the archive/pd data deleted in Jul–Nov 2024 (inferred; standard TrueNAS behaviour, not tested here). On sc-veeam01, disable all jobs before it can reach the repository. Even for a box that boots, the disks-only path below is the safest. Import the pool read-only on any ZFS host other than stash (stash's own pool is also called tank), by its numeric id, under an altroot, and send from a snapshot that already exists:

# a box that boots (network unplugged, tasks disabled): read-only on the source
ssh stash zfs create tank/archive/a0_final
cd /mnt/tank/backup/A0
rsync -aH --numeric-ids soc_top shire_top minion_top stash:/mnt/tank/archive/a0_final/

# disks only, on a spare ZFS host: nothing is written to them
zpool import                       # lists the pools and their numeric ids
zpool import -o readonly=on -N -R /mnt/rescue <numeric-id>   # add -f if it says the pool was last used by another system
zfs list -o name,used,refer -r tank          # please send us this output
zfs list -t snapshot -o name,creation -r tank
zfs send -R tank/archive/eng@<newest-existing-snapshot> \
  | ssh stash zfs recv -u -o readonly=on -x mountpoint tank/archive/eng-truenas01
# if send -R stops with "cannot hold ... read-only": send each dataset's snapshot without -R,
# or import without -N and rsync from /mnt/rescue/...

Why: these are the only places the full-chip layout, the shire-level power runs and the PD work areas are known to have existed after 2023.

Would close or narrow: M01 M04 M05 M06 M07 M08 M09 M10 M12 M13 M14 M15

A10 Lab hosts: what are esperanto-soc2…10 and esperanto-flash, and can what's left be imaged before reuse? (new)

Your tailnet lists esperanto-soc2 (offline) through esperanto-soc10 and esperanto-flash. I haven't touched them. The lab flash PC's history (/archive/esperanto/lab/flash/et/.bash_history, 12 Mar 2026) has ssh esperanto-soc2 and ssh roman@10.20.10.1, and a card image gianluca.esperanto-soc4.bin is dated 5 Aug 2025, so I guess they are re-used Esperanto card hosts on the old Mountain View lab subnet (inferred). esperanto-flash is probably the lab flash PC itself: its history runs tailscale status and rsyncs itself to ainekko@mordast (inferred). 10.20.10.x was Esperanto's Mountain View lab subnet (gateway 10.20.10.1 in the Machine Setup from Scratch page, mv-swpcie32 at 10.20.10.228 in IT-1175), and mordast (10.20.10.72) is on it now. Gianluca (stash home gianluca, inferred Gianluca Guida) flashed cards on esperanto-soc4 on 5 Aug 2025 and would know which machines these are. Which physical machines are they (old hostname, serial), and do they still hold their pre-2025 disks?

The root disks were copied on 28–30 Jul 2025 and cards were flashed on esperanto-soc4 a week later, so old root disks may be overwritten already; data disks may survive. Never imaged at all: mv-gb01…19 (the Aug–Oct 2024 power traces under mv-gb09:/mnt/esperanto/et/power/_s6_traces_2024-08-28 and later, and mv-gb19:/mnt/esperanto/et), the 8 TB data disks of mv-swpcie22 and mv-swpcie25, mv-demo01, mv-lab07/09 and the lab-desktop file server. If the mv-swpcie21/23 or mv-eap04 disks still exist, a re-image would fix the copies that dropped blocks (swpcie21 lacks a 190 GB tail).

# on stash, with the lab disk attached; mark it read-only first, the map file lets it resume
blockdev --setro /dev/sdX
cd /mnt/tank/archive/esperanto/lab
ddrescue -d -r3 /dev/sdX <host>.img <host>.map
# or just the data directories; -R keeps each full path (.../<host>-files/mnt/esperanto, .../home/et, .../root)
rsync -aHAXR --numeric-ids /mnt/esperanto /home/et /root stash:/mnt/tank/archive/esperanto/lab/<host>-files/

Why: the 2024 card power and temperature campaigns on mv-gb09/gb19 are the most recent measured data, and they exist nowhere else.

Would close or narrow: M19 M20

A11 Make the three unreadable mirror repos readable (updated)

Still open today: the loose objects of esperanto/gepardo-soc (820,132 of 820,169) and customers/denso (64 of 102) are mode 0600, owner shelley, and so are 360,726 objects of the bare esperanto/qqq, whose tape_out tag exists nowhere else. The copy through macOS also left 78,804 AppleDouble ._* files; 117 ._pack-*.idx make git print non-monotonic index. Low priority; faster on stash than over NFS.

sudo chmod -R a+rX /mnt/tank/home/github/esperanto/esperantotech/esperanto/gepardo-soc/.git/objects \
                   /mnt/tank/home/github/esperanto/esperantotech/customers/denso/.git/objects \
                   /mnt/tank/home/github/esperanto/esperantotech/esperanto/qqq/objects
find /mnt/tank/home/github/esperanto -name '._*' -path '*/.git/*' | wc -l    # review, then add -delete

Why: the Gepardo (ET-SoC-2) history and the qqq tape_out tag become browsable.

Would close or narrow: M39 M35

A03 AWS: list the Esperanto buckets, and restore the PD archive from Glacier (new)

In the AWS accounts 828856276785 and 554873560799 (owner of record Dave Ditzel): please list all buckets, and for s3://pure-pd-archive the object count, total size and storage classes. A Glacier lifecycle was set on 14 Mar 2025 after the Jan 2025 bill said this bucket was most of the S3 bill; mordast has only the 10.2 GB of STANDARD objects copied to Wasabi on 30 Jun 2025. Also check a0-archive-et-soc-1, a0-archive-us-west and it-1249-a0-archive (the 2023 A0 syncs; the last run logged Completed 38.7 TiB) and veeam-to-s3-backups-4-5-2* (Veeam chains of all 8 Pure file systems, ~4 Jun 2024; restoring these also needs Veeam B&R 12 and the job's encryption password, if one was set). If they exist, restore and copy soc_top, shire_top and minion_top first: soc_top is most likely only in the a0-archive-* buckets, since the pure-pd-archive upload seems to have stopped after memshire_east_side. Bulk Glacier restores take up to two days; moving ~30 TB out of AWS costs a few thousand dollars at list price (my estimate).

aws s3 ls
aws s3 ls s3://pure-pd-archive/A0/ --recursive --summarize | tail -2
aws s3api list-objects-v2 --bucket pure-pd-archive --query 'Contents[].StorageClass' \
    --output text | tr '\t' '\n' | sort | uniq -c
for b in a0-archive-et-soc-1 a0-archive-us-west it-1249-a0-archive; do
  aws s3 ls s3://$b/ --recursive --summarize | tail -2
done
# then: S3 Batch Operations > Restore (Bulk) on the prefix that holds A0, and after it completes
aws s3 sync s3://<bucket that holds it, e.g. a0-archive-et-soc-1>/<prefix>/soc_top <dest> --force-glacier-transfer

Why: the cheapest place the full-chip layout may still exist; no hardware needed.

Would close or narrow: M01 M02 M13 M42 M04 M05 M16

A04 Google Workspace: share or copy the shared drives that weren't copied (updated)

Read-only to yaroslav@nekko.ai, or rclone them to stash by id. In order:

• 0ADz9vEuaYsTGUk9PVA: the ex-staff home tarballs (24 listed in EIP-125, at least 16.3 TiB, since bmaric.tgz was still being written at 9.8 TiB; incl. bmaric, psanchez, nshah, rohiniv, rupeshr; a 15 Apr 2024 screenshot shows klingner, bmaric, kiran, jsola and jsanchez uploading), and ET-EX-ENG-Tarballed-Home-Directories. From these, rupeshr, rohiniv, klingner and psanchez first.
• et_exstaff (departed staff laptop copies, PST mail, Gdocs).
• 0AIMo64EKj195Uk9PVA (ET VLSI Shared Drive), 0ADP4zyteTbOdUk9PVA (P/TE, inferred), 0AD0UWR09ToBsUk9PVA (ET IT Shared Company Folder; holds the Veeam/TrueNAS configuration backups), 0ABPxZKAuxOIxUk9PVA (All Hands Documents and Recordings), 0AFeuUUGKHxLYUk9PVA (OPM), 0AHK5s3IRLKXiUk9PVA, and the Original Esperanto Shared Drive (a dangling shortcut at the root of the copy).

Correction to Saturday's item 5: the 403s were 252 objects (27.4 GB), mostly All Hands decks and Meet recordings, not vendor PDFs.

# on stash; lists every shared drive with its id
rclone backend drives gdrive:
rclone copy gdrive: /mnt/tank/archive/esperanto/gdrive-extra/exstaff \
    --drive-team-drive 0ADz9vEuaYsTGUk9PVA --drive-acknowledge-abuse -P \
    --include '{klingner,rupeshr,rohiniv,psanchez}*.tgz'

Why: the ex-staff PD homes hold the 2020 soc_top RedHawk-SC EM/IR runs (rupeshr), the SOC_Top bumps (rohiniv) and the ET-SoC-1.5 mPower runs (klingner); none of it is anywhere on mordast.

Would close or narrow: M08 M24 M27 M30 M31 M13

A05 Google Workspace: export the linked power and test Sheets and decks by id, and the leavers' My Drives (updated)

I have a list of 227 Drive ids in priority order (in my home on mordast: /home.local/yaroslav/claude/vault-2026-10-11/synthesis/missing/drive_ids_wanted.tsv, readable by root only; I'll send it): the 123 weekly Power_Topics decks (Aug 2020 – Feb 2023, Francisco Torres), the power Sheets (ET-SOC-2 PTPX experiments, Power Projection Spreadsheet, ptpx_data_table_JB, power measurement and estimate), the P/TE characterization and package Sheets (board_vmin_corr_round2, Vmin vs process and temperature, ETSOC1 Die Related Information, Package X/Y), the board-tracking and E-Fuse Sheets, and the Apr 2024 aging-report folder 1dyaLxlkDN6jChTGuaZNYcPTTjeIXsV_m.

With a Workspace super-admin: do the accounts of Francisco Torres, Matt Ward and Shankar Jayaratnam (left 30 Jun 2025, email is only archived) and of Tom Berg, Eric Soriano, Aleksandar Lilic and Devin Patel still exist? If so, please export their Drives (Takeout or Vault, Sheets as .xlsx). Correction to Saturday's item 7: 8 of the 11 power shortcuts named there are already on mordast.

rclone backend copyid gdrive: <file-id> /mnt/tank/archive/esperanto/gdrive-extra/byid/ \
    --drive-export-formats xlsx,pptx,docx
# Google Vault: Export > Drive > the accounts above > include shared-drive items

Why: the weekly power decks and Sheets record per-block and measured power through tape-out and bring-up; the aging reports are the only file-level map of the homes and of /project/pd.

Would close or narrow: M25 M26 M27 M28 M29 M31

A06 Rotate or revoke credentials that are in the archive (new)

Paths only; I haven't used or copied any of them. They are readable by every account on mordast (checked: ekolb/.aws/credentials and the wildcard key are mode 0644; the lab disk images are 0644 too; and even mode-600 files open for a non-owner account, see the flash PC below). Restricting read access on the archive would also block the archive browser, so rotating is the real fix.

• AWS keys: /archive/esperanto/wasabi/esperanto-eng/ekolb/.aws/credentials and ekolb/.s3cfg (6 Sep 2023); home_eng_jenkins/.aws/credentials (2019) and jenkins/.aws.
• Wildcard TLS key for esperanto.ai: ekolb/wildcard-esperanto.ai.key (May 2021).
• Jenkins SSH keys, incl. AWS .pem files: home_eng_jenkins/.ssh (51 files).
• A Datadog API key in ekolb/.history (2021); the sc-truenas03 web login in a comment of IT-1467; a vendor FTP login in IT-1701.
• GitHub tokens in 75 lab .git/config files, e.g. lab:sdb1:/esperanto/avuong/et_sdk_tools_1.6.0/et_repos/repos/gp-sdk/.git/config.
• The lab flash PC's SSH key, /archive/esperanto/lab/flash/et/.ssh/id_rsa (Oct 2023). Mode 600, owner nobody, but every account on mordast can read it anyway: the stash export appears to map every client user to the files' owner (inferred; checked 12 Oct with test -r from a non-owner account, an access check that doesn't open the file). Its authorized_keys changed on 28 Aug 2025, and its history ssh'es to esperanto-soc2 (host key in known_hosts) and to roman@10.20.10.1 (the lab gateway in the old setup pages; no host key recorded), so the key may still be trusted on current hosts (inferred).
• Lab server keys: 123 files named id_rsa / id_ed25519 / id_ecdsa in the lab images (some are test keys), e.g. lab:sda1:/backup.mv-swpcie21.img:/root/.ssh/id_rsa, lab:sdf:/backup.mv-swpcie23.img:/root/.ssh/id_rsa and the shared et account's key on several hosts. If any esperanto-socN is a re-used lab host that wasn't reinstalled, its authorized_keys may still trust these.

# for each key id in those files: shows the IAM user and when it was last used
aws iam get-access-key-last-used --access-key-id <id>
aws iam update-access-key --user-name <user> --access-key-id <id> --status Inactive
# on the esperanto-soc hosts and the flash PC
cat ~et/.ssh/authorized_keys /root/.ssh/authorized_keys    # drop keys that aren't current

Why: the AWS account was alive in 2025, and the flash-PC key may still be trusted on current hosts. A chmod on stash would not help either: the export maps every client to the owner (inferred).

A13 Tailscale SSH check period for mordast (from Saturday)

Unchanged from Saturday, and I can't verify it from mordast. In the nekko.ai policy, the SSH rule for yaroslav@nekko.ai to tag:lab-maintenance (mordast) needs either "action": "accept" or the longest check period, so agents can reach mordast non-interactively. Same for aifoundry1–3 if you're in there anyway.

{ "action": "check", "src": ["yaroslav@nekko.ai"], "dst": ["tag:lab-maintenance"],
  "users": ["autogroup:nonroot"], "checkPeriod": "168h" }

A16 Alchip (through you): the full-chip OASIS and ICC2 databases of the A0 tape-out (updated)

Alchip received at least eight full-chip OASIS databases and four ICC2 tarballs for TSMC product TMNK96 (customer 0G33) between Jul and Dec 2020, e.g. soc_top_A0_FULL_071720_noIPtext.oasis, soc_top_full_merge_102720-2030layerV2.oasis, soc_top.nlib_1124_reduced.tgz and soc_top_nlib_1111.tgz, and probably the final soc_top_full_merge_121920_remove_uncon_VDD_0P65.oasis (inferred: masks were ordered on 23 Dec 2020). Mike Pelham was the contact. Would they confirm they keep the tape-out archive and release to the asset owner a layer-reduced view (die outline, block and macro placement) cleared by TSMC? This is the 6 Oct layout request, now with names; I can send the exact list of what the solver needs.

Why: an independent copy of the final layout that doesn't depend on any Esperanto hardware surviving.

Would close or narrow: M03 M01 M04

A17 Amkor, the heatsink vendor and Meta (through you): package and cooling models (new)

Amkor: the ET-SoC-1 45×45 mm package FEA model (materials, geometry), any JEDEC theta-JC / psi-JT characterisation or a 2-resistor / Delphi model, the substrate SiP databases (TSM_4720, 0859819SP) and the stack-up. Radian (or Boyd): heatsink drawing T31-235 / INF-760355-MIS. Meta: the four SoC thermal models uploaded to the C1 SharePoint on 18 Apr 2019.

Why: no package thermal model or theta values exist anywhere in the archive.

Would close or narrow: M22 M21

A18 Ex-Esperanto engineers: personal copies of the missing power data (new)

Some are reachable inside the company (new Atlassian accounts since Aug 2025, or stash homes named after them; the matches are inferred):

• Aleksandar Lilic (aleksandar; could also be Aleksandar Ugarak): alilic/dev/archive_ptpx, the ET-SOC-2 PTPX experiments Sheet, the mv-gb09 traces, Ivan Ratkovic's Drive.
• Bruce Klein (bruce): the Perforce depot, SiP/Allegro projects, the 2024 CelsiusDC runs on his Windows desktop.
• Howard Davidson (howard): cooling and packaging contractor 2022–23.
• Pedro Sanchez (pedro): his psanchez home, the 4.7 TB tarball in EIP-125 (M08).
• Ying Hao Xu (yinghao): yhxu, one of the homes after kpn (M09).
• Jayesh Iyer (jayesh): where the 2021–24 architecture/PD areas went.
• Barry Pangrle (new account Aug 2025): the 2019 power model and the Ansys/RedHawk evaluation.

Is it all right if I ask these people directly? For those below, would you forward a short note? I'll draft it.

Through you, if you're in touch: Rajib Nath (PowerRuns2 PT-PX reports, ARCHI-4); Tom Berg and Terry Beale (gate-level shire/NoC power FSDBs, virus70 full-chip PT-PX); Francisco Torres (Power_Topics decks, tape-out PT-PX in /archive/eng/ftorres/power); Stephen Lee (Feb 2022 Fmax decks, V-f shmoo); Devin Patel (P/TE Sheets, Silicon Bring-Up Presentation (Devin).pptx, which Atlassian itself lost); Chun Ning (cning soc* run areas).

Why: small, high-value files (reports, Sheets, decks) often survive on laptops even when the NAS copies are gone.

Would close or narrow: M07 M09 M14 M21 M23 M26 M28 M32 M08

A19 Teradyne (through you): a dump of the ATE test-program repository (new)

tron.teradyne.com/Esperanto/ET_SOC1 hosted the ATE test programs; mordast has only an r23 working copy of Oct 2020 (190 files, 215 entries). Could they send a dump, or at least the final test program with its PVT/POWER blocks?

svnadmin dump <repo> | gzip > ET_SOC1.svn.gz

Why: temperature-dependent test limits and sensor trim.

Would close or narrow: M38

A01 What happened to the colo hardware after June 2025? (new)

For each box: still powered, in storage, wiped, returned or sold, and where? The QTS colo machine list was last edited on 24 Jun 2025 and still listed the TrueNAS boxes, sc-pure01, the IO NAS and the NetApp. Ray Borg (Head of IT; last seen in Jira 1 Jul 2025), Michael Ray, Erich Kolb and Patrick Lugliani ran them; Dave Ditzel is owner of record of the cloud accounts (AWS: A03).

If you don't know, would you forward this table to Ray Borg or Michael Ray? Vendor records could also tell: Pure1 shows whether sc-pure01 still phones home, iXsystems support can look up serials A1-100191 and A1-72549, and QTS should have the move-out and shipping records for the cage.

If a TrueNAS box powers up (network unplugged, scheduled tasks disabled: see A02), the output of zfs list -o name,used,refer -r tank and zfs list -t snapshot -o name,used,creation -r tank would already tell us most of what's on it.

Why: almost every large gap (full-chip layout, PD work areas, PT-PX runs, ex-staff homes, the homes after kpn) has its best surviving copy on one of these.

Would close or narrow: M01 M04 M05 M06 M07 M08 M09 M10 M12 M13 M14 M15 M16 M18 M21 M37 M41 M17

A08 Who ran the June 2025 Wasabi upload, why did /eng stop at “kpn”, and was anything else copied at shutdown? (new)

The rclone walk of /eng (20–23 Jun 2025, Wasabi account dave.ditzel) reached kpn at 20:52 UTC on 23 Jun and stopped there (the parallel walks ended by ~22:30), with 58 of 92 top directories probably still transferring (inferred from upload times). Only a 3-hour excerpt of the parallel fe log survives (eng/ekolb/rclone.log), so I guess Erich Kolb ran it (inferred). Is there a full log or exit status? Was it resumed anywhere? Did /eng or /pd also go to a disk, the leased NetApp or AWS FSx? For the provenance notes only: who imaged the lab disks (28–30 Jul and 15–18 Dec 2025), and who ran the 30 Apr 2026 Wasabi purge (the attestation leaves the executor blank)? And does a Slack export of esperanto-tech exist? It would answer most of this. Last, the bucket the Veeam job PureENG to Wasabi wrote in Jul 2024 (10.5 TB, run by Erich Kolb): was it in the dave.ditzel account, or in another Wasabi account that may still exist?

Would close or narrow: M09 M10 M11 M40 M41 M44 M13

A09 What was stash /mnt/tank/archive/eng meant to receive? (updated)

It was created on 15 Dec 2025 at 17:09 PST, 21 minutes before the first lab disk image started writing to stash (17:31), and is empty (0 entries; the 26 TiB that df shows is just the pool's free space, the same on every stash dataset). It is exported to 10.20.10.0 (the old Mountain View lab subnet mordast is on) and 10.10.1.0, the colo subnet of sc-truenas03, the IO FreeNAS and the Pure. Its name matches sc-truenas01's tank/archive/eng, but sc-truenas01 was at 10.10.7.10. Which box was it for, and was that box on the lab network in December? (This replaces Saturday's question about the bigger NFS archive.)

ls -la /mnt/tank/archive/eng; zfs get creation,used,refquota tank/archive/eng

Would close or narrow: M06 M07 M10

A07 Is there any Atlassian backup from before the site was deactivated? (updated)

A Jira XML backup or a Confluence site export would close: the histories cut at 40 entries (650 issues, 24,834 of 433,529 entries; also needed to explain 357 key gaps), the private MFGTST MFG Test project (exported with 0 issues; at least 86 bring-up/ATE triage issues), 45 attachments on 8 archived pages (incl. PROJECTS page 2616426497 with volt-freq-shmoo.xlsx and the three Feb 2022 Fmax meeting DD status decks), page history, remote links, and the TEAM space (empty, or no permission?). If the site can be reactivated even briefly, two calls recover most of it:

GET /wiki/rest/api/content/2616426497/child/attachment?status=archived
jira_changelog.py with a read-only token (per-issue changelog endpoint)

The script: jira_changelog.py (published next to this page).

Why: the Fmax/Power material is measured V-f and power data; MFGTST holds the silicon bring-up triage.

Would close or narrow: M32 M33 M34

A14 Perforce: was the sc-perforce depot saved anywhere? (updated)

mordast has the server root of Apr 2022 (journal and db) but file content for only 112 of 23,677 depot paths, and the server kept running to at least May 2023 (IT-1222, IT-1285). Bruce Klein was the main client. If any of it survives, these paths first: //depot/Systems/ET-SOC/Substrate/..., //depot/Systems/PCIe-Dev-Card/Rev3/{PCB,Mechanical}/..., //depot/Systems/ET-SOC1 Test PCIe Card/..., //depot/Systems/BUB-1.0/... (not the PMIC SAMD20 demo-firmware tree).

# on the server: a checkpoint without rotating the journal, plus the Systems archives
# (the /opt/perforce path is inferred; the archived copy is under eng/git/perforce/servers/master/{root,journals,archives})
p4d -r /opt/perforce/servers/master/root -jd /tmp/p4-checkpoint
tar czf p4-systems.tgz /opt/perforce/servers/master/archives/depot/Systems

Why: package stack-up, substrate and heatsink geometry for the package thermal model.

Would close or narrow: M21 M23

A15 Is gitlab.com/esperantotech still alive, and what is the tailnet device “gitlab”? (updated)

The 513-repo mirror is complete for git (newest commit 3 Jun 2025), but merge requests, issues, CI pipelines and job logs, wikis, registries and personal namespaces of the gitlab.com era (Jul 2023 – 2025) were never exported. If the group still exists, per-project exports would keep the MRs, issues, wikis and pipeline history; job logs, registries and personal namespaces need separate API pulls or your account. Are the github.com/et-* orgs (490 repos pushed 17–19 Sep 2025) still there? What is the tailnet device gitlab (owner roman@): an old VM, a restore or a mirror? And do the retired sc-gitlabdev / sc-gitlab / sc-gitlab03 VM disks or the Barcelona barcino backup PC still exist?

glab api --paginate 'groups/esperantotech/projects?include_subgroups=true&per_page=100' \
  | jq -r '.[].path_with_namespace' | wc -l
glab api -X POST projects/<id>/export          # one per project: MRs, issues, wiki, pipeline history (no job logs)
glab api projects/<id>/export/download > <name>.tar.gz
glab api projects/<id>/jobs/<job-id>/trace > <job-id>.log   # job logs are not in the export

Why: CI logs and MRs record which power/PT-PX jobs ran and where their outputs went.

Would close or narrow: M35 M37

A20 Do any Synopsys or Siemens licences still work, and may we run them? (from Saturday)

Unchanged from Saturday. Needed to open NDM, OASIS or FSDB files if any of the above is recovered.