News Fedora 32: Distribution auf Basis von Linux 5.6 und Gnome 3.36

AlphaKaninchen schrieb:
@Skidrow Hauptsächlich um es einfacher zu haben wenn eines der beiden Systeme Probleme macht, da das neuinstallieren von Windows einem den Dual Boot zerstört und den Windows Bootloader zu bekommen wenn Grub Probleme macht ist auch nicht so einfach.
Und ich weiß auch nicht wie es sich mit Upgrades von Windows verhält...

Einfach ein Linux Bootmedium mit chroot in die Linux installation und Grub wieder über den MBR von Windows drüber bügeln lassen. Dauert ca. 10 Minuten wenn man kein Bootmedium erstellen muss. Ich habe es bisher auch noch nicht erlebt, dass Windows Grub oder einen anderen Bootloader killt nach einem Update.

Windows überschreibt den Bootsektor nur bei Installation, weswegen man im Falle von Dual Boot Windows zuerst installieren sollte.
 
aRkedos schrieb:
Windows überschreibt den Bootsektor nur bei Installation, weswegen man im Falle von Dual Boot Windows zuerst installieren sollte.

Das ist mir mal so bei einem Dualbootsystem passiert. War ein großes Windows Update, was im Endeffekt ja eine Neuinstallation ist, zack Grub weg...
 
aRkedos schrieb:
Einfach ein Linux Bootmedium mit chroot in die Linux installation und Grub wieder über den MBR von Windows drüber bügeln lassen. Dauert ca. 10 Minuten wenn man kein Bootmedium erstellen muss. Ich habe es bisher auch noch nicht erlebt, dass Windows Grub oder einen anderen Bootloader killt nach einem Update.
对 我知道
Nur wollen sie das ernsthaft jemandem erklären der fragt wie er im Installer einen Dual Boot auswählt?
 
  • Gefällt mir
Reaktionen: Iapetos
DrCox1911 schrieb:
Das kommt mir als Spieler natürlich mehr als entgegen und gegenüber Manjaro ging mein System auch noch nie bei einem Update kaputt, installiere die immer blind und es klappt immer.
Das gefiel mir damals (bin mit Fedora 18 angefangen) auch sehr gut. Während ich mir debian beim Upgrade von debian 4 auf debian 5 und debian 5 auf debian 6 jeweils geschrottet hatte und diese Erfahrung auch bei ubuntu (weiß nicht mehr welche Versionen es damals waren und ob es ein LTS zu non-LTS war oder non-LTS zu non-LTS war, ich hatte es zeitgleich zu debian 5, aber auf einem anderen System, installiert gehabt), lief das Upgrade von Fedora 18 auf 19 so durch. Ich hatte dann aber direkt trotzdem noch eine frische Installation gemacht und diese Installation machte das Upgrade von Fedora 19 bis einschließlich Fedora 31 jedes mal problemlos mit. Also von den Upgrades her kann ich Fedora ebenfalls wärmstens empfehlen.

Etwas Offtopic (und längerer Text):

Allerdings habe ich Fedora 31 im März auf meinem 6710B ersetzt, weil ich da wieder was verkonfiguriert hatte. Ich vermute im Zusammenhang mit dem atomic Repo für openVAS, denn ich wollte dort mal OpenVAS installieren um mein Heimnetzwerk mal zu scannen. Dazu wollte ich erst blackarch probieren, weil ich dachte, ist arch basiert und hat daher die neuesten Versionen von openVAS (bzw. greenbone security scanner, wie erinzwischen heißt) integriert. Aber das wollte auch nicht. Fedora habe dann gesehen, dass Fedora inzwischen auch sogar aktuellere Versionen von OpenVAS hatte als blackarch, aber das konnte ich mit mehreren USB Sticks und diversen USB Tools (Fedora Image Writer, Rufus, WinSetupFromUSB, balena Etcher und ROSA Image Writer) nicht installieren. Daher ist auf dem Laptop nun ein Kali Linux nur für OpenVAS. Allerdings würde ich hier dann auch jedem raten, es unter Fedora zu probieren, sofern man Fedora eh gerade installiert hat.

Im Februar habe ich dann auf dem M450 (Windows 7 durch Linux ersetzt, weil ich ja nun den Dell 390DT mit Windows 10 habe und ich einen alten Rechner, der noch geht, nicht einfach verschrotte) nach mehreren Versuchen Mageia installiert. Lief auch wunderbar, booten dauerte nur länger und schmiss immer Fehler. Ich vermutete, dass ich eine oder 2 kaputte HDDs habe und wollte schon um installieren auf die 2. HDD, da Mageia immer Fehler wegen Dateisystem beim booten anzeigte. gsmartcontrol sagte mir aber, dass die bereits von Mageia verwendete HDD heile ist, also habe ich nur die andere, nicht benutzte kaputte HDD ausgebaut. Mageia hat da wieder eher was von debian, in dem es selten Programm Updates gibt. Aber die HW Erkennung bei der Installation gefiel mir sehr gut, weil die sofort meine GTX 660 erkannte und mir dann direkt anboot die NVIDIA Treiber zu installieren. Aber damit und den nachinstallierten CUDA Toolkit ging CUDA nicht und die FileSystem Fehler beim booten nervten auch, weswegen ich im April dann auf arch gewechselt bin. Unter arch läuft CUDA einwandfrei. Und es bootet wesentlich schneller. Während Mageia gefühlt so träge beim Booten ist wie Windows (und Fedora zumindest bei einem Server auch nicht viel schneller ist), ist arch sogar bei Systemen ohne SSD "rasend" schnell. Also der Bootvorgang dauert gefühlt nicht mal 1 Minute, während Mageia und Fedora gefühlt 3 bis 5 Minuten brauchten, bis der Anmeldebildschirm gezeigt wurde.
 
Zuletzt bearbeitet: (ohne HDD => ohne SSD, Klammern etwas umsortiert im letzten Abschnitt.)
disco dogg schrieb:
Was mich aber immer wieder nervt ist DNF, wenn ich mal an einem System mit APT bin frag ich mich immer nur wie DNF so lahmarschig sein kann.
Das stimmt wohl. Der Unterschied APT zu DNF bezüglich Geschwindigkeit ist schon extrem. Zum Glück brauche ich es bei Fedora nicht so oft.
 
BrollyLSSJ schrieb:
Während Mageia gefühlt so träge ist wie Windows und Fedora (zumindest bei einem Server auch nicht viel schneller ist), ist arch sogar bei Systemen ohne HDD "rasend" schnell. Also der Bootvorgang dauert gefühlt nicht mal 1 Minute, während Mageia und Fedora gefühlt 3 bis 5 Minuten brauchten, bis der Anmeldebildschirm gezeigt wurde.
Fedora 32 ist bei mir am Tablet in Sachen speed selbst dem iPad Pro vorraus...
 
@AlphaKaninchen
Ich bezog mich damit (träge) nur auf den Boot Vorgang auf ein und der selben Hardware, abgesehen von Fedora, was auf einen anderen Laptop war (wo jetzt Kali Linux drauf ist) und eben einen ProLiant DL380 G7 Server installiert ist. Ich habe daher mal die Klammern in dem zitierten Absatz anders gesetzt und das "ohne HDD" durch "ohne SSD" ersetzt, sowie ein "beim Booten" nach "träge" eingefügt. Ich meinte damit nicht die Bedienbarkeit. Der Desktop ist allgemein flüssig bedienbar gewesen bei Fedora, arch und Mageia.

Falls dein Tablet-Vergleich immer noch gilt und sich somit auf dem Boot bezog, verstehe ich den Vergleich nicht.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
Ne bezog sich auf die nutzung Booten dauert eh wegen Luks und braucht die USB Tastatur etc...
Wobei Einschalter drücken -> 5sec -> Passwort für Luks -> 5sec -> User Passwort -> 2sec -Desktop, sofort nutzbar schon ok ist.
Da ich aber von allem was keinen Ladebalken hat sofortige Reaktion erwarte, empfinde ich es schon als langsam
 
Zuletzt bearbeitet:
OK, LUKS nutze ich nicht. Habe die Systeme bisher noch immer unverschlüsselt eingerichtet. Tastatur und Maus ist am PC und Schlepptop identisch, da ich die per KVM Switch (USB und VGA Kabel) angebunden habe. Beim Server (den DL380 G7) nutze ich allerdings auch eine USB Tastatur und Maus (direkt angeschlossen), ist aber an einem ganz anderen Ort (eben im Rechenzentrum).
 
Mal kurze, enttäuschte Anmerkung zur exFAT-Unterstützung: Ich habe gerade meinen Desktop von Fedora 31 Workstation auf 32 aktualisiert und mal probiert, ob ich meinen exFAT-USB-Stick jetzt benutzen kann. Direkt nach dem Upgrade gabs erstmal nichts, nichtmal eine Auflistung in den Geräten. Ich hab dann mal in den dnf-Quellen gesucht und unter exfat* nur die exfat-utils in RPM Fusion, also nicht in den offiziellen Quellen, gefunden. Nachdem ich diese dann installiert hatte, wurde mir der USB-Stick immerhin angezeigt und er taucht auch in Disks auf, aber einhängen geht immernoch nicht, weil: "unknown filesystem: exfat". Und irgendwie gibts in den 32er RPM Fusion Quellen kein exfat-fuse mehr, weil die wahrscheinlich auch denken, dass Fedora mit dem 5.6er Kernel doch wohl die Dateisysteme, die der Kernel selbst offiziell und absolut freie-GPL-software-mäßig unterstützt, auch unterstützen wird. Aber Pustekuchen! Mich erinnert das gerade an die Zicken, die Fedora seinerzeit mit Reiser4 angestellt hatte - aber das Dateisystem war ja auch nicht im Vanilla-Kernel, exFAT ist im Vanilla-Kernel.

Also für mich ist exFAT-Unterstützung jetzt, wo es als freie Software im Linuxkernel ist, so essentiell auch, weil imho FAT32 ausgerottet gehört, dass ich überlege, nur deswegen die Distro zu wechseln.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
Schade schade - also könnte man alle News zu Linux-Distros der letzten Monate mal überarbeiten und übnerall den Hinweis auf exFAT streichen.

An Fedora 32 stört mich jetzt aber immernoch, dass exfat-fuse, der Samsung-Treiber, nicht mehr in RPM Fusion ist.

Update
Ich hab jetzt das Sternchen bei der Paketsuche auch vor exfat gesetzt und siehe da, der Samsung-Treiber ist in RPM Fusion. Er wurde nur, wie das openSuse vorgemacht hat, als fuse-exfat statt exfat-fuse eingepflegt. Jetzt läufts wieder wie vor dem Upgrade und ich bleibe bei Fedora.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Iapetos und AlphaKaninchen
Zurück
Oben