Beiträge von thorium666


    Hi,
    den Eindruck habe ich auch, ich habe auf meinem Laptop geschaut und da ist das gleiche Bild.
    Nachtrag: Auf allen 3 TWs...


    Hier auch noch ein Leap (nicht der NFS server)



    Der hat auch kein NFS in der chain (hat auch kein NFS in der fstab) jedoch:


    Code
    nfs-mountd.service - NFS Mount Daemon
       Loaded: loaded (/usr/lib/systemd/system/nfs-mountd.service; static)
       Active: inactive (dead)


    Was bei den TWs ergibt:



    Code
    systemctl status nfs-mountd.service
    ● nfs-mountd.service
       Loaded: not-found (Reason: No such file or directory)
       Active: inactive (dead)

    NFS Client:



    NFS Server:



    NFS Server (Leap 42.1)

    Code
    toxic:/ # systemd-analyze blame |grep nfs
               321ms var-lib-nfs-rpc_pipefs.mount
               303ms proc-fs-nfsd.mount
                34ms nfs-server.service
                17ms nfs-mountd.service
                 5ms nfs-config.service
                 3ms nfs-idmapd.service
                 2ms nfsserver.service


    NFS Client (TW)


    Code
    vega:/home/devil # systemd-analyze blame |grep nfs
    vega:/home/devil #

    NFS Client (TW)

    Code
    vega:/home/devil # systemctl status nfs-mountd.service
    ● nfs-mountd.service
       Loaded: not-found (Reason: No such file or directory)
       Active: inactive (dead)

    NFS Server (Leap 42.1)

    Code
    toxic:/ # zypper se -si | grep nfs
    i | nfs-client                                 | package     | 1.3.0-14.1                    | x86_64 | Main Update Repository   
    i | nfs-kernel-server                          | package     | 1.3.0-14.1                    | x86_64 | Main Update Repository   
    i | nfsidmap                                   | package     | 0.25-7.1                      | x86_64 | Main Repository (OSS)    
    i | yast2-nfs-client                           | package     | 3.1.16-5.2                    | noarch | Main Repository (OSS)    
    i | yast2-nfs-common                           | package     | 3.1.8-5.2                     | noarch | Main Repository (OSS)    
    i | yast2-nfs-server                           | package     | 3.1.8-5.2                     | noarch | Main Repository (OSS)


    NFS Client (TW)


    Code
    vega:/home/devil # zypper se -si | grep nfs
    i | nfs-client                           | package     | 1.3.3-5.1                    | x86_64 | openSUSE-Tumbleweed-Oss                                                 
    i | nfsidmap                             | package     | 0.26-1.3                     | x86_64 | openSUSE-Tumbleweed-Oss                                                 
    i | yast2-nfs-client                     | package     | 3.1.16-1.1                   | noarch | openSUSE-Tumbleweed-Oss                                                 
    i | yast2-nfs-common                     | package     | 3.1.8-1.4                    | noarch | openSUSE-Tumbleweed-Oss

    @Sauerland, gut gesehen, habe ich heute nacht schon :)


    @Trekkie,
    kleinere nummer (höhere Prio)


    Code
    | Alias                  | Name                                                                     | Enabled | GPG Check | Refresh | Priority | URI                                                                                    
    --+------------------------+--------------------------------------------------------------------------+---------+-----------+---------+----------+----------------------------------------------------------------------------------------
    1 | isv_ownCloud_community | Latest stable community release of ownCloud server (openSUSE_Tumbleweed) | Yes     | (r ) Yes  | Yes     |   20     | http://download.opensuse.org/repositories/isv:/ownCloud:/community/openSUSE_Tumbleweed/
    3 | packman                | packman                                                                  | Yes     | (r ) Yes  | Yes     |   20     | http://ftp.gwdg.de/pub/linux/misc/packman/suse/openSUSE_Tumbleweed/                    
    2 | openSUSE-20151209-0    | openSUSE-20151209-0                                                      | No      | ----      | No      |   99     | cd:///?devices=/dev/disk/by-id/ata-VBOX_CD-ROM_VB1-1a2b3c4d                            
    4 | repo-debug             | openSUSE-Tumbleweed-Debug                                                | No      | ----      | Yes     |   99     | http://download.opensuse.org/debug/tumbleweed/repo/oss/                                
    5 | repo-non-oss           | openSUSE-Tumbleweed-Non-Oss                                              | Yes     | (r ) Yes  | Yes     |   99     | http://download.opensuse.org/tumbleweed/repo/non-oss/                                  
    6 | repo-oss               | openSUSE-Tumbleweed-Oss                                                  | Yes     | (r ) Yes  | Yes     |   99     | http://download.opensuse.org/tumbleweed/repo/oss/                                      
    7 | repo-source            | openSUSE-Tumbleweed-Source                                               | No      | ----      | Yes     |   99     | http://download.opensuse.org/source/tumbleweed/repo/oss/                               
    8 | repo-update            | openSUSE-Tumbleweed-Update                                               | No      | ----      | Yes     |   99     | http://download.opensuse.org/update/tumbleweed/


    Ich habe jetzt auch meinen Workarround zum test deaktiviert und komme auch bereinigt nur ohne NFS mappings hoch.

    Die Ausgabe habe ich dir schon gegeben, die waren exakt 0 Pakete aus den Update Repo. Ich brauche das nicht auch zwingend, habe nach der Sicherung zudem deine Schritte soeben durchgeführt, jedoch Owncloud höher priorisiert.


    OT,


    ich war hier auch am überlegen, wollte jedoch bei den Systemen kein Software-Museum haben also habe ich mich so entschieden. Lediglich der Unterbau ist konservativ. Die Entscheidung war jedich nicht unbedingt richtig, die Migration auf Leap plane ich schon.

    Kannst du das bestätigen, dass das verhalten diesbezüglich bei TW und Leap anders ist ?
    Bei Leap brauche ich das Update, bei TW nicht?


    Ich habe gerade die VM weggesichert und werde deine Schritte direkt auf der TW durchgehen. Ich denke ich weiss jetzt auch woher das Update kommt. Bei der Installation wird man gefragt ob man Online Repos hinzufügen will, bestätigt man das hat man ein Update Repo drinn (ohne es manuell auszuwählen).

    Nicht durcheinander bringen. Ich hoste alle Server auf einer Leap 42.1 Maschine. Vor jedem Update des Hosts werden die Updates auf einer Leap 42.1 Test maschine getestet. Auf dem Host laufen 2 Tumbleweeds "produktiv" . Ich habe deine Anleitung auf meinem Test Server getestet, habe gerade keine Tumbleweed Testmachine zur Hand also habe ich es auf dem leap 42.1 Test gemacht indem ich die beiden Update Repos entfernt habe und die Zypperkommands ausgeführt habe um das Verhalten nachzuvollziehen . Für die Verwirrung habe ich hier gerade gesorgt, ich wollte jedoch deine Anleitung nachvollziehen.


    Wir reden hier über einen der TWs, ich würde gerne deine Anleitung befolgen möchte jedoch nicht das gleiche Verhalten sehen wie eben auf dem Leap beim entfernen des "Update" repos.

    Sourcen brauche ich schon. Wieso Owncloud nach 120 (Niedrigste) ? Debug & CD sind eh schon deaktiviert.


    Ich habe das auch schnell mal auf meinem Crash & Burn Server getestet (Ist kein TW sondern Leap 42.1), damit bekomme ich sogar den kernel-default-4.1.12-1.1 wieder installiert, 800 Pakete downgegraded.
    Dabei wären das auf der Maschine die einzigen aktiven nachdem ich Update OSS/ Update Non OSS entfernt habe


    6 | repo-non-oss | openSUSE-Leap-42.1-Non-Oss | Yes | (r ) Yes | Yes
    7 | repo-oss | openSUSE-Leap-42.1-Oss | Yes | (r ) Yes | Yes
    8 | repo-source | openSUSE-Leap-42.1-Source | Yes | (r ) Yes | Yes


    • zypper clean
    • zypper ref
    • zypper dup

    Führte dann zu dem oben genannten was ich direkt abgebrochen habe. Ich werde das auf dem Produktivsystem nicht machen.
    Ich habe mir auch mal den Inhalt von openSUSE-Leap-42.1-Oss / Index of /distribution/leap/42.1/repo/oss/suse/x86_64 angesehen, das entspricht dem Installationsmedium. Bei Leap 42.1 brauche zwingend das Update Repo.


    Ist das bei TW anders ?

    Code
    vega:/home/devil # zypper se -si | grep openSUSE-Tumbleweed-Update
    vega:/home/devil #

    Das Repo habe ich nicht hinzugefügt, es kam wohl automatisch rein. Auch die schlechte Priorisierung habe ich nicht bewusst verzapft. Was schlägst du als Priorisierung vor ? Derzeit ziehen die Suse Pakete vor den von Packman (die werden nur für ein paar Bibliotheken benötigt). Ich weiss außerdem nicht wie es bei meinem Problem (gehe von Timings beim Boot aus) weiterhelfen soll.


    Nachtrag:
    wenn ich das hier richtig lese:
    Über den Umgang mit openSUSE Repos
    wären die Packman & Owncloud höher zu priorisieren? Ich bin allerdings mit der Qualität von Packman nicht immer zufrieden, vor allem das Mediatomb ist ein Dauerpatient (jedes Update entfernt die Binaries, ein un/reinstall von MT ist immer notwendig). Auch ist die Anzahl der Packman Pakete überschaubar (soll auch so bleiben), die Neupriorisierung würde auch nur bei Neuinstallationen ziehen (habe bewusst kein dup gemacht)?

    Hi


    hier:


    Code
    # | Alias | Name | Enabled | GPG Check | Refresh | Priority | URI
    --+------------------------+--------------------------------------------------------------------------+---------+-----------+---------+----------+----------------------------------------------------------------------------------------
    1 | isv_ownCloud_community | Latest stable community release of ownCloud server (openSUSE_Tumbleweed) | Yes | (r ) Yes | No | 99 | Index of /repositories/isv:/ownCloud:/community/openSUSE_Tumbleweed
    2 | openSUSE-20151209-0 | openSUSE-20151209-0 | No | ---- | No | 99 | cd:///?devices=/dev/disk/by-id/ata-VBOX_CD-ROM_VB1-1a2b3c4d
    3 | packman | packman | Yes | (r ) Yes | Yes | 99 | Index of /pub/linux/misc/packman/suse/openSUSE_Tumbleweed
    4 | repo-debug | openSUSE-Tumbleweed-Debug | No | ---- | Yes | 99 | Index of /debug/tumbleweed/repo/oss
    5 | repo-non-oss | openSUSE-Tumbleweed-Non-Oss | Yes | (r ) Yes | Yes | 99 | Index of /tumbleweed/repo/non-oss
    6 | repo-oss | openSUSE-Tumbleweed-Oss | Yes | (r ) Yes | Yes | 99 | Index of /tumbleweed/repo/oss
    7 | repo-source | openSUSE-Tumbleweed-Source | No | ---- | Yes | 99 | Index of /source/tumbleweed/repo/oss
    8 | repo-update | openSUSE-Tumbleweed-Update | Yes | (r ) Yes | Yes | 99 | Index of /repositories/openSUSE:/Factory:/Update/standard




    nach dem letzten großen Update, u.a. Kernel 4.5, besteht das Problem weiterhin. Mein Workarround muss weiterhin aktiv bleiben.


    Konsolenausgaben bitte in Code-Tags