FAQ: Windows -> GNU/Linux - Umstieg, Einstieg, Aufstieg - Seite 77

Seite 77 von 82 - Forum: Linux and other OS auf overclockers.at

URL: https://www.overclockers.at/linux/faq-windows-gnu-linux-umstieg-einstieg-aufstieg_127618/page_77 - zur Vollversion wechseln!

mit strg+alt+F2 auf ein anderes terminal wechseln und den plattenplatz freiräumen sowie apt upgrade nochmal ausführen?
alternativ im grub eine terminal only session starten
debian ist halt keine anfänger distro, apt schreibt ja sogar hin wieviel plattenplatz es verbraucht...bei debian muss man auch damit rechnen mal was auf dem terminal zu machen...

ich werds nachher nochmal probieren, aber eins vorweg:
das user-verzeichnis liegt bereits auf einem anderen laufwerk.
dort etwas zu löschen löst das problem nicht.

Apt lädt die .deb Archive standardmäßig nach /var/cache/apt/archives herunter, deine /home Partition hat demgemäß nix damit zu tun.

Nach einem halben Jahr wird die Flut an Paketen noch nicht so arg sein, und du vermutlich generell eher wenig Speicherplatz frei haben. Oder du hast irgendein 3rd Party Repo aktiv, das sehr große Update-Archive ausliefert.

So oder so würde ich ein Live-System booten und die Partition entsprechend vergrößern, wenn du kurzfristig reinbooten willst kannst du natürlich aus /var/cache Inhalte entfernen.

Alle halben Jahre booten und drauf schimpfen wird jedoch vermutlich so oder so nicht auf die beste Userexperience hinauslaufen

(Vom Linux noob für den Linux noob)
Nachdem ich unter Linux fatigue gelitten hatte (distros asuprobieren... *kotz*), hab ich in letzter Zeit wieder etwas herumprobiert, diesmal mit Bazzite.
Bisher für mich das Beste vom Gefühl, Useability und Gesamteindruck. (also nach Ubuntu bzw gleichauf)

Hab aber noch nichts komplexeres probiert wie hypervisor +vm oder hibernation usw, da wirds dann immer kritisch. Aber es stimmt mich etwas hoffnungvoll als alternative für Gaming.

Zitat aus einem Post von Rogaahl

Ein neues open source RAW Fotobearbeitungs Programm, von einem 18-jährigen Australier. Ist erst ein paar Wochen alt, dafür hat es aber schon einen sehr guten Funktionsumfang, ist effizient und sehr slik/modern.

GitHub - CyberTimon/RapidRAW: A beautiful, non-destructive, and GPU-accelerated RAW image editor built with performance in mind.

A beautiful, non-destructive, and GPU-accelerated RAW image editor built with performance in mind. - CyberTimon/RapidRAW

Link: github.com

Ich hab was vor, dass für mich nicht so alltäglich ist.
Vielleicht kann einer der Linux Sysadmin Veteranen hier mir etwas Input geben ob mein Plan erfolgsversprechend klingt.

Ausgangsszenario:
"Entwicklungsserver" der immer mehr daily Services hostet soll von einer sehr gebrauchten alten SSD auf zwei neue in Raid 1 übersiedeln.

Mein Plan:

• Neue SSDs einbauen
• Von einer Live ISO booten
• Die neuen SSDs partitionieren, mit mdadm das Raid erstellen und dann formatieren
• Mit rsync von der alten SSD auf das neue Raid "kopieren"
• In das neue Filesystem am Raid chrooten
• Dort fstab, mdadm config, grub und initramfs updaten
• Reboot & pray

Klingt mir so, als koennte das klappen Bei rsync musst du aufpassen, dass du auch wirklich ALLE Metadaten richtig ins neue fs mitnimmst, also mit `rsync --numeric-ids --archive --acls --crtimes --hard-links --xattrs /your/old/root/. /your/new/root/.` wuerde ich starten. So sollten sogar file-based capabilities mitgenommen werden, da die auch in einem xattr-Namespace liegen. Manche arbeiten bei so einer Migration auch mit partimage bzw. fsarchiver, aber ich finde die chroot-rsync-Variante eigentlich flexibler

Wenn du ein EFI-System hast (wovon ich ausgehen wuerde) musst du auch noch schauen, wie du das mit der ESP-Redundanz und deinem RAID1 loest. Die alte SSD wuerde ich vor dem Reboot-Versuch ausbauen, sonst merkt sich deine Firmware vmtl. via NVRAM, dass sie die ESP und den Bootloader von dort laden soll, und dann ist alles eher schlecht.

Wäre es evtl an der Zeit an ein anderes, resilienteres Setup zu denken?
Je nach Services auf Virtualisierung oder Containerisierung gehen?
Damit ist das Backup und eine rasche Wiederherstellung leichter (bzw durch den Prozess schon vorbereitet)

wie löst man das in dem fall eigentlich mit grub? auf beiden ssds installieren? schon oder? weil wenn eine ausfällt sollte der Server ja noch über die andere booten? und in der bootreihenfolge beide hintereinander angeben...

Sonst wäre mein Ansatz gleich wie deiner. Würde den Ausfall auch mal testen

edit: inwiefern hilft virtualisierung? für das OS vom hypervisor brauchst ja auch Redundanz... also würde virtualisierung nur helfen wenn man 2 server nimmt. Was aber kostenmäßig wieder eine ganz andere Hausnummer is... das selbe mit container wost dann sowas wie k3s brauchst (und know how)
edit2: klar kannst auch das hausnummer proxmox OS auf ein software RAID installieren... falls das gemeint war. Aber da gewinnst ja keine zusätzliche Redundanz. Und wir wissen ja gar ned um was es geht. also schwierig da gleich zu sagen Virtualisierung wäre das richtige...

Ich hab mich eine Weile mit der Frage der ESP-Redundanz beschaeftigt und im Zuge dessen fuer den Debian-Installer Patches beigesteuert, die ab Forky (Debian 14) zumindest mal mit preseed-Installationen eine der denk- und machbaren Varianten dafuer ermoeglichen. Imo ist das ganze ein tragischer Defekt der EFI-Spec, wo man dieses Problem einfach via "irgendeine Hardware-RAID-Kacke wird es schon fuer uns regeln, YOLO" "geloest" hat.

In der Praxis muss man schauen, dass alle ESPs im System zu jeder Zeit inhaltsgleich ist. Proxmox hat fuer diesen Zweck z. B. das proxmox-boot-tool im Lieferumfang; mein Ansatz fuer Debian ist (zugegeben ein bissi out of Spec, aber es hat noch auf jeder Plattform, die ich versucht habe, funktioniert) ein mdadm-RAID1 mit einem Superblock-Layout, das fuer die Firmware "unsichtbar" bleibt.

In allen Faellen hat man ggf. mit der Problematik zu kaempfen, dass ein OS, das sich nicht an den einen verwendeten Mechanismus zum Syncen aller ESP-Dateisysteme haelt, den Bootvorgang empfindlich (zer)stoeren kann. Das wird uns wohl bis in alle Ewigkeit/bis zur Abloese von UEFI erhalten bleiben.

ok versteh, das is PITA. und auf legacy boot gehen? falls möglich?

Mit BIOS/MBR-Boot hat man dieses Problem in der tat nicht, aber man verliert in der Praxis durch das Aktivieren des CSM immer mehr Features, die man tendenziell haben moechte - insb. im Server - wie z. B. PCIe-Passthru.


Was mir recht lange nach der Einfuehrung von EFI und tatsaechlichem Booten davon nicht klar war:

"GRUB installieren" mit BIOS/MBR bedeutet, dass grub seinen stage0-Loader in den ersten Sektor der ersten (bzw. einfach aller, weil es keinen Unterschied macht) Disk(s) im System schreibt, wo ein bisschen x86-Machine-Code dafuer sorgt, dass die spaeteren Stages auf der selben Disk in /boot auf quasi beliebigen Dateisystemen (GRUB muss sie unterstuetzen, aber die Firmware muss nix davon wissen - und GRUB versteht auch sowas wie ext4 md RAID6) gefunden werden kann. Wenn man also diese 448 Byte auf die Disks bringt, ist alles relativ leiwand, und RAID-Metadaten und Dateisysteme sind davon unbeeindruckt.

"GRUB installieren" auf einem EFI-System bedeutet, mind. eine EFI-Binary (grub als PE fuers EFI-Target kompiliert) an einen (optional "magischen" Default-)Pfad auf der ESP zu kopieren, und, von gewissen Faktoren abhaengend, auch noch eine Konfigurationsdatei im Binary zu embedden oder mit auf die ESP zu legen. Die ESP (EFI System Partition) ist eine Partition in der GUID Partition Table, die eine spezielle, reservierte Unique ID hat, und die (meistens - aber das ist kein Muss) FAT32 formatiert ist. Das ist alles. Wenn man dann mag, kann man dann auch noch (z. B. via efibootmgr) im NVRAM der Firmware festlegen, dass es bitte zu diesem Loader eine Boot-ID geben soll, und dass bzw. ob die Default-Boot-ID werden soll - diese Information liegt aber nicht innerhalb der ESP, sondern afaiui meistens (immer?) in ein paar Bloecken des SPI-NAND, die u. A. auch die Firmware des Motherboards selber beherbergen.

Vielleicht ist das ja fuer den einen oder anderen Mitlesenden hier auch 2026 noch eine neue Information

Danke für die Infos und deine Ausführungen.
Ich habe mich bisher immer davor gedrückt von "Multidisk" zu booten.

Ich muss mir dass mal unter FreeBSD mit Root on ZFS und verschiedene Boot environments ansehen.

HDMI 2.1 mit amdgpu ist inzwischen fast vollständig von zwei Leuten via reverse Engineering implementiert.

Stark!

Leider muss ich noch warten.

Zitat

- Untested DCN generations include DCN 3.1 - DCN 3.6. DCN 3.0 (RX 6000 series) has not been implemented yet, but I believe it should be pretty similar to the newer DCNs.

overclockers.at v4.thecommunity
© all rights reserved by overclockers.at 2000-2026