Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

brikler
12.01.2020 10:49:14
[tom@donar ~]$ sudo pacman -S filesystem
[sudo] Passwort für tom: 
Warnung: filesystem-2019.08-1 ist aktuell -- Reinstalliere
Löse Abhängigkeiten auf...
Suche nach in Konflikt stehenden Paketen...

Pakete (1) filesystem-2019.08-1

Gesamtgröße der installierten Pakete:  0,24 MiB
Größendifferenz der Aktualisierung:  0,00 MiB

:: Installation fortsetzen? [J/n] 
(1/1) Prüfe Schlüssel im Schlüsselring                        [#################################] 100%
(1/1) Überprüfe Paket-Integrität                              [#################################] 100%
(1/1) Lade Paket-Dateien                                      [#################################] 100%
(1/1) Prüfe auf Dateikonflikte                                [#################################] 100%
(1/1) Überprüfe verfügbaren Festplattenspeicher               [#################################] 100%
Warnung: konnte Dateiinformationen für var/log/old/ nicht ermitteln
:: Verarbeite Paketänderungen...
(1/1) Installiere filesystem                                  [#################################] 100%
:: Starte post-transaction hooks...
(1/1) Arming ConditionNeedsUpdate...

hoffentlich war es das jetzt und hab hoffentlich wieder ruhe.

@ohshi1Ae
danke schön smile

ohshi1Ae
11.01.2020 22:55:23
brikler schrieb:

/sbin bzw /usr/sbin war nicht leer und der link von /sbin/init zu /usr/lib/systemd/systemd war richtig gesetzt.

/usr/lib/systemd/systemd ist aber aus /sbin nicht erreichbar, wenn es nicht auf /usr/bin zeigt. Und für /usr/sbin gilt das gleiche. Deswegen ist es definitiv falsch, wenn /sbin ein statisches Verzeichnis und kein symbolischer Link ist.

Und alles, was jetzt über pacman nach /usr/bin installiert wird, würde nicht mehr in /sbin erscheinen, und Anwendungen, die das auf /sbin erwarten, fahren dann vor die Wand. Installier doch noch mal das Paket "filesystem", dann wirst du schon sehen, wo es bei so einer Verzeichnisstruktur überall kracht.

brikler
11.01.2020 22:20:08

/sbin bzw /usr/sbin war nicht leer und der link von /sbin/init zu /usr/lib/systemd/systemd war richtig gesetzt.

mit dem 5.4 er kernel hatte und hab ich ärger mit der graphik, da hab ich ihn mal "abgewürgt", da kommt wahrscheinlich der datenverlust her.
damals hab ich mir mit einem "pacman -S `pacman -Qqn`" beholfen, wie ach dieses mal, mit dem selben problem… jetzt hab ich hald danach gefragt.

ohshi1Ae
11.01.2020 21:10:25

Da ist noch mehr kaputt. /usr/sbin müsste z. B. auf /usr/bin verlinkt sein, das ist bei dir aber ein Verzeichnis. Da liegt übrigens auch ganz nebenbei noch ein Link zu "init", was möglicherweise auch den Fehler "no working init found" erklären könnte, wenn /sbin leer war, bzw. nicht auf das richtige Verzeichnis mit den nötigen Inhalten verweist.

Da müsstest du mal in dich gehen und versuchen dich zu erinnern, was du vor dem Bootproblem gemacht hast, denn das kommt ja auch nicht von ungefähr.

brikler
11.01.2020 20:46:41
ohshi1Ae schrieb:
stefanhusmann schrieb:

Hast du mal virifiziert, ob /usr/lib64 bei dir auch tatsächlich ein Symlink auf /usr/lib ist?

Der Link wird eigentlich vom Paket "filesystem" angelegt, entweder ist da früher schon mal etwas schief gelaufen,

gut möglich, daß da was "verbogen" ist, gestern bekam ich beim starten den "freundlichen" hinweis "no working init found", also hab ich im chroot alle pakete neu installiert, dann konnte ich wieder wie gewohnt booten

ohshi1Ae schrieb:
brikler schrieb:

mit "funktionieren" meinte ich: es lässt sich kompiliert und /usr/lib64 ist ein symlink auf /usr/lib

  
lrwxrwxrwx   1 root root    7 17.08.2019 22:15 lib64 -> usr/lib/

Es geht nicht um "lib64" sondern um "/usr/lib64".

[tom@donar ~]$ ls -l /usr/
insgesamt 318
drwxr-xr-x   3 root root 118784 11.01.2020 19:33 bin/
drwxr-xr-x 293 root root  24576 11.01.2020 19:33 include/
drwxr-xr-x 127 root root 249856 11.01.2020 19:42 lib/
drwxr-xr-x   5 root root   4096 11.01.2020 11:14 lib32/
drwxr-xr-x   2 root root   3488 11.01.2020 17:14 libexec/
drwxr-xr-x  11 root root   3488 27.01.2019 19:10 local/
drwxr-xr-x   3 root root   3488 10.04.2019 15:56 man/
drwxr-xr-x   2 root root   8192 11.01.2020 19:26 sbin/
drwxr-xr-x 202 root root   8192 11.01.2020 18:12 share/
drwxr-xr-x   3 root root   3488 05.01.2020 18:24 src/
lrwxrwxrwx   1 root root     12 27.01.2019 20:48 depmod -> /sbin/depmod*
lrwxrwxrwx   1 root root      3 17.08.2019 22:15 lib64 -> lib/
ohshi1Ae
11.01.2020 20:27:02
brikler schrieb:

mit "funktionieren" meinte ich: es lässt sich kompiliert und /usr/lib64 ist ein symlink auf /usr/lib

  
lrwxrwxrwx   1 root root    7 17.08.2019 22:15 lib64 -> usr/lib/

Es geht nicht um "lib64" sondern um "/usr/lib64".

ohshi1Ae
11.01.2020 20:22:35
stefanhusmann schrieb:

Hast du mal virifiziert, ob /usr/lib64 bei dir auch tatsächlich ein Symlink auf /usr/lib ist?

Was ich auch reichlich seltsam finde ist, dass bei ihm pacman meldet, dass /usr/lib64 glibc gehört. Der Link wird eigentlich vom Paket "filesystem" angelegt, entweder ist da früher schon mal etwas schief gelaufen, oder es wurde Software an der Paketverwaltung vorbei installiert, die /usr/lib64 statt eines symbolischen Links als Ordner angelegt hat. Mit einem reinen Arch passiert so etwas nämlich nicht.

brikler
11.01.2020 20:17:32

mit "funktionieren" meinte ich: es lässt sich kompiliert und /usr/lib64 ist ein symlink auf /usr/lib

lrwxrwxrwx   1 root root    7 17.08.2019 22:15 lib64 -> usr/lib/
pkgname=kwin
pkgver=5.17.5
pkgrel=1
pkgdesc='An easy to use, but flexible, composited Window Manager'
arch=(x86_64)
url='https://www.kde.org/workspaces/plasmadesktop/'
license=(LGPL)
depends=(kscreenlocker xcb-util-cursor plasma-framework kcmutils breeze kinit qt5-sensors qt5-script)
makedepends=(extra-cmake-modules qt5-tools kdoctools)
optdepends=('qt5-virtualkeyboard: virtual keyboard support for kwin-wayland')
groups=(plasma)
source=("https://download.kde.org/stable/plasma/$pkgver/$pkgname-$pkgver.tar.xz"{,.sig})
install=$pkgname.install
sha256sums=('8517adaf8270d783aea7b3886d86b5abed6a5ec2b5c78b632479597d956baadc'
            'SKIP')
validpgpkeys=('2D1D5B0588357787DE9EE225EC94D18F7F05997E'  # Jonathan Riddell <jr@jriddell.org>
              '0AAC775BB6437A8D9AF7A3ACFE0784117FBCE11D'  # Bhushan Shah <bshah@kde.org>
              'D07BD8662C56CB291B316EB2F5675605C74E02CF'  # David Edmundson <davidedmundson@kde.org>
              '1FA881591C26B276D7A5518EEAAF29B42A678C20') # Marco Martin <notmart@gmail.com>

prepare() {
  mkdir -p build
}

build() {
  cd build
  cmake ../$pkgname-$pkgver \
    -DCMAKE_INSTALL_LIBEXECDIR=lib \
    -DBUILD_TESTING=OFF
  make
}

package() {
  cd build
  make DESTDIR="$pkgdir" install
}

https://projects.archlinux.de/svntogit/ … ages/kwin]

ich hab grad was am PKGBUILD verändert, ich hab die cmake direktiven aus dem 15.7-3 mit dazu getan und pacman hat nicht gemeckert:

cmake ../$pkgname-$pkgver \
     -DCMAKE_BUILD_TYPE=RelWithDebInfo \
    -DCMAKE_INSTALL_PREFIX=/usr \
    -DKDE_INSTALL_LIBDIR=lib \
    -DKDE_INSTALL_SYSCONFDIR=/etc \
    -DKDE_INSTALL_LIBEXECDIR=lib \
    -DUDEV_RULES_INSTALL_DIR=/usr/lib/udev/rules.d \
     -DKDE_INSTALL_USE_QT_SYS_PATHS=ON "$@" \
#ab da aktuelles PKGBUILD
    -DCMAKE_INSTALL_LIBEXECDIR=lib \
    -DBUILD_TESTING=OFF 
  make

…aber so richtig toll ist das auch nicht:

==> WARNUNG: Paket enthält einen Verweis auf $srcdir
usr/lib/libkwinglutils.so.5.17.5
==> Erstelle Paket "kwin"...
  -> Erstelle .PKGINFO Datei...
stefanhusmann
11.01.2020 20:05:30

Wenn das Paket wirklich reproduzierbar nach /usr/lib64 installieren würde, würde es eben nicht richtig funktionieren.

Hast du mal virifiziert, ob /usr/lib64 bei dir auch tatsächlich ein Symlink auf /usr/lib ist?

ohshi1Ae
11.01.2020 19:47:52

Nein, es funktioniert nicht, sonst würdest du nicht versuchen, etwas nach /usr/lib64 zu installieren.

brikler
11.01.2020 19:01:01

danke schön, aber ich hab am PKGBUILD überhaupt nichts verändert, warum auch? es funktioniert schließlich…

stefanhusmann
11.01.2020 18:40:37

An der cmake-Option

-DCMAKE_INSTALL_LIBEXECDIR=lib \

aus der build-Funktion hast du nicht gedreht? Die ist nämlich geanu dafür da, damit dies nicht passiert.

ohshi1Ae
11.01.2020 18:24:26

pacman meckert, weil es unter /usr/lib64 Dateien installieren soll, die es unter /usr/lib schon gibt, um das mal auf einen einfachen Nenner zu bringen.

Wenn du mit "pacman -Ql kwin" abfragst wirst du sehen, dass in der pacman-Datenbank die Dateien als sich unter /usr/lib befindlich registriert wurden. Und genau diese Dateien in diesem Verzeichnis würden bei einem Update des Pakets auch ohne Rückfrage  überschrieben. Aus der Sicht von pacman ist /usr/lib ein anderes Verzeichnis als /usr/lib64, bei dem Installationsversuch merkt es aber wegen des symbolischen Links auf /usr/lib, dass die Datei in /usr/lib64 schon existiert, und verweigert die Installation. Mit "pacman -Qo" kannst du auch noch einmal ausdrücklich pacman befragen, welche Datei zu welchem Paket gehört. Es darf immer genau nur einen Besitzer geben.

Die einzige vernünftige Maßnahme kann also nur sein, den Dateikonflikt durch Installation in das richtige Verzeichnis zu lösen.

brikler
11.01.2020 18:04:52

ich hab das PKGBUILD aus dem arch repo und mir bis jetzt da keine gedanken drum gemacht…
zum beispiel cairo hats genau so wie kwin, aber warum meckert da nicht pacman?

ohshi1Ae
11.01.2020 17:07:23
brikler schrieb:

kwin: /usr/lib64 existiert im Dateisystem (gehört zu glibc)

Du musst dein Paket so bauen, dass nach /usr/lib installiert wird, weil /usr/lib64 ein symbolischer Link darauf ist, und deshalb kein Verzeichnis mit gleichem Namen angelegt werden kann.

Fußzeile des Forums

Powered by FluxBB