Updating 1 package, INFO says "P2P: 1 packages available from 1 peers", but it fails because "Not available from peers (--only-peers mode)"

[9marja99-droid]

Sharing media worked great with urpm-ng-0.1.21-1.mga10.noarch, but has been unreliable since 0.1.23
(I haven't used 0.1.22). One time I fixed it by reverting to 0.1.21 on the server.

There is no pattern, it doesn't matter whether a package that cannot be retrieved from the serving peer is already installed on the server, or also needed by the server, or neither.

Is the problem caused by my doing nothing with the instructions below?

i2026:01:02:15:16 <maat|alt> you ca already do this :
2026:01:02:15:16 <maat|alt> urpm media set --replication seed --quota 6GB Core\ Release
2026:01:02:15:16 <maat|alt> or
2026:01:02:15:17 <maat|alt> urpm media set --retention 90 Core\ Release
2026:01:02:15:17 <maat|alt> 1st case to defind a seeding media
2026:01:02:15:18 <maat|alt> 2nd to change the time you keep packages in your local media dir
2026:01:02:15:18 <maat|alt> and...
2026:01:02:15:18 <maat|alt> urpm media set --replication full --quota 200GB Core\ Release
2026:01:02:15:18 <maat|alt> this to set up a full replica (if you have plenty of space)

I assumed that that was no longer needed, so I even moved /var/lib/urpm back to the root partition, instead of having it on a large disk that was mounted on /var/lib/urpm

But I'll put it back on a large partition, if needed.

/ is 70% full:
/dev/nvme0n1p5 48G 32G 14G 70% /
6,1G is used by /var/lib/urpm/

[9marja99-droid]

This is odd, only one package to update and INFO says it's available:

urpm.core.download - INFO - P2P: 1 packages available from 1 peers

But the download fails because it is not available from peers:

Transaction summary:

Upgrade (1):
vaapi-driver-intel-media-26.1.3-1.mga10.x86_64

Download size: 42.0 MB

Proceed with upgrade? [y/N] y
urpm.core.peer_client - INFO - Got 2 peers from local urpmd
urpm.core.download - DEBUG - P2P: peer discovery took 0.01s, found 2 peers
urpm.core.download - DEBUG - P2P: availability query took 0.02s
urpm.core.download - INFO - P2P: 1 packages available from 1 peers
urpm.core.download - DEBUG - only_peers mode: skipping upstream for vaapi-driver-intel-media-26.1.3-1.mga10.x86_64.rpm

Downloading 1 package...
[1/1] 0%

1 download failed:
vaapi-driver-intel-media: Not available from peers (--only-peers mode)
(13:49:27) [root@T470mga10 /home/marja]#

[9marja99-droid]

Not_available_from_peers.txt

Attaching a more complete output.

[9marja99-droid]

I've reinstalled Mageia on the client (so also reinstalled urpm-ng) almost three days ago, and haven't had any problems fetching packages using the --only-peers mode since then.
Maybe something had become corrupted on the client?
Anyway, closing. I'll reopen if the issue pops up again.

[9marja99-droid]

It happened again :-(

Reopening

This time it was with hwdata:

---

Upgrade (2):
hwdata-0.405-1.mga10.noarch
marknote-1.5.0-1.mga10.x86_64

Install (1) - new dependencies:
lib64kirigamiapp6-1.11.0-1.mga10.x86_64

Download size: 12.1 MB

Proceed with upgrade? [y/N] y

Downloading 3 packages...

1 download failed:
hwdata: Not available from peers (--only-peers mode)

---

It fails both before and after installing those three packages on the server peer.

[pvi-github]

Thanks for the detailed report and logs — they pointed straight at the bug.

Root cause

The daemon keeps an in-memory index of RPMs it can serve (_rpm_index). It
is a long-lived cache that is only invalidated in a handful of scheduler
code paths (metadata refresh, media add/remove…). Any file removed
outside those paths — retention cleanup, signature purge, manual rm,
cache eviction — stays in the index forever.

The resulting race is exactly what you observed:

1. Peer A asks peer B /api/have for a list of filenames.
2. Peer B answers "yes, I have them" because they are still in
   _rpm_index, even though the files are no longer on disk.
3. Peer A tries to fetch them via /media/<path> and gets a 404
   (Package not found).
4. In --only-peers mode, the downloader then prints the very misleading
   "Not available from peers (--only-peers mode)", hiding the real
   problem.

Fix (commit 0c13a0d on branch 0.7.x)

Two small, surgical changes:

Fix 1 — Self-heal stale entries at read time

check_have_packages() in urpm/daemon/daemon.py now stats each file
before reporting it as available. If the file is gone, the entry is
dropped from _rpm_index on the spot and reported as missing to the
caller. This closes the window between "file removed" and "next scheduler
invalidation" without any locking or background sweep.

# Self-heal stale index: verify the file still exists on disk.
full_path = medias_dir / path
if not full_path.is_file():
    logger.debug(
        "Dropping stale index entry: %s (path %s no longer on disk)",
        filename, path,
    )
    self._rpm_index.pop(filename, None)
    missing.append(filename)
    continue

Fix 3 — Surface the real peer error in --only-peers mode

_download_item() in urpm/core/download.py now tracks the last peer
error across all peer attempts and includes it in the final message when
--only-peers blocks the upstream fallback. Instead of the opaque
"Not available from peers (--only-peers mode)", you now get something
like:

peer download failed (192.168.1.42: HTTP 404), upstream disabled (--only-peers)

which makes the underlying cause obvious and prevents future guess-work.

Test

If you can rebuild from branch 0.7.x (commit 0c13a0d) and rerun the
scenario that reproduced the bug, I would love to know whether:

• the second pass (with --only-peers) now reports a useful error
  message instead of the opaque one;
• the first pass eventually succeeds once stale entries are self-healed
  and the real file is fetched from upstream (without --only-peers).

Thanks again for the clear report!

Note

What this does not fix yet

The stat check is read-time self-healing — it is not a substitute for
proper invalidation in the cleanup paths. A follow-up will audit every
place that deletes or moves a file under medias_dir and make sure it
also invalidates _rpm_index so peers never even get offered a stale
entry in the first place. For now, Fix 1 is enough to unblock the
symptom you reported.

[pvi-github]

Now you can try with version 0.7.4...

[9marja99-droid]

I didn't quite understand what you what you wrote and asked.

Anyway, trying again with a different package. urpm-ng-0.7.4-2.mga10 is installed on both systems.

=> First installing it on the "server peer":
(18:22:22) [root@TC /home/marja]# urpm i mageia-sysrq-config

Transactiesamenvatting:

Gevraagd (1) - 7.0 KB
mageia-sysrq-config-1.0-1.mga10

Totaal: 1 pakket (7.0 KB)

Doorgaan met installatie? [j/N] j

Bezig met downloaden van pakketten...
1 gedownload, 0 uit cache in 0s

Installeren van 1 pakket...

Installing 1 package...
[1/1] klaar
1 pakket geïnstalleerd
(18:23:20) [root@TC /home/marja]#

=> Then trying on the "client peer"

(18:33:48) [root@T470 /home/marja]# LANGUAGE=en urpm i mageia-sysrq-config --only-peers --show-all 2>&1 | tee mageia-sysrq-config.txt

Transaction summary:

Requested (1) - 7.0 KB
mageia-sysrq-config-1.0-1.mga10

Total: 1 package (7.0 KB)

Proceed with installation? [y/N] y

Downloading packages...

1 download failed:
mageia-sysrq-config: no peer has this package (--only-peers mode)
(18:38:53) [root@T470 /home/marja]#

I had set the server peer to share the local mirror and the core_release and nonfree_release media in the past (several times even, but not in the last few weeks), how can I check that didn't get undone?

[9marja99-droid]

If sharing worked, then it should have installed it, like now happens without the --only-peers option (installing from the same local mirror shared with NFS):

LANGUAGE=en urpm i mageia-sysrq-config --show-all 2>&1 | tee mageia-sysrq-config2.txt

Transaction summary:

Requested (1) - 7.0 KB
mageia-sysrq-config-1.0-1.mga10

Total: 1 package (7.0 KB)

Proceed with installation? [y/N] y

Downloading packages...
1 downloaded, 0 from cache in 0s

Installing 1 package...

Installing 1 package...
[1/1] done
1 package installed

1 package had scriptlet output (use --verbose to see)
(18:43:51) [root@T470 /home/marja]#

[9marja99-droid]

I had set the server peer to share the local mirror and the core_release and nonfree_release media in the past (several times even, but not in the last few weeks), how can I check that didn't get undone?

[root@TC /home/marja]# LANGUAGE=en urpm mirror status

Mirror Status

Mirror mode: enabled
Rate limiting: on

Cache Statistics

Total files: 624
Total size: 3.20 GB
Referenced: 624 files (3.20 GB)
Unreferenced: 0 files (0 B)

Media with mirror settings

(all media using defaults)

I couldn't find whether the needed media were still set to shared, so I did again:

(15:20:29) [root@TC /home/marja]# urpm media set "Core Release" --shared yes
Bijgewerkt 'Core Release':

• shared: yes
  (15:21:06) [root@TC /home/marja]# urpm media set "Nonfree Release" --shared yes
  Bijgewerkt 'Nonfree Release':
• shared: yes
  (15:21:18) [root@TC /home/marja]#

And then I first tried to update with --only-peers, which failed, and then without peers, from the same local mirror, which succeeded.

update_with_and_without_only-peers.txt

[pvi-github]

This intrigues me :

urpm.core.download - DEBUG - Downloads completed in 6.18s
urpm.core.download - DEBUG - Registered cache file: x11-server-xorg-21.1.22-1.mga10.x86_64.rpm (1178502 bytes)
urpm.core.download - DEBUG - Registered cache file: x11-server-xwayland-24.1.10-1.mga10.x86_64.rpm (1089228 bytes)
urpm.core.download - DEBUG - Registered cache file: x11-server-common-21.1.22-1.mga10.x86_64.rpm (495593 bytes)
``

You should not have these DEBUG messages displayed... what version of urpm are you running ?

urpm -V

While we are at debug thing what peers do you see ?

urpm peer

And how are configured your medias ?

urpm media