# Distfiles über NFS

## musv

Hallo, 

ich hab 2 Rechner. Einer davon ist ein Uraltnotebook mit kleiner Festplatte. Demzufolge hab ich die Distfiles per NFS zur Verfügung gestellt. Bis vor ca. 1 Woche ging das auch noch alles wunderprächtig. Beim heutigen Compilierversuch meckerte emerge jedoch und brach ab. 

großer Rechner: Distfiles in /var/portage/distfiles

Notebook: greift auf die Distfiles vom großen Rechner per NFS zu.

```

emerge -1u lsof cabextract ntfs3g mac nss libao perl-cleaner

Calculating dependencies... done!

>>> Verifying ebuild manifests

>>> Starting parallel fetch

>>> Emerging (1 of 8) dev-libs/nspr-4.8.6

Cannot chown a lockfile: '/var/portage/distfiles/.nspr-4.8.6.tar.gz.portage_lockfile'

 * nspr-4.8.6.tar.gz RMD160 SHA1 SHA256 size ;-) ...                     [ ok ]

Traceback (most recent call last):

  File "/usr/lib/portage/bin/ebuild", line 268, in <module>

    debug=debug, tree=mytree)

  File "/usr/lib/portage/pym/portage/proxy/objectproxy.py", line 32, in __call__

    return result(*args, **kwargs)

  File "/usr/lib/portage/pym/portage/package/ebuild/doebuild.py", line 838, in doebuild

    fetchonly=fetchonly):

  File "/usr/lib/portage/pym/portage/proxy/objectproxy.py", line 32, in __call__

    return result(*args, **kwargs)

  File "/usr/lib/portage/pym/portage/package/ebuild/fetch.py", line 612, in fetch

    stat_cached=mystat)

  File "/usr/lib/portage/pym/portage/util/__init__.py", line 910, in apply_secpass_permissions

    stat_cached=stat_cached, follow_links=follow_links)

  File "/usr/lib/portage/pym/portage/util/__init__.py", line 745, in apply_permissions

    os.chown(filename, uid, gid)

  File "/usr/lib/portage/pym/portage/__init__.py", line 228, in __call__

    rval = self._func(*wrapped_args, **wrapped_kwargs)

OSError: [Errno 22] Invalid argument: '/var/portage/distfiles/nspr-4.8.6.tar.gz'

 * Fetch failed for 'dev-libs/nspr-4.8.6', Log file:

 *  '/var/tmp/portage/dev-libs/nspr-4.8.6/temp/build.log'

>>> Failed to emerge dev-libs/nspr-4.8.6, Log file:

>>>  '/var/tmp/portage/dev-libs/nspr-4.8.6/temp/build.log'

 * Messages for package dev-libs/nspr-4.8.6:

 * Fetch failed for 'dev-libs/nspr-4.8.6', Log file:

 *  '/var/tmp/portage/dev-libs/nspr-4.8.6/temp/build.log'

```

Wurde da irgendwas an emerge verschlimmbessert, sodass ein Lock zu einem entsprechenden Distfile erzeugt wird und da der Eigentümer nicht geändert werden kann?

Ein Test brachte mir folgendes:

```

 cd /var/portage/distfiles/

root distfiles> touch blubb

root distfiles> chown root:root blubb 

chown: Ändern des Eigentümers von „blubb“: Das Argument ist ungültig

```

Hätte auch bezweifelt, dass man per NFS Dateien von root einfach so ändern kann.

Wie krieg ich das wieder zum Laufen?

----------

## disi

Ich glaube vor kurzem wurde "userfetch" als FEATURE automatisch ins profile genommen.

Versuche das doch mal in der make.conf abzuschalten.   :Idea: 

Einen aehnlichen Fehler "ungueltig" hatte ich sonst nur auf reiser4 ohne nfs gesehen.

----------

## Jimini

Wie sieht denn deine /etc/exports aus? Gibst du /usr/portage/distfiles evtl. mit der Option "root_squash" frei? Dadurch kann der Inhalt dann nicht auf anderen Rechnern verändert werden.

Meine Freigabe sieht wie folgt aus:

```
/usr/portage/distfiles 10.0.0.0/255.255.255.0(sync,rw,no_root_squash,no_subtree_check)
```

MfG Jimini

----------

## Randy Andy

Hähä,

ähnliches hatte ich auch schon mal, und der Fehler wird dir quasi auch schon genannt.

Ich tippe daher auf folgendes:

Lösche einfach mal die lock-datei, die meist nur 0kb groß ist, und vermutlich durch ungültigen Abbruch der operation zustande kam, und alles wird gut.

Bin mir mit dem Pfad nicht sicher, da ich hier nicht am Gentoo-PC sitze, vermutlich unter:

/var/portage/distfiles/lockfile oder lock.

Wetten daß.

Good luck,

Andy.

----------

## musv

 *disi wrote:*   

> Einen aehnlichen Fehler "ungueltig" hatte ich sonst nur auf reiser4 ohne nfs gesehen.

 

Öhm, beide Rechner sind auf root mit Reiser4 bestückt.   :Shocked: 

 *Jimini wrote:*   

> Meine Freigabe sieht wie folgt aus:
> 
> ```
> /usr/portage/distfiles 10.0.0.0/255.255.255.0(sync,rw,no_root_squash,no_subtree_check)
> ```
> ...

 

meine auch. D.h. anderer Pfad und andere IP.

 *Randy Andy wrote:*   

> Lösche einfach mal die lock-datei, die meist nur 0kb groß ist, und vermutlich durch ungültigen Abbruch der operation zustande kam, und alles wird gut.
> 
> Bin mir mit dem Pfad nicht sicher, da ich hier nicht am Gentoo-PC sitze, vermutlich unter:
> 
> /var/portage/distfiles/lockfile oder lock.

 

werd ich heut abend mal probieren.

----------

## disi

Hier ist der Fehler, den ich hatte. Es war "directory not empty" bzw. irgendso eine kaputte inode.

http://marc.info/?l=reiserfs-devel&m=126998004110839&w=2

Auf der Mailingliste sind einige andere mit acl Problemen auf reiser4

Mit NFS hatte ich mal Versionsprobleme zwischen NFS4 und NFS3. Es ist wichtig, dass du den NFS3 Client nimmst und nicht NFS4. Beim Server ist es egal.

https://forums.gentoo.org/viewtopic-t-815826-highlight-nfs.html

Sonst habe ich auch keine Idee mehr  :Smile: 

----------

## musv

Bin wohl nicht der Erste:

https://bugs.gentoo.org/show_bug.cgi?id=318847

Naja, gibt's erstmal keine Updates.

Trotzdem danke für die Hinweise.  :Smile: 

----------

## haegar87

Ich weiß zwar keine Lösung für das eigentlich Problem, 

aber ich habe einen Lösungsvorschlag!   :Wink: 

Ich bevorzuge die simple Methode, die gentoo von hause aus mitbringt.

Die Distfiles werden vom Server via FTP im lokalen Netz freigegeben. In die mirrorliste kommt einfach der eigene Server als erstes rein.

So versucht emerge bei jedem Paket dieses zuerst lokal im Netzwerk zu bekommen, und wenn das nicht da ist, springt er auf den ersten INet Mirror und läd es von da. Bei aktuellen 1000MBit Netzwerken is da auch kein großer Zeitverlust merkbar...

Der umgekehrte Weg vom lokalen Distfiles Verzeichnis zum Server läuft via rsync. Damit werden doppelte Dateien ignoriert, und nicht vorhandene dazukopiert.

Das Distfiles Verzeichnis liegt unter tmp, sodass es beim neustart dann auch automatisch geleert wird.

Is aber nurn Lösungsvorschlag, falls die NFS Freigabe nach wie vor nicht funktioniert ^^

Grüße,

haegar87

----------

## lxg

… und hier die (inoffizielle) Anleitung dazu: http://www.gentoo-wiki.info/TIP_Using_PORTAGE_BINHOST

(Habe ich heute schon drei mal gepostet, scheint gerade ein heißes Thema zu sein.  :Wink: )

----------

## musv

Ja, das wäre eine Möglichkeit, aber:

Sinn ist vor allem auch, dass ich die Distfiles nicht lokal auf dem Notebook speichern muss. Die Distfiles liegen 1x auf dem Desktoprechner und das reicht mir auch. Die Notebookfestplatte ist 20 GB groß. Mit Herstellerumrechnung (20GB = 18.6 GB), Swap/Root und Home-Verzeichnisse geht der Platz da ziemlich schnell zur Neige. Aus dem Grund möchte ich auch die Distfiles gar nicht erst auf der Miniplatte abspeichern.

----------

## mv

FEATURES=-distlocks

Bei so wenig Plattenplatz (ich habe das gleiche Problem) empfehle ich, /usr/portage, /var/db, /usr/src/kernel, /usr/share/texmf-dist, und /usr/share/games mit squash_dir aus dem mv overlay zu komprimieren.

----------

## musv

Portage + Overlays nutze ich schon seit Jahren über Squashfs. Ist vor allem auch praktisch, dass man nach einem emerge --sync dann einfach das  gepackte Portageimage auf die anderen Rechner schieben kann. Hatte ganz früher alles über nfs laufen. Nur ist emerge dann elende lahm. 

/var/db, Kernelsourcen und das Tex-Zeux hab ich (noch) nicht ausgelagert. Da hab ich bisher noch keine Notwendigkeit gesehen. Werd mir aber die Idee mal zu Gemüte führen.

Frage zu distlocks:

Was passiert dann, wenn beide Rechner gleichzeitig beginnen, das entsprechende Distfile runterzuladen?

----------

## mv

 *musv wrote:*   

> Was passiert dann, wenn beide Rechner gleichzeitig beginnen, das entsprechende Distfile runterzuladen?

 

Einer der beiden lädt es dann umonst herunter (von ganz wenigen Fällen vielleicht abgesehen, bei denen eine Race condition zuschlagen könnte, und beide Prozesse mit dem selben Filehandle enden - das sollte aber wohl eher ein akademischer Fall sein).

----------

## musv

Hab heute dann doch mal ein Update versucht (Minitube). 

```
FEATURES="-distlocks" emerge -1u minitube

Calculating dependencies... done!

!!!

!!! parallel-fetching requires the distlocks feature enabled

!!! you have it disabled, thus parallel-fetching is being disabled

!!!

>>> Verifying ebuild manifests

>>> Emerging (1 of 1) media-video/minitube-1.1

 * minitube-1.1.tar.gz RMD160 SHA1 SHA256 size ;-) ...                   [ ok ]

Traceback (most recent call last):

  File "/usr/lib/portage/bin/ebuild", line 268, in <module>

    debug=debug, tree=mytree)

  File "/usr/lib/portage/pym/portage/proxy/objectproxy.py", line 32, in __call__

    return result(*args, **kwargs)

  File "/usr/lib/portage/pym/portage/package/ebuild/doebuild.py", line 838, in doebuild

    fetchonly=fetchonly):

  File "/usr/lib/portage/pym/portage/proxy/objectproxy.py", line 32, in __call__

    return result(*args, **kwargs)

  File "/usr/lib/portage/pym/portage/package/ebuild/fetch.py", line 612, in fetch

    stat_cached=mystat)

  File "/usr/lib/portage/pym/portage/util/__init__.py", line 910, in apply_secpass_permissions

    stat_cached=stat_cached, follow_links=follow_links)

  File "/usr/lib/portage/pym/portage/util/__init__.py", line 745, in apply_permissions

    os.chown(filename, uid, gid)

  File "/usr/lib/portage/pym/portage/__init__.py", line 228, in __call__

    rval = self._func(*wrapped_args, **wrapped_kwargs)

OSError: [Errno 22] Invalid argument: '/var/portage/distfiles/minitube-1.1.tar.gz'

 * Fetch failed for 'media-video/minitube-1.1', Log file:

 *  '/var/tmp/portage/media-video/minitube-1.1/temp/build.log'

>>> Failed to emerge media-video/minitube-1.1, Log file:

>>>  '/var/tmp/portage/media-video/minitube-1.1/temp/build.log'

 * Messages for package media-video/minitube-1.1:

 * Fetch failed for 'media-video/minitube-1.1', Log file:

 *  '/var/tmp/portage/media-video/minitube-1.1/temp/build.log'
```

Das Lustige daran ist, dass das Package bereits vorhanden ist. Es müsste also nicht mal runtergeladen werden. Im Bugreport gibt's auch keine Neuigkeiten.

----------

## mv

Dann schalte halt das FEATURE zum parallelen herunterladen aus: Dass das ohne lockfiles Schwierigkeiten machen kann, kann ich mir schon vorstellen.

----------

