Linux: Antergos (Arch)-Distri auf Thinkcentre läuft wunderbar, tolles Linux

@ syscrh,

danke für Deine Beiträge, diese sind für mich durchaus informativ.
Dennoch habe ich mal ein paar Fragen spezieller an Dich.
Was Für Versionen von Debian setzt Du zur zur Zeit und und wie lange würdest Du diese Nutzen? Beispielsweise geht der Support von Jessie wohl noch bis 2020, macht es Sinn dies bis dahin auch zu nutzen?

Eine andere Frage ist, nutzt Du auch aktuelle Hardware mit Debian, oder wie verhält es sich da bei Dir?
Generell nur ältere Hardware oder neue Hardware mit anderen Systemen?
Denn da Debian ja recht konserativ ist und dadurch nicht immer brandaktuell, aber dafür zuverlässig (zumindest Stable, mit Testing habe ich keine Erfahrung) ist dies nicht gerade die beste Voraussetzung für aktuelle Hardware.


Ich nutze ebenfalls auschließlich Debian. Zur Zeit läuft auf meinen verschiedenen Rechnern noch Wheezy, Jessie und Stretch. Für meine Produktivsysteme setze ich immer nur stable ein, lediglich mein T43 ist als Spielwiese immer mit testing bestückt. Die Oldstables die ich noch betreibe sind meist einfach nur noch nicht angehoben. Es gibt eigentlich wenig Gründe bei Oldstable zu bleiben, normalerweise kann man problemlos nach Erscheinen einer neuen stabilen Version auch auf diese wechseln. Es ist nicht nötig auf das erste Point-Release zu warten oder sowas in der Art.
Ich nutze Debian auf Geräten um Baujahr 2000 (Pentium 3) bis zu aktuellen Kaby-Lake Maschinen (alles stable wie gesagt). Die alten Kisten laufen genauso stabil und zuverlässig wie die aktuellen. Mir kommt dabei natürlich im Moment zu Gute, dass stable noch recht aktuell ist und einen "frischen" Kernel mitbringt. Aber falls der Kernel doch mal zu alt sein sollte für die verwendete Hardware gibt es ja die backports mit denen auch neuere Kernel genutzt werden können ;)
 
Ich denke das grundsätzliche Sicherheitsproblem von yaourt ist, dass die pkgbuilds relativ einfach von anderen Leuten hinzugefuegt/veraendert werden koennen und im Gegensatz zu den offiziellen Arch-Quellen (die schon deutlich laxer getestet und kontrolliert werden als es bei Debian der Fall ist) praktisch nicht getestet werden. Das hat Vor- und Nachteile. Teilweise wird versucht das Problem dadurch zu umgehen, dass der Nutzer den pkgbuild lesen kann bevor die Software installiert wird, so kann man einen Blick darauf haben was geschehen wird. Aber wirklich sicher ist das auch nicht, wer Sicherheit haben will muesste dazu alle Patches etc. lesen, was ein kaum zu bewaeltigender Zeitaufwand ist. Wie gesagt auf Systemen wo Sicherheit ein zentraler Faktor ist sollte man yaourt nicht einsetzen.
Vorteil davon ist, dass man ohne grosse Wartezeiten seine Software relativ direkt an die Community bringen kann und teilweise ueber yaourt sehr aktiv und rege kommuniziert wird. In meinen Augen ist die Sicherheit fuer einen Desktop OK, wenn irgendwo mal Mist drin steht dann wird es frueher oder spaeter schon auffliegen, man muss dann allerdings damit leben dass es erstmal drinsteht und erst im Nachhinein gefixt wird. Deswegen yaourt immer auf eigene Gefahr. :) Diese Bedenken gelten natuerlich nicht im gleichen Masse fuer die offiziellen Arch-Quellen, da wird in meinen Augen schon ausreichend sauber gearbeitet, wuerde ich vom Sicherheitsaspekt her sogar auf einen Server einsetzen, aber aus anderen Gruenden dann wieder nicht. :)
 
@ syscrh,

danke für Deine Beiträge, diese sind für mich durchaus informativ.

Danke, das freut mich! :)

Dennoch habe ich mal ein paar Fragen spezieller an Dich.
Was Für Versionen von Debian setzt Du zur zur Zeit und und wie lange würdest Du diese Nutzen? Beispielsweise geht der Support von Jessie wohl noch bis 2020, macht es Sinn dies bis dahin auch zu nutzen?

Persönlich versuche ich immer so bald wie möglich meine Rechner umzustellen, denn bisher hat mir jedes Debian-Release besser als das alte gefallen und daher hat sich ein zeitnahes Upgrade gelohnt. Das Schöne bei Debian ist ja, dass man keine Neuinstallation machen braucht und ein Update auf aktueller Desktop-Hardware damit schnell erledigt ist. Bei Servern kommt das dann wieder ganz darauf an, was man damit anstellt. ;)
Einsetzen kann man die Releases natürlich auch bis zum Ende des Support-Zeitraumes, denn unsicherer ist die ältere Version in der Theorie auch nicht. Kommt ganz darauf an, welche Hardware man betreibt und was man von seinem System erwartet.

Eine andere Frage ist, nutzt Du auch aktuelle Hardware mit Debian, oder wie verhält es sich da bei Dir?

Generell nur ältere Hardware oder neue Hardware mit anderen Systemen?
Denn da Debian ja recht konserativ ist und dadurch nicht immer brandaktuell, aber dafür zuverlässig (zumindest Stable, mit Testing habe ich keine Erfahrung) ist dies nicht gerade die beste Voraussetzung für aktuelle Hardware.

Ich verwende alte und neue Hardware mit Debian.
Beispiele:
- 2001er Desktop-PC von Medion mit NVIDIA AGP Grafikkarte wurde von mir bis Debian Wheezy betrieben. Alles neuer als Wheezy läuft leider mangels zu aktueller Xorg-Version nicht mehr (NVIDIA stellt keine Treiber mehr bereit und Nouveau kann kein Dual-Monitor und verursacht Grafikfehler), weswegen der Rechner bald ausgemustert werden wird. Da noch viel Zeit zu investieren macht aufgrund des Stromverbrauches eh keinen Sinn mehr und bei Windows ist mit Vista auch Schluss auf der Kiste. CentOS 6 könnte man noch bis 2020 betreiben, aber das lohnt sich einfach nicht.
- 2005er Notebook von Acer mit Intel GPU läuft mit Debian Stretch. Allerdings ist das eher ein Franken-Debian, da der Kernel ab Debian Jessie zu massiven Performanceproblemen und Kernel-Panics nach der über 6-stündigen Installation führt. Hier gehe ich bei einer Neuinstallation so vor, dass ich immer zuerst ein minimales Debian Wheezy installiere (das dauert auch nur eine Stunde), dann die Stretch Repos hinzufüge, aber den Kernel (also ein einziges Paket!!) via Apt-Pinning auf Wheezy festnagele. Danach upgrade ich alles, bis auf den Kernel, auf Debian Stretch und installiere GNOME Flashback. Erstaunlicherweise funktioniert dieses Franken-Debian sehr stabil! Bis 2022 hab ich damit auf jeden Fall meine Ruhe und evtl. läuft ja sogar noch Buster mit Wheezy-Kernel. :cool: In der Windows-Welt ist mit XP Schluss, da Vista die Grafiktreiber immer wieder deinstalliert und Windows 7 nicht am Bootlogo vorbei kommt (scheint das gleiche Verhalten zu zeigen wie Debian Jessie und neuer, also alles spielt sich wie in Zeitlupe ab). Aber auch bei diesem Rechner frage ich mich, wieso ich den überhaupt noch am Leben erhalte ... Naja, ist zum Basteln wenigstens ganz nett und zeigt, dass Debian unglaublich flexibel ist! Geschwindigkeit ist übrigens erstaunlich gut, trotz Single-Core CPU. Zum Surfen im Netz oder zum Abspielen von DVDs tatsächlich absolut ausreichend! Aber ohne uMatrix geht im Netz natürlich nix mehr, die animierte JavaScript-Werbung gibt den alten Kisten ansonsten den Rest.
- 2016er ThinkPad Yoga 460: Das Gerät habe ich zuerst mit Testing, damals Stretch, betrieben und dann auf Stable (also Stretch) belassen. Läuft ganz hervorragend (seit ca. Spätsommer 2016) und sämtliche Sensoren und Bauteile werden einwandfrei unterstützt. Dazu gehört auch der Helligkeitssensor und der Rotationssensor! Das Yoga 460 wird allerdings nicht bei mir bleiben, aber das hat nichts mit Debian zu tun, sondern mit der Hardware an sich. :)
- und noch viele weitere Geräte (X230 Tablet, Sony Vaio, Dell OptiPlex von 2006 mit Stretch und GNOME Shell, ...) ... :cool:

Grundsätzlich schaut das bei mir immer so aus, dass ich auf nagelneuer Hardware immer Testing installiere(n muss), damit die Hardware voll unterstützt wird, und ich dort dann einfach abwarte bis Testing das neue Stable wird. Aktuell wären das alle Rechner, welche mit Kaby Lake und neuer daherkommen, denn Stretch bietet nur bis Skylake volle Unterstützung der Hardware. Klar könnte man mit Kernel-Backports arbeiten, aber damit habe ich persönlich schlechte Erfahrungen gemacht, weswegen ich dann lieber auf Testing setze.

Was ich ansonsten auch immer wieder überlege ist Debian Testing auf meinem Hauptsystem einzusetzen, da ich mich um das jeden Tag kümmern kann und mich dort die frequenten Updates kaum stören sollten ...
 
Ich denke das grundsätzliche Sicherheitsproblem von yaourt ist, dass die pkgbuilds relativ einfach von anderen Leuten hinzugefuegt/veraendert werden koennen und im Gegensatz zu den offiziellen Arch-Quellen (die schon deutlich laxer getestet und kontrolliert werden als es bei Debian der Fall ist) praktisch nicht getestet werden. Das hat Vor- und Nachteile. Teilweise wird versucht das Problem dadurch zu umgehen, dass der Nutzer den pkgbuild lesen kann bevor die Software installiert wird, so kann man einen Blick darauf haben was geschehen wird. Aber wirklich sicher ist das auch nicht, wer Sicherheit haben will muesste dazu alle Patches etc. lesen, was ein kaum zu bewaeltigender Zeitaufwand ist. Wie gesagt auf Systemen wo Sicherheit ein zentraler Faktor ist sollte man yaourt nicht einsetzen.
Vorteil davon ist, dass man ohne grosse Wartezeiten seine Software relativ direkt an die Community bringen kann und teilweise ueber yaourt sehr aktiv und rege kommuniziert wird. In meinen Augen ist die Sicherheit fuer einen Desktop OK, wenn irgendwo mal Mist drin steht dann wird es frueher oder spaeter schon auffliegen, man muss dann allerdings damit leben dass es erstmal drinsteht und erst im Nachhinein gefixt wird. Deswegen yaourt immer auf eigene Gefahr. :) Diese Bedenken gelten natuerlich nicht im gleichen Masse fuer die offiziellen Arch-Quellen, da wird in meinen Augen schon ausreichend sauber gearbeitet, wuerde ich vom Sicherheitsaspekt her sogar auf einen Server einsetzen, aber aus anderen Gruenden dann wieder nicht. :)

Ganz so ist es nicht. Zwei Dinge muss man unterscheiden: AUR und yaourt.

AUR: Im Arch User Repository werden PKGBUILDS gesammelt, die nicht geprüft werden. Jeder kann dazu beitragen. Deshalb sollte man sie vor makepkg aufmerksam lesen.

yaourt: Ist ein Hilfsprogramm zum einfacheren Herunterladen und Bauen von PKGBUILDs. Davon gibt es einen ganzen Haufen: https://wiki.archlinux.org/index.php/AUR_helpers Das Problem bei yaourt ist, dass unter bestimmten Bedingungen das PKGBUILD gesourced wird, bevor der Nutzer einen Blick hinein werfen kann.
 
Gibt viele überzeugte Arch-Nutzer, welche sich nichts anderes als Arch vorstellen. Und trotzdem gibt's noch viel mehr glückliche Ubuntu-Nutzer, welche wiederum nicht viel mit Arch anfangen können
Arch bietet halt löblichere Batterielaufzeiten, vs. alle andere Distributionen.
Habe auf dem desktop-Rechner ein antergOS installiert. Auf den Notebooks antergos probiert, aber mit linux-Mint 18.2-xfce recht zufrieden, wie auch mit Linux-Lite 3.6.
Manjaro hatte nach 2 x Installationen gebockt, ist am Ende abgeschmiert, weswegen man von manjaro gänzlich weg ist. Antergos läuft dagegen recht stabil. Mit Fedora ist man nicht warm geworden, wie auch mit Sabayon. Debian-Ableger mit KDE gefällt nicht, wie auch Xubuntu, Lubuntu. Von Ubuntu ist man schon lange weg. Einzig suse wird man dem Nächst mal testen -
hatte aber in der Vergangenheit miese Akkulaufzeiten auf dem Portable mit suse-Systeme.
Zukünftig wird man sich aber mehr mit Arch befassen.
 
Unterm Strich ist doch alles Linux, nur auf verschiedene Arten gepflegt. Ich fände es toll, wenn es ein "Hauptlinux" gäbe und die anderen Distris dann lediglich Ports davon wären, mit verschiedener Software, verschiedenen Desktops etc.

Aber so aufgesplittert wie es im Moment ist, geht doch distriseitig unheimlich viel Manpower dafür drauf, in zig Distris überall das Gleiche zu pflegen. Wenn sich da alle mal zusammenschließen würden und mit dann richtig heftiger Manpower alle am gleichen Strang ziehen würden, wäre Linux sicher noch viel perfekter als es jetzt schon ist.

Der Ansatz von Microsoft, nur noch "ein" Windows zu pflegen, zielt z.B. genau in diese Richtung.

Mir ist es z.B. als Anwender völlig egal, ob ich Debian oder Arch nutze. Hauptsache es macht das was es soll.

Antergos ist das erste Linux, was ich kenne, was genau das tut.
 
Zuletzt bearbeitet:
Nein, das wäre ziemlicher Käse. Wurde bei heise schon zu Genüge diskutiert und ich verstehe den Gedankengang bis heute nicht. Wer sich nicht entscheiden kann, der nimmt Ubuntu und gut ist.

Ein paar wirr durcheinander geworfene Gedanken meinerseits, welche beim besten Willen nicht vollständig sind.
1. Gäbe es ein Volkslinux, dann würden sich die Resourcen nicht konzentrieren, sondern es gäbe weniger Entwickler als heute, denn die meisten machen das in ihrer Freizeit und arbeiten nur mit, weil ihnen eine bestimmte Distribution bzw. Nische gefällt.
2. Resourcen sind bereits heute gebündelt und durch den ständigen Wettbewerb untereinander entwickelt sich das Linux-Umfeld stetig weiter. Dennoch werden die meisten Verbesserungen innerhalb einer Distribution Upstream zum jeweiligen Paket hochgeladen und damit kocht eben nicht jeder sein eigenes Süppchen, sondern am Ende kommt jede Verbesserung wieder allen zu Gute. Beispiel sind z. B. die aktuellen Verbesserungen von Ubuntu beim GNOME-Desktop und dessen Erweiterungen, welche allesamt Upstream vorgenommen werden und damit in jeder anderen Distribution auftauchen werden!
3. Es wird nie ein derartiges LInux geben, denn Open Source funktioniert nunmal so, dass man ein Projekt forkt (abspaltet), dieses separat weiter entwickelt und dann die Verbesserungen als Patches Upstream wieder einreicht. Werden diese nicht akzeptiert, dann muss man eben seinen Fork weiter pflegen oder ohne die Patches leben. Außerdem gibt es schlichtweg keine zentrale Kontrollinstanz und jedem Menschen steht es frei mit dem Quellcode anzustellen, was er möchte. Andere können, aber müssen das Resultat ja nicht nutzen.
3.1 Wer soll denn bitteschön bestimmen, was der Standard zu sein hat?
3.1.1 Würde ein Standard diktiert, wo wäre dann noch die Konkurrenz, welche zur Verbesserung und Weiterentwicklung anspornt und verpflichtet?
4. Nicht jeder Mensch hat gleiche Bedürfnisse. Oder sind hier alle zufrieden mit einem Trabant und brauchen keinen Fortschritt und andere Automarken und Modelle? Ich mag z. B. die konservative und demokratische Entwicklung bei Debian, ebenso möchte ich ein fixed-release. Jemand anderes sucht aber genau das Gegenteil und möchte lieber sofort alle neuen Features haben und ein rolling release. Das passt einfach nicht zusammen.
5. Linux ist nur ein Kernel. Die verschiedenen Distributionen sind komplett verschiedene Betriebssysteme und haben zufällig nur eine ähnliche Software-Auswahl. Der Vorschlag eines Einheits-Linux ist ähnlich absurd wie eine Zusammenführung von Windows und macOS oder macOS und FreeBSD.
6. Eigentlich gibt es nur wenige einigermaßen große eigenständige Distributionen: Debian (und Ubuntu als kommerzielle Version), (open)SUSE, RedHat (Fedora als Entwicklungszweig, CentOS als kostenlose Community-Variante von RHEL), Solus OS, Arch Linux, Gentoo, etc.
6.1 Ubuntu MATE, Kubuntu, etc. sind alles keine eigenständigen Distributionen, sondern lediglich Installer für Ubuntu mit einer anderen Desktop-Umgebung. Sie verwenden aber allesamt das exakt selbe Repository und sind damit allesamt pures Ubuntu.

Wie schon gesagt: Wer überfordert ist, der nimmt Ubuntu und gut ist. Alle anderen können die tolle Vielfalt genießen und glücklich sein (persönlich kann ich z. B. nix mit Arch oder Fedora und auch nur wenig mit Ubuntu anfangen; ist doch toll, dass ich dann was anderes nutzen kann, oder?).
 
Die verschiedenen Distris sorgen aber auch für Probleme.

Will jemand für Windows ein Programm machen und verteilen, packt er es in eine setup.exe, welche man dann einfach nur noch installieren braucht, und gut ist. Läuft so gut wie auf jedem Windows der letzten 15 Jahre.

Will ich auch nur etwas (z.B. Seamonkey) für die aktuellen Linuxe bereitstellen, gibt es keine einheitliche setup.exe, sondern alle möglichen Wege.

Das ist doch für die Software-Hersteller als auch für mich als Linux-DAU wirklich nicht optimal gelöst, da nie alles in den jeweiligen Repositories drin ist, was man will.

Von daher wäre eine Linux-Vereinheitlichung zumindest im diesem Bereich ganz nett.
 
Zuletzt bearbeitet:
Will jemand für Windows ein Programm machen und verteilen, packt er es in eine setup.exe, welche man dann einfach nur noch installieren braucht, und gut ist. Läuft so gut wie auf jedem Windows der letzten 15 Jahre.

Will jemand ein Programm für z. B. Debian erstellen, dann gibt er dafür den Quellcode frei und bittet einen Debian-Maintainer das Paket aufzunehmen (bzw. stellt im Idealfall dafür jemanden bereit). Dabei wird durch den Maintainer dann sichergestellt, dass der Quellcode mit der Binärdatei übereinstimmt, keine Schadsoftware dabei ist und, dass alle Abhängigkeiten erfüllt sind und sich das Programm problemlos installieren lässt. Ebenso landet ein Programm aus Debian auch automatisch in Ubuntu, da Ubuntu sein System alle 6 Monate von Debian abspaltet und damit auch dessen Pakete übernimmt (daher arbeiten auch viele Ubuntu-Entwickler direkt am Debian-Repository, da das dann Ubuntu und Debian zu Gute kommt). Komfortabler geht's doch nicht?!

Der Entwickler muss sich also überhaupt nicht um die Paketierung kümmern, denn das übernehmen die Distributionen.

Will ich auch nur etwas (z.B. Seamonkey) für die aktuellen Linuxe bereitstellen, gibt es keine einheitliche setup.exe, sondern alle möglichen Wege.

Korrekter Weg: Das Programm für die jeweilige Distribution paketieren, sodass es sich jeder Nutzer einfach über das Standard-Repository herunterladen kann.

Wenn ich für Android ein Programm veröffentliche, dann ist das ja nicht anders. Im Idealfall will man das nicht nur im Google Play Store, sondern auch bei Amazon und F-Droid haben. Das erfordert auch tlw. Anpassungen.

Das ist doch für die Software-Hersteller

Wie gesagt: Ein Problem haben nur closed source Programme. Bei quelloffener Software übernehmen es die Maintainer einer jeden Distribution.

als auch für mich als Linux-DAU wirklich nicht optimal gelöst, da nie alles in den jeweiligen Repositories drin ist, was man will.

Dann fügt man seinem System eben noch ein oder zwei andere Repositories hinzu. Ich brauche unter Debian nur ein einziges externes Repository und das ist für den Messenger Riot. Alles andere ist in stable und stable-backports enthalten.

Ansonsten sollte man evtl. einen Packaging Request erstellen, damit das Programm aufgenommen wird. Problem: Häufig fehlt es den Distris an Paketbetreuern, weswegen sie ohne freiwillige Unterstützung nicht noch mehr Pakete aufnehmen können. Ebenso verstoßen manche Pakete gegen die Packaging Guidelines mancher Distributionen.

Von daher wäre eine Linux-Vereinheitlichung zumindest im diesem Bereich ganz nett.

Hört man immer wieder und das funktioniert immer noch nicht. Auf welchen Standard soll man sich denn einigen? DEB mit Apt? RPM mit Apt? RPM mit yum? RPM mit Urpmi? RPM mit zypper?
Das sind einfach unterschiedliche Ansätze mit unterschiedlichen Vor- und Nachteilen. Und selbst wenn man einen Standard hätte, was soll das denn bringen? Die Pakete müssen trotzdem an die einzelnen Versionen einer jeden Distribution angepasst werden, denn die Abhängigkeiten sind bei Ubuntu 14.04 ganz anders als bei Ubuntu 16.04 oder 17.10. Und sowas übernimmt eben im Normfall der Maintainer der Distribution.
Es ist einfach so, dass jede Linux-Distribution ein eigenständiges Betriebssystem ist. BSD-Anwendungen laufen auch nicht ohne Anpassungen unter macOS. Hat sich da schon mal jemand beschwert?
Wenn einem sowas zu viel ist, dann besteht auch die Möglichkeit alle Abhängigkeiten in die *.deb bzw. *.rpm Datei zu packen. Dann braucht man nur zwei Pakete erstellen, denn eine RPM ohne Abhängigkeiten kann ich unter openSUSE, Fedora, Mageia usw. installieren, ebenso eine DEB ohne Abhängigkeiten unter Debian, Ubuntu, usw.. Das ist zwar sehr unsicher und wartungsintensiv, aber möglich. Das gleicht dann eben dem "Windows way of life" ...

Eine weitere Möglichkeit ist z. B. der openSUSE Build Service. Der bietet die Option Pakete für eine ganze Hand voll Distributionen relativ automatisch bauen zu lassen. Am Ende bekommt man ein externes Repository und das kann der Nutzer dann einbinden.
Ebenso gibt es seit vielen Jahren die Möglichkeit AppImages bereitzustellen. Diese beinhalten ebenso alle Abhängigkeiten und müssen nicht installiert werden. Neuere Konzepte zur Installation sind Flatpak und Snap.

Alle Alternativen zum klassischen Repository haben aber einen erheblichen Nachteil: Die Pakete kommen vom Entwickler und es kann nicht nachvollzogen werden, ob bei einem quelloffenen Programm der Quellcode auch mit der ausgelieferten Binärdatei übereinstimmt. Diese Garantie habe ich bei mittlerweile fast allen klassischen Distributionen (und bei F-Droid unter Android), da diese das Konzept der reproduzierbaren Builds umgesetzt haben. Für closed source Software ist das aber natürlich egal und dafür gibt's eigentlich mehr als genug Möglichkeiten zur Auslieferung ...
Aber vermutlich liegt das Problem sowieso eher darin, dass manche Leute/Entwickler mit Vielfalt überfordert sind und daher unbedingt alles diktiert haben wollen ... Wo kämen wir denn dahin ... Demokratie, mehr als ein Auto-Modell, kein Volksnotebook, kein Volksbetriebssystem ... Tzzz ... Vielfalt ... Informationen ... Entscheidungen ... mündiger Bürger ... Brrr ...

PS: Für solche Leute kann ich immer wieder Ubuntu empfehlen! Ich kenne kein Programm, welches nicht für Ubuntu paketiert ist (ob via ext. Repository oder im Hauptrepo) und die Nutzerbasis ist auch im deutschsprachigen Raum riesig. Für alle nicht überforderten: Distrowatch :thumbup:
 
@syscrh: vielen Dank für deine ausführlichen Antworten. Für einen Linux-Anfänger sind deine Zusammenfassungen Gold wert. So verstehe ich vieles besser.

Danke!

- - - Beitrag zusammengeführt - - -

Habe jetzt mal eine aktuelle Debian-Live-ISO mit Cinnamon-Desktop ausprobiert... und was ist:

- keine Seamonkey-Suite
- kein Yandex-Browser

im Repository, nur als Beispiel... und nun?

Wenn die Installationen von außerhalb eines Repositories so unsicher sind, was mache ich dann?

Bei Antergos ist alles da.

Seamonkey und Yandex sind nun echt keine exotischen Programme.
 
Ich möchte gerne Windows in eine virtuelle Maschine packen und unter Antergos starten, aber Virtualbox startet nicht, sondern bringt nur eine Fehlermeldung:

"Kernel driver not installed (rc=-1908)
The VirtualBox Linux kernel driver (vboxdrv) is either not loaded or there is a permission problem with /dev/vboxdrv. Please reinstall the kernel module by executing
'/sbin/vboxconfig'
as root.
where: suplibOsInit what: 3 VERR_VM_DRIVER_NOT_INSTALLED (-1908) - The support driver is not installed. On linux, open returned ENOENT. "

Da bin ich komplett aufgeschmisssen und komme nicht weiter. Gebe ich den genannten Befehl per Terminal und sudo ein, findet er den Befehl nicht...

Hat da jemand eine Lösung?
 
Hast Du Secureboot im BIOS eingeschaltet? Das erzeugte bei einigen aktuellen Distributionen eine ähnliche Fehlermeldung, da dann alle Treiber zusätzlich signiert sein müssen.
Nach Abschalten von Secureboot lief Virtualbox dann wieder.
 
Also unter Debian muss ich noch linux-headers-amd64 installieren, ansonsten bekomme ich ähnliche Fehlermeldungen. Hast Du dazu schon einen Blick ins ArchWiki geworfen?
 
Secure-boot ist disabled, linux-headers habe ich auch schon nachinstalliert.

Google wirft zu dem Problem einiges aus, aber keine für mich gangbare Lösung. Ich komme einfach nicht weiter.

-edit-

Jetzt geht es. Musste scheinbar nach der Installation von den linux-headers neustarten, was ich noch nicht getan hatte.
 
Du brauchst die linux-headers des laufenden Kernels. Wurde dieser seit dem letzten Boot aktualiisert, läuft noch die alte Version, aber die Header-Dateien sind schon neuer.
 
Ich würde gerne das Image der virtuellen Maschine auf sda3 (unter Windows Laufwerk D: ) verschieben, aber unter /dev wird mir kein sda3 angezeigt, unter gparted schon?

Genauso würde ich gerne das Windows-ISO von sda3 einbinden, geht aber genausowenig.

Man, ist Linux kompliziert, sobald man eine Kleinigkeit von Hand machen muss...............
 
NAME FSTYPE LABEL UUID MOUNTPOINT

sda
sda1 ntfs System D49A07BF9A079CDC
sda2 ext4 Linux 86f7eba4-a4b8-426a-a931-a0885d2b0bde /
sda3 ntfs Daten 9CC200F8C200D882

sdb
sdb1 ntfs Daten HDD DA94AE1994ADF861 /run/media/xy/Daten


Wenn ich das richtig erkenne, ist meine USB 3.0-HDD als sdb richtig eingebunden, die interne SSD von meinem Thinkcentre nicht.

-edit-

Habe die VM-Image-Datei und das Windows 7-ISO auf sda3 stellen können, nachdem ich im Dateimanager Nemo die Partition gemountet habe.

Kann man das automatisch machen lassen, auto-mount von sda3 unter Antergos?
 
Zuletzt bearbeitet:
Antergos ist wirklich toll, gefällt mir immer besser. Nutze es seit einigen Monaten als Produktivsystem. VMs gehen nun auch, auto-mount habe ich auch hinbekommen.

Nun habe ich Windows 10 Fall Update installiert, nur um es mal auszuprobieren, und ich komme nicht mehr in Linux rein, da das Bootmenü nur noch Windows 7 und 10 zur Auswahl anbietet, aber nicht mein installierte Antergos.

Wie kann ich das reparieren?


-edit-

habe mit Rescatux Grub wiederhergestellt... ist aber jetzt ganz lustig: kann von Grub aus entweder Antergos oder den Windows-Bootmanager starten. Bei letzterem kann ich dann in einem zweiten Schritt zwischen Win 7 oder 10 auswählen.

Wäre ja schön, wenn man alle drei Systeme direkt in einem Bootmanager hätte...
 
Zuletzt bearbeitet:
  • ok1.de
  • ok2.de
  • thinkstore24.de
  • Preiswerte-IT - Gebrauchte Lenovo Notebooks kaufen

Werbung

Zurück
Oben