Jump to content

stockfisch

Members
  • Content Count

    55
  • Joined

  • Last visited

About stockfisch

  • Rank
    Amateur

Fußball, Hobbies, Allerlei

  • Lieblingsverein
    SKV - wos sunst?
  • Beruf oder Beschäftigung
    V Programmierknecht

Kontakt

  • Website URL
    http://

Allgemeine Infos

  • Geschlecht
    Männlich
  • Aus
    Stahlstadt

Recent Profile Visitors

3,145 profile views
  1. ok, dann versuchens wir mal mit apt-pinning - ist mit Sicherheit der sauberere Weg ... leg mal bitte ein file /etc/apt/preferences.d/ppa mit folgendem Inhalt an .. Package: * Pin: origin ppa.launchpad.net Pin-Priority: 1000 dann sollten alle packages von ppa.launchpad.net mit einer hoeren Prioritaet behandelt werden; sprich ein apt-get update; apt-get install --reinstall libdrm-amdgpu1 libgl1-mesa-dri mesa-va-drivers sollte dir dann die passende Packete neuinstallieren; wenns noch nicht geht, die Packete deinstallieren und anschliessen neuinstallieren.
  2. wie erwartet, der Versionskonflikt kommt dadurch, dass du das PPA http://ppa.launchpad.net/oibaf/graphics-drivers/ubuntu eingebunden hast -> ein apt-get install libdrm-amdgpu1=2.4.89+git1801130630.fd9bcb~oibaf~x sollte die libdrm-amdgpu auf die gwuenschte Version heben, danach solltes du wie gewoehnt die restlichen beiden Packages installieren .. ein Tip: ich kenn synaptic nicht wirklich, aber wenns schon was 'graphisches' sein soll, dann verwende aptitude fuers installieren / deinstallieren .. Vorteil: du kannst dir gleich die moeglichen Versionen etc ansehen bzw. Versionskonfl
  3. Seas, mach mal ein apt-cache policy libgl1-mesa-dri bzw. libdrm-amdgpu1. Mein Verdacht ist, dass du andere Packetquellen (also irgendwelche PPAs oder haendisch halt Eintraege in der sources.list bzw in sources.list.d/) eingebunden hast und dadurch die fehlende/falsche Packetabhaengigkeit entstanden ist ... wahrscheinlich wird dir folgendes helfen: libdrm-amdgpu1 auf die >= 2.4.89... Version heben, dann koennen die anderen 2 Packete problemlos installiert werden. Vorausgesetzt das Packet steht nicht auf 'hold' Aufgrund einer anderen Abhaengigkeit ..
  4. ad devuan: Revoluzzer ist vielleicht ein wenig uebertrieben, aber ihr Ziel, ein debian stable ohne systemd, finde ich sehr vernueftig ad arch: ich hab im Maerz 1997 mein erstes Unix in der Hand gehabt - witzigerweise ein SCO Unix (die original CDs lagern noch immer irgendwo) .. zeitgleich auch eine 'aeltere' DLD (Deutsche Linux Distribution) bzw. bin dann kurz danach durch Zufall auf eine SuSE 4.2 gestossen und hab ein paar Versionen mitgemacht (bis zur 6.4 glaub ich ) .. zu dieser Zeit hatte ich oefters mit debian servern (Ham und Potato war das noch) Kontakt, ca. zur selben Zeit stellt
  5. ja slackware koennte man noch durchgehen lassen ich stehe dieser Entwicklung (systemd) uebrigens nicht wohlgesonnen gegenueber - wenn nur das devuan endlich mal in Richtung stable-release kommen wuerde ...
  6. naja, es ist eigentlich eher ein generelles Problem von den (meisten) Distributionen .. die Entwicklung von SYS-V in Richtung systemd ist so ziemlich das Gegenteil von dem, was die Unix-Philosophie ausmacht .. da ist mittlerweile OS-X mehr Unix (und da sogar 'offiziell') als jedes beliebiges Linux. Wenns nahe an Unix sein soll, bleiben eher nur mehr die BSDs uebrig .. aber Gegenfrage: welche Unices kennst du, um zu sagen, Arch ist nahe dran .. finde persoenlich da eher wenig Gemeinsamkeiten bei AIX, True64 oder Solaris ..
  7. hmm, das glaub ich nicht TIm .. Stichwort systemd
  8. Seas, so rein gefuehlsmaessig sollte die Kiste eh genuegend Power mitbringen, um normal arbeiten damit zu koennen (vielleicht einen SSD rein, dann rockts vermutlich richtig Wenn das ein Arbeitsrechner werden soll wuerde ich ganz pragmatisch (auch wenns fuer manche hier nicht cool ist) debian nehmen, mit mate als Desktop (oder wenns schlanker sein soll lxde) .. fertig .. Von Gentoo wuerde ich absehen, macht sicher richtig viel Spass, alle paar Tage FIrefox/Chrome etc neu zu kompilieren auf der Kiste .. wobei je nach Leidensfaehigkeit sicher kein Problem, aber (Geschwindigkeits)
  9. d.h. dein "Umzug" hat jetzt geklappt? Freut mich ..
  10. einfach mal die Glaskugel angeworfen: dein /boot ist eine eigene Partition und du hast sie nicht in deine chroot umgebung gemountet -> daher findet er den kernel nicht? Weil die Fehlermeldung waere relativ aussagekraeftig
  11. Seas Mazunte, geh, wegen Probleme mit der Ramdisk neu aufsetzen? Wechselst du bei einem quietschenden Scheibenwischer auch das Auto? poste mal deine Fehlermeldung(en)
  12. es soll auch Leute geben, die sich ihre System zurechtkonfiguriert haben .. da ist der Mehraufwand nach Neuinstallation sicher hoeher .. aber ok, ist ja anscheinend eine (ARCH) Spielzeugkiste
  13. Seas, kurz zusammengefasst, so sollte es passen: cryptsetup luksOpen /dev/sda2 crypt_sda2 mkdir /mnt/crypt_sda2 mount -o ro /dev/mapper/crypt_sda2 /mnt/crypt_sda2 wenn es das neue crypto-device eh schon gibt: cryptsetup luksOpen /dev/sdc2 crypt_sdc2 mkdir /mnt/crypt_sdc2 mount /dev/mapper/crypt_sdc2 /mnt/crypt_sdc2 cd /mnt/crypt_sda2 tar -x | ( cd /mnt/crypt_sdc2 && tar -x ) oder auch alternativ mit rsync: rsync -aux /mnt/crypt_sda2/* /mnt/crypt_sdc2 (sollte auch passen denk ich ^^) ahja, fast vergessen .. /etc/fstab natuerlich anpassen und n
  14. ok, dann nehm ich dich ein wenig an der Hand .. hab aber gerade nicht viel Zeit, alles aus dem Kopf raus .. boote dein Rettungsystem von USB/DVD/PXE/whatever .. als root blkid | grep-i crypto -> da siehst du deine Partition (TYPE=crypto_LUKS") cryptsetup luksOpen /dev/XXXX <name_fuer_cryptdevice> (da wirst du nach der Passphrase gefragt) mount /dev/mapper/<name_fuer_cryptdevice> /mnt/irgendwo voala - somit hast du Zugriff auf deine Files ... neue Disk: partitioniern (eh klar) cryptsetup -y -v luksFormat /dev/YYYY neue Passphras
  15. Wieso nicht? Soviel Platz belegt? Ansonsten einfach haendisch mit irgendeinem Rettungssystem booten, das vorhanden Luks Volume mounten, das neue erstellen und anschliessend Files rueber, Bootloader/Grub neu installieren, fertig ..
×
×
  • Create New...