Fehler Installation

    • Offizieller Beitrag

    Guten Morgen Lina Valantukeviciute


    welche Version ist denn installiert?

    Code
    dpkg -l libaio1

    Dies gibt Ihnen Informationen zur installierten Version von libaio1. Wenn Sie sicherstellen möchten, dass Sie die neueste Version von libaio1 installiert haben, können Sie den folgenden Befehl ausführen:

    Code
    sudo apt-get update && sudo apt-get upgrade libaio1

    Im Normalfall sollte ein Neustart nach der Installation nicht notwendig sein, jedoch habe ich in meiner Hyper-V Testumgebung unter ubuntu schon die Erfahrung gemacht, dass einzelne Dienste nicht, oder nicht richtig gestartet wurden. Welche Debian11 Version haben Sie denn verwendet? Ebenfalls die netinstall?

    • Offizieller Beitrag

    Guten Morgen StefanF,


    das Thema Debian 12 ist vorerst KEIN Thema, da wir Debian 12 noch nicht mit agorum getestet haben und es durchaus sein kann, dass es nicht funktioniert. Gerade vor 14 Tagen hatten wir einen ähnlichen Fall. Hier brachte die Verwendung von Debian 11 den erhofften Erfolg.


    Davon abgesehen: Leider hat es etwas gedauert, bis ich die Zeit gefunden habe, Deine Problematik lokal nachzuvollziehen. Ich kann Dein Problem bei der Installation von libaio jedoch leider nicht reproduzieren.

    Da die Ursache für derlei Probleme sehr vielfältig sein können, fällt das in den Bereich des Betriebs. Hier müsstest Du Dich u.U. einmal an die Debian-Community wenden.

    Hallo zusammen,


    ich arbeite in einer Proxmox-Umgebung und habe gerade agorum 11.3.0.3-1730 in einem Debian 12 Linux-Container ohne Probleme installiert. Das funktioniert bei mir automatisch mit einem Skript, das seit Debian 9 +/- unverändert geblieben ist.


    Als Master verwende ich den Standard-Container mit einigen zusätzlichen Paketen:

    Code
    BASE_PACKAGES="apt-utils iproute2 iputils-ping net-tools procps vnstat \
  unzip vim nano mc wget curl jq gnupg ca-certificates less cifs-utils \
  apt-transport-https dirmngr htop sudo pwgen software-properties-common \
  hdparm fio smartmontools lshw pciutils usbutils lsscsi libncurses5 \
  procps lsof psmisc"

    für agorum kommt dann noch dazu:

    Code
    OFFICE_PACKAGES="libaio1 imagemagick ghostscript libreoffice"

    In meiner Umgebung mit Proxmox 7.4-15 und Linux bookworm-agorum 5.15.108-1-pve #1 SMP PVE 5.15.108-1 (2023-06-17T09:41Z) x86_64 GNU/Linux funktioniert damit bisher alles reibungslos.


    Für mich sieht es so aus, als ob es weniger einer Problem von libaio1 oder Debian 12 ist, sondern eher mit der Kernel-Version, Kernel-Einstellungen und Hypervisor zusammenhängt.


    Vielleicht hilft das ja bei der Eingrenzung des Fehlers weiter ...



    Falls debian 12 mit netinstall iso installiert worden ist, kann es sein, dass /usr/sbin nicht im Pfad von root ist.


    In diesem Fall schlägt der Aufruf (der in der agorum installation enthalten ist)

    Code
     ldconfig -p | grep libaio.so.1 | grep /lib | wc -l


    fehl bzw. findet kein Ergebnis


    Um das zu beheben in der .bashrc des users der die Installation vornimmt

    Code
    nano ~/.bashrc

    den Eintrag

    Code
    export PATH=/usr/sbin:$PATH

    hinzufügen.


    Den user aus und wieder einloggen (damit der Pfad geladen werden kann)

    und dann wieder


    Code
    ldconfig -p | grep libaio.so.1 | grep /lib | wc -l


    ausführen.

    Das sollte "1" zurückgeben.

    Dann die agorum installation starten.

    Ich denke hier werden die verschiedenen Möglichkeiten sehr gut erklärt:
    (aus: https://stackoverflow.com/ques…ly-set-path-on-linux-unix)


    Zitat von stackoverflow

    There are multiple ways to do it. The actual solution depends on the purpose.

    The variable values are usually stored in either a list of assignments or a shell script that is run at the start of the system or user session. In case of the shell script you must use a specific shell syntax and export or set commands.

    System wide

    1. /etc/environment List of unique assignments. Allows references. Perfect for adding system-wide directories like /usr/local/something/bin to PATH variable or defining JAVA_HOME. Used by PAM and systemd.
    2. /etc/environment.d/*.conf List of unique assignments. Allows references. Perfect for adding system-wide directories like /usr/local/something/bin to PATH variable or defining JAVA_HOME. The configuration can be split into multiple files, usually one per each tool (Java, Go, and Node.js). Used by systemd that by design do not pass those values to user login shells.
    3. /etc/xprofile Shell script executed while starting X Window System session. This is run for every user that logs into X Window System. It is a good choice for PATH entries that are valid for every user like /usr/local/something/bin. The file is included by other script so use POSIX shell syntax not the syntax of your user shell.
    4. /etc/profile and /etc/profile.d/* Shell script. This is a good choice for shell-only systems. Those files are read only by shells in login mode.
    5. /etc/<shell>.<shell>rc. Shell script. This is a poor choice because it is single shell specific. Used in non-login mode.

    User session

    1. ~/.pam_environment. List of unique assignments, no references allowed. Loaded by PAM at the start of every user session irrelevant if it is an X Window System session or shell. You cannot reference other variables including HOME or PATH so it has limited use. Used by PAM.
    2. ~/.xprofile Shell script. This is executed when the user logs into X Window System system. The variables defined here are visible to every X application. Perfect choice for extending PATH with values such as ~/bin or ~/go/bin or defining user specific GOPATH or NPM_HOME. The file is included by other script so use POSIX shell syntax not the syntax of your user shell. Your graphical text editor or IDE started by shortcut will see those values.
    3. ~/.profile, ~/.<shell>_profile, ~/.<shell>_login Shell script. It will be visible only for programs started from terminal or terminal emulator. It is a good choice for shell-only systems. Used by shells in login mode.
    4. ~/.<shell>rc. Shell script. This is a poor choice because it is single shell specific. Used by shells in non-login mode.


    Übersetzt:

    Zitat

    Es gibt verschiedene Möglichkeiten, wie Umgebungsvariablen gesetzt werden können. Die tatsächliche Lösung hängt vom Zweck ab.

    Die Werte der Variablen werden normalerweise entweder in einer Liste von Zuweisungen oder in einem Shell-Skript gespeichert, das beim Start der System- oder Benutzersitzung ausgeführt wird. Bei einem Shell-Skript muss eine spezielle Shell-Syntax sowie die Befehle export oder set verwendet werden.

    Systemweit

    • /etc/environment: Liste von eindeutigen Zuweisungen. Erlaubt Referenzen. Perfekt, um systemweite Verzeichnisse wie /usr/local/something/bin zur PATH-Variablen hinzuzufügen oder JAVA_HOME zu definieren. Wird von PAM und systemd verwendet.
    • /etc/environment.d/*.conf: Liste von eindeutigen Zuweisungen. Erlaubt Referenzen. Perfekt, um systemweite Verzeichnisse wie /usr/local/something/bin zur PATH-Variablen hinzuzufügen oder JAVA_HOME zu definieren. Die Konfiguration kann auf mehrere Dateien aufgeteilt werden, normalerweise eine pro Tool (Java, Go, Node.js). Wird von systemd verwendet, gibt diese Werte jedoch standardmäßig nicht an Benutzer-Login-Shells weiter.
    • /etc/xprofile: Shell-Skript, das beim Start der X Window System-Sitzung ausgeführt wird. Es wird für jeden Benutzer ausgeführt, der sich in das X Window System einloggt. Eine gute Wahl für PATH-Einträge, die für jeden Benutzer gültig sind, wie /usr/local/something/bin. Die Datei wird von einem anderen Skript eingebunden, daher sollte die POSIX-Shell-Syntax und nicht die Syntax der Benutzershell verwendet werden.
    • /etc/profile und /etc/profile.d/: Shell-Skript. Eine gute Wahl für rein Shell-basierte Systeme. Diese Dateien werden nur von Shells im Login-Modus gelesen.
    • /etc/<shell>.<shell>rc: Shell-Skript. Eine schlechte Wahl, da sie spezifisch für eine einzige Shell ist. Wird im Nicht-Login-Modus verwendet.

    Benutzersitzung

    • ~/.pam_environment: Liste von eindeutigen Zuweisungen, keine Referenzen erlaubt. Wird von PAM beim Start jeder Benutzersitzung geladen, unabhängig davon, ob es sich um eine X Window System-Sitzung oder eine Shell handelt. Sie können keine anderen Variablen, einschließlich HOME oder PATH, referenzieren, daher ist die Verwendung eingeschränkt. Wird von PAM verwendet.
    • ~/.xprofile: Shell-Skript. Wird ausgeführt, wenn sich der Benutzer in das X Window System einloggt. Die hier definierten Variablen sind für jede X-Anwendung sichtbar. Perfekte Wahl, um PATH mit Werten wie ~/bin oder ~/go/bin zu erweitern oder benutzerspezifische Werte wie GOPATH oder NPM_HOME zu definieren. Die Datei wird von einem anderen Skript eingebunden, daher sollte die POSIX-Shell-Syntax verwendet werden. Ihr grafischer Texteditor oder IDE, die per Verknüpfung gestartet werden, sehen diese Werte.
    • ~/.profile, ~/.<shell>_profile, ~/.<shell>_login: Shell-Skript. Es wird nur für Programme sichtbar sein, die vom Terminal oder Terminal-Emulator aus gestartet werden. Eine gute Wahl für rein Shell-basierte Systeme. Wird von Shells im Login-Modus verwendet.
    • ~/.<shell>rc: Shell-Skript. Eine schlechte Wahl, da es spezifisch für eine einzige Shell ist. Wird von Shells im Nicht-Login-Modus verwendet.


    StefanF


    Möglicherweise sind deine Pfade in Dateien hinterlegt, die bei einem Update vom Linux überschrieben werden?

Jetzt Teil von agorum Community werden!

Noch kein Benutzerkonto? Registriere dich kostenlos und werde Teil von agorum Community!

Benutzerkonto erstellen Anmelden