Der GNU/Linux-Thread

[oldfield2283]

Schreibt das Script eventuell auf stderr statt stdout?

Ich hab' keinen Dunst ... das Script startet und gibt in der bash aus. Ist soweit ja richtig, ich hätte es nur gerne in einer Datei. die ich später auswerten kann.

./script.py > datei.txt 2>&1

EDIT: oder ./script.py 2>&1 > datei.txt, hab gerade die richtige Reihenfolge nicht im Kopf.

Bin jetzt nur der Hobby-Linuxer und habe mich selbst auch schon böse reingelegt, wenn ich Sachen aus der Windows-Welt einfach so übetrage. Dabei mache ich eigentlich sogar sehr viel und gerne in der Konsole und mit batches. Dein doppeltes > habe ich aber nicht verstanden. Meine Programme (egal ob nun Python oder was anderes) reagieren gut auf < und > oder sogar | wenn es eine ganze lange Liste mit Weitergaben ist. Aber wie gesagt, dein >&1 verstehe ich nicht so ganz, ist das ein Formatierungsding hier?

Ob erst Parameter2 und dann die Umleitung oder umgekehrt , ist m.M. nach egal ich würde es aber so schreiben (erst die Parm)

Werde ich morgen mal probieren, für heute habe ich die Himbeere schlafen gelegt ...

hoffentlich liest das hier die Himbeere im Forum nicht und beschwert sich....

[Jack]

Aber wie gesagt, dein >&1 verstehe ich nicht so ganz, ist das ein Formatierungsding hier?

Ob erst Parameter2 und dann die Umleitung oder umgekehrt , ist m.M. nach egal ich würde es aber so schreiben (erst die Parm)

Mit dem & werden File Descriptors bezeichnet. &1 also für Standardausgabe.
und mit >&1 wird die entsprechende Ausgabe umgelenkt.
Und die Reihenfolge ist wichtig (s.o.)

[Versingled]

Werde ich morgen mal probieren, für heute habe ich die Himbeere schlafen gelegt ...

hoffentlich liest das hier die Himbeere im Forum nicht und beschwert sich....

[uhu72]

Ich habe Probleme mit globbing im bash script. Es wird immer ein Syntax Error rausgeschmissen.
Mein letzter Stand nach stundenlanger Recherche, ist, es geht nicht, weil der Parser schlicht nicht die extended globbing features kennt.
Konkret geht es um ein derartiges Konstrukt:

Code: Alles auswählen

rm blabla/!(*.CR?)

[The Poet]

Ich habe Probleme mit globbing im bash script. Es wird immer ein Syntax Error rausgeschmissen.
Mein letzter Stand nach stundenlanger Recherche, ist, es geht nicht, weil der Parser schlicht nicht die extended globbing features kennt.
Konkret geht es um ein derartiges Konstrukt:

Code: Alles auswählen

rm blabla/!(*.CR?)

Ok, du willst offenbar alles löschen, was das Pattern "*.CR?" nicht matched?

Bei mir (irgendeine alte Linux Mint-Kiste als Testbed) auf der Konsole funzte das ohne Probleme, hab ich gerade getestet - dann hab ich's aber in ein bash-file geschrieben, und bekam den Fehler

./test.sh: line 3: syntax error near unexpected token `('

Ich nehme an, das ist auch deine Fehlermeldung...


Ich hab mal geschaut, ob extglob an ist... und auf der Konsole war es das. Wenn der neue bash-Prozess startet, der das Script ausführt, ist es aber offenbar nicht an:

Konsole:

Code: Alles auswählen

shopt | grep "extglob"

extglob on

Script:

Code: Alles auswählen

#!/bin/bash

shopt | grep "extglob"

... ausgeführt, Output:
extglob off



Als ich deine "rm"-Zeile in ein Script geschrieben habe, und darüber noch die Zeile

Code: Alles auswählen

shopt -s extglob

(also ext globbing angeschaltet hab), ging es auch im Script :). Probier mal.



edit: Falls das immer noch nicht hilft, weil du irgendwelche functions im bash-Script definiert hast (und extglob zu "spät" im Script anschaltest), vielleicht bringt dich dieser SO-Post weiter.

[uhu72]

Danke, ich melde mich falls es neue Erkenntnisse gibt.

Code: Alles auswählen

shpot -s extglob

direkt darüber funktioniert nicht, dass hatte ich auch schon probiert ...

[The Poet]

Dann poste doch mal das ganze Script und/oder ein minimal example, das den Fehler auslöst...

OS + bash Version ist sicher auch hilfreich, falls hier jemand noch helfen möchte, um das Problem einzukreisen.

[uhu72]

Jetzt läuft's im Test.
Ich habe die

Code: Alles auswählen

shopt -s extglob

radikal an den Anfang gesetzt. Man muss die Option rechtzeitig setzen, sonst schnallt der parser das nicht. In meinem Fall war das Test-script zwar sehr klein, aber dennoch in einer großen if-Schleife.
Im Nachhinein klar, aber man ist erst mal so sehr auf das Detail fixiert, dass man das drumherum aus dem Blick verliert.

Vielen Dank für den entscheidenden Hinweis.

[The Poet]

Jetzt läuft's im Test.

[...]

Vielen Dank für den entscheidenden Hinweis.

[Mit müden Augen]

Wer Ubuntu benutzt sollte dringend Updates (vom Kernel) machen, u.a. RCE wenn ich richtig gesehen habe. https://ubuntu.com/security/notices

[oldfield2283]

Öhm nun muß ich doch mal fragen... Kennt sich jemand mit Multi-Boot Problemchen aus, Grub usw.

Ich hatte bis letzte Woche eine Installation Win 7 / Linux Mint 17.2 auf einem Uralt-Rechner. Der hatte 2 Platten, das Boot-Menue war auf sdb und ein Verweis zum Windows auf sda. Ob Windows noch alleine gebootet hätte, weiß ich gar nicht mal so, weil ich es nicht mehr probieren konnte mit Abziehen der 2.Platte. Außerdem hatte der PC mehrere Macken und sollte verschrottet werden - solange wie ich ihn anhatte, ging er aber noch wie Bienchen.

Jetzt mein Problem. Ich dachte, ich ziehe die beiden Festplatten einfach um in einen Not-PC (zu klein und zu alt ja, aber als Kopierstation mit 4GB noch zu gebrauchen), melde sie im Bios in der richtigen Reihenfolge an (sdb vor sda) und das sollte gehen. Macht er aber nicht Linux Mint fährt ohne Fragen hoch. Windows mault. Egal, wie ich die Datenkabel setze (die Idee hatte ich auch schon). Blöderweise habe ich Windows einmal "Startoptionen reparieren" lassen, das war mein Fehler, es klappte nicht und meine GRUB-Kombination ist aber wohl im Eimer, jedenfalls bootet diese Platte nun gar nicht mehr (alles im Not-PC).

Ich hatte jetzt folgende Idee: Windows Installation holen und reparieren lassen. Danach das Linux den GRUB wieder reparieren lassen und noch einmal probieren jetzt mit markierten Platten und Datenkabeln... Dummerweise weiß ich nicht mehr wie ich das vor Jahren gemacht hatte? SuperGrub?!

Folgender kleiner Nebeneffekt irritiert mich auch noch. Sobald eine der beiden Platten angeschlossen ist, klappt auch kein Boot vom Stick mehr (Gparted, Linux Mint, Windows Install) - die stürzen alle mit black screen und bewegungslos ab, anscheinend sobald sie den Plattenbereich der ehemaligen sda untersuchen oder auch nur suchen? Die Platte selbst (1 TB) ist in Ordnung, ich konnte alles sichern - nur würde ich gerne deren Desktop auch noch mal haben... Weil da ein paar Links/Programme drauf sind, die ich so nicht habe auf einem ansonsten 90%igen 1:1 Klon vom Oktober. Speziell Signal fehlt mir doch sehr, ich weiß die Installation ist etwas eigen.

Weiß jemand zufällig die richtige Reihenfolge, wie man den Grub repariert?

[The Poet]

Öhm nun muß ich doch mal fragen... Kennt sich jemand mit Multi-Boot Problemchen aus, Grub usw.

Ich hatte bis letzte Woche eine Installation Win 7 / Linux Mint 17.2 auf einem Uralt-Rechner. Der hatte 2 Platten, das Boot-Menue war auf sdb und ein Verweis zum Windows auf sda. Ob Windows noch alleine gebootet hätte, weiß ich gar nicht mal so, weil ich es nicht mehr probieren konnte mit Abziehen der 2.Platte. Außerdem hatte der PC mehrere Macken und sollte verschrottet werden - solange wie ich ihn anhatte, ging er aber noch wie Bienchen.

Jetzt mein Problem. Ich dachte, ich ziehe die beiden Festplatten einfach um in einen Not-PC (zu klein und zu alt ja, aber als Kopierstation mit 4GB noch zu gebrauchen), melde sie im Bios in der richtigen Reihenfolge an (sdb vor sda) und das sollte gehen. Macht er aber nicht Linux Mint fährt ohne Fragen hoch. Windows mault.

Ich glaub hier ist das Problem (zumindest für den Windows-Teil). Win 7 erwartet seine alte Hardware und findet sie nicht...

(Oder ist der "neue" Not-PC baugleich zum alten? Dann nevermind. Bzw. dann könnte sich Win 7 immerhin noch an evtl. geänderten Hardware-IDs stören... aber das ist nur Rumraterei meinerseits. Ich würd sowas auf jeden Fall nicht machen... anderes System => Neuinstallation. Zumindest bei Windows, da kann man sonst ja gar nix debuggen weil closed source.
Was in deinem Fall sinnfrei wäre, natürlich, denn du willst ja noch vorm Planieren der HDD mal ins *alte* Windows reingucken.)

Ich hatte jetzt folgende Idee: Windows Installation holen und reparieren lassen. Danach das Linux den GRUB wieder reparieren lassen und noch einmal probieren jetzt mit markierten Platten und Datenkabeln... Dummerweise weiß ich nicht mehr wie ich das vor Jahren gemacht hatte? SuperGrub?!

Ich mach's immer so: Passenden Linux Mint-Distri-Datenträger raussuchen, von da booten, und von da die ganze grub-Grütze neugenerieren lassen, aber halt mit dem target für die grub-Dateien auf der Festplatte (anstatt dem, was jetzt im virtuellen Filesystem liegt, das aus dem CD- oder dem Stick-Static-Filesystem im Hintergrund abgeleitet ist). Gibt Anleitungen dafür im Netz. Offenbar hast du das aber jetzt auch schon probiert ... bzw. wolltest es probieren, aber scheiterst am BlackSOD , von daher...

Folgender kleiner Nebeneffekt irritiert mich auch noch. Sobald eine der beiden Platten angeschlossen ist, klappt auch kein Boot vom Stick mehr (Gparted, Linux Mint, Windows Install) - die stürzen alle mit black screen und bewegungslos ab, anscheinend sobald sie den Plattenbereich der ehemaligen sda untersuchen oder auch nur suchen? Die Platte selbst (1 TB) ist in Ordnung, ich konnte alles sichern - nur würde ich gerne deren Desktop auch noch mal haben... Weil da ein paar Links/Programme drauf sind, die ich so nicht habe auf einem ansonsten 90%igen 1:1 Klon vom Oktober. Speziell Signal fehlt mir doch sehr, ich weiß die Installation ist etwas eigen.

...gehen wir nochmal zum ursächlichen Grund, warum du das eigentlich tun willst: Was meinst du mit "deren Desktop" (nochmal haben)? Da die Platte gesichert ist, würde es doch reichen, dir den Ordner rauszusuchen, in dem die Desktop-Verknüpfungen gespeichert sind und sie dir wegzusaven. Oder meinst du "nochmal den Desktop/Windows-Screen vor dir haben, um dir Notizen machen zu können und dir Configs etc. auf einem eventuellen künftigen super-neuen Rechner klicken zu können" ... also: "so klicken, dass sie identisch zu den alten Configs sind"?

Weiß jemand zufällig die richtige Reihenfolge, wie man den Grub repariert?

Die Frage scheint ja wohl eher zu sein, wie du das tun willst, wenn der Stick seinen Dienst unter bestimmten Nebenbedingungen (Platte drangehängt) versagt...

Was passiert, wenn du vom Stick booten willst, wenn du

a) keine HDD dran hast
b) sda dran hast (das war Windows, IIRC)
c) sdb dran hast (das war Linux mit grub, IIRC)
d) beide dran hast?

Führt das *alles* zum BlackSOD? Und schon andere Sticks probiert? Evtl. liegt's daran? Und: Im BIOS alles richtig eingestellt ... Boot-Optionen für Disks & USB?

Schon mal Grub4DOS auf dem Stick probiert? Das kann zumindest grub glaub ich chainloaden (zum Testen) und hilft vielleicht bei der Fehlersuche. Mir hat es zumindest früher das eine oder andere Mal den Ar*** gerettet, noch zu XP-Zeiten.


Perspektivisch, die typischen kreativen Hacker-Ideen:
Also sofern du es *irgendwie* geschafft hast, wenigstens Windows wieder zum Laufen zu bringen, könntest du ja dessen Partition und Bootloader als primär auswähen, und zur Not Grub4DOS mal probieren... das kann IIRC grub chainloaden... der dann wiederum Linux startet. Oder vielleicht kann Grub4DOS mittlerweile auch das Linux Mint direkt chainloaden. Ist zwar ein bisschen von hinten übers Ohr durchs Knie geschossen , aber als Notfalllösung wär's okay, sofern Linux vom Stick zu Reparaturzwecken gar nicht mehr booten will.

Aber Priorität hat natürlich erstmal die a)-b)-c)-d)-Geschichte, is klar ^^.

[oldfield2283]

Öhm nun muß ich doch mal fragen... Kennt sich jemand mit Multi-Boot Problemchen aus, Grub usw.

Ich hatte bis letzte Woche eine Installation Win 7 / Linux Mint 17.2 auf einem Uralt-Rechner. Der hatte 2 Platten, das Boot-Menue war auf sdb und ein Verweis zum Windows auf sda. Ob Windows noch alleine gebootet hätte, weiß ich gar nicht mal so, weil ich es nicht mehr probieren konnte mit Abziehen der 2.Platte. Außerdem hatte der PC mehrere Macken und sollte verschrottet werden - solange wie ich ihn anhatte, ging er aber noch wie Bienchen.

Jetzt mein Problem. Ich dachte, ich ziehe die beiden Festplatten einfach um in einen Not-PC (zu klein und zu alt ja, aber als Kopierstation mit 4GB noch zu gebrauchen), melde sie im Bios in der richtigen Reihenfolge an (sdb vor sda) und das sollte gehen. Macht er aber nicht Linux Mint fährt ohne Fragen hoch. Windows mault.

Ich glaub hier ist das Problem (zumindest für den Windows-Teil). Win 7 erwartet seine alte Hardware und findet sie nicht...

(Oder ist der "neue" Not-PC baugleich zum alten? Dann nevermind. Bzw. dann könnte sich Win 7 immerhin noch an evtl. geänderten Hardware-IDs stören... aber das ist nur Rumraterei meinerseits. Ich würd sowas auf jeden Fall nicht machen... anderes System => Neuinstallation. Zumindest bei Windows, da kann man sonst ja gar nix debuggen weil closed source.
Was in deinem Fall sinnfrei wäre, natürlich, denn du willst ja noch vorm Planieren der HDD mal ins *alte* Windows reingucken.)

Ich hatte jetzt folgende Idee: Windows Installation holen und reparieren lassen. Danach das Linux den GRUB wieder reparieren lassen und noch einmal probieren jetzt mit markierten Platten und Datenkabeln... Dummerweise weiß ich nicht mehr wie ich das vor Jahren gemacht hatte? SuperGrub?!

Ich mach's immer so: Passenden Linux Mint-Distri-Datenträger raussuchen, von da booten, und von da die ganze grub-Grütze neugenerieren lassen, aber halt mit dem target für die grub-Dateien auf der Festplatte (anstatt dem, was jetzt im virtuellen Filesystem liegt, das aus dem CD- oder dem Stick-Static-Filesystem im Hintergrund abgeleitet ist). Gibt Anleitungen dafür im Netz. Offenbar hast du das aber jetzt auch schon probiert ... bzw. wolltest es probieren, aber scheiterst am BlackSOD , von daher...

Folgender kleiner Nebeneffekt irritiert mich auch noch. Sobald eine der beiden Platten angeschlossen ist, klappt auch kein Boot vom Stick mehr (Gparted, Linux Mint, Windows Install) - die stürzen alle mit black screen und bewegungslos ab, anscheinend sobald sie den Plattenbereich der ehemaligen sda untersuchen oder auch nur suchen? Die Platte selbst (1 TB) ist in Ordnung, ich konnte alles sichern - nur würde ich gerne deren Desktop auch noch mal haben... Weil da ein paar Links/Programme drauf sind, die ich so nicht habe auf einem ansonsten 90%igen 1:1 Klon vom Oktober. Speziell Signal fehlt mir doch sehr, ich weiß die Installation ist etwas eigen.

...gehen wir nochmal zum ursächlichen Grund, warum du das eigentlich tun willst: Was meinst du mit "deren Desktop" (nochmal haben)? Da die Platte gesichert ist, würde es doch reichen, dir den Ordner rauszusuchen, in dem die Desktop-Verknüpfungen gespeichert sind und sie dir wegzusaven. Oder meinst du "nochmal den Desktop/Windows-Screen vor dir haben, um dir Notizen machen zu können und dir Configs etc. auf einem eventuellen künftigen super-neuen Rechner klicken zu können" ... also: "so klicken, dass sie identisch zu den alten Configs sind"?

Weiß jemand zufällig die richtige Reihenfolge, wie man den Grub repariert?

Die Frage scheint ja wohl eher zu sein, wie du das tun willst, wenn der Stick seinen Dienst unter bestimmten Nebenbedingungen (Platte drangehängt) versagt...

Was passiert, wenn du vom Stick booten willst, wenn du

a) keine HDD dran hast
b) sda dran hast (das war Windows, IIRC)
c) sdb dran hast (das war Linux mit grub, IIRC)
d) beide dran hast?

Führt das *alles* zum BlackSOD? Und schon andere Sticks probiert? Evtl. liegt's daran? Und: Im BIOS alles richtig eingestellt ... Boot-Optionen für Disks & USB?

Schon mal Grub4DOS auf dem Stick probiert? Das kann zumindest grub glaub ich chainloaden (zum Testen) und hilft vielleicht bei der Fehlersuche. Mir hat es zumindest früher das eine oder andere Mal den Ar*** gerettet, noch zu XP-Zeiten.


Perspektivisch, die typischen kreativen Hacker-Ideen:
Also sofern du es *irgendwie* geschafft hast, wenigstens Windows wieder zum Laufen zu bringen, könntest du ja dessen Partition und Bootloader als primär auswähen, und zur Not Grub4DOS mal probieren... das kann IIRC grub chainloaden... der dann wiederum Linux startet. Oder vielleicht kann Grub4DOS mittlerweile auch das Linux Mint direkt chainloaden. Ist zwar ein bisschen von hinten übers Ohr durchs Knie geschossen , aber als Notfalllösung wär's okay, sofern Linux vom Stick zu Reparaturzwecken gar nicht mehr booten will.

Aber Priorität hat natürlich erstmal die a)-b)-c)-d)-Geschichte, is klar ^^.

Hey erstmal vielen Dank für deine schnelle Antwort! Ja das mit dem a)->d) wollte ich noch mal checken. Es hat mir gestern einen gehörigen Schrecken eingejagt. Generell ging der Stick und auch Grub/Geparted/Mint/Windows-Install auf dem Not-PC schon mal....

Also der Not-PC ist leider viele Nummern kleiner von der Hardware (RAM/Prozi). Du hast recht, ich habe nicht bedacht, daß Windows nicht nur die Platten prüft... Das Linux Mint hatte überhaupt nicht gemault... Also die Rechner sind 16 (der kaputte) und 12 (der Not) Jahre alt - ich erwarte keine Wunderdinge.

Ich werde deine Tips alle der Reihe nach abarbeiten, Priorität hatte für mich erstmal das Daten sichern, und dazu benutze ich auch ein anderes System, nicht den Not-PC (nicht daß der mir meine externen Platten noch schrottet). Mein notwendiges "Umschaufeln" (4 TB auf ne 10 TB damit die leere 4 TB dann das von den Unglücks-Platten aufnimmt) dauert ja auch...

Hier (auf dem 3.PC) könnte notfalls auch der Stick noch mal sich mit dem Wieder-Start-Fähigmachen der einen Platte beschäftigen, ich kann auch sehen, ob a)-d) auch auf diesem PC so passieren. Auf dem 3.PC lief der Stick - habe ich heute geprüft...

Generell hast du recht - ich komme an den Desktop-Ordner ja ran. Es ging mir um 3-4 installierte Programme u.a. Signal weil das bis jetzt noch so schön gekoppelt ist ans Handy. Wahrscheinlich habe ich aber schlechte Karten, installierte Programme eventell auf dem Not-PC weiter aufzurufen von der dann ja fremden Platte, daher würde ich es gerne so booten. Es ist nicht dramatisch - 90% habe ich auf einem damals erstellten Klon-System.

[Mit müden Augen]

Ich hab nur quergelesen (zu müde und depressiv ), aber BSOD macht mir Sorgen, vor allem bei einem so alten Rechner. Da könnte sich ein ordentlicher Hardwaredefekt ankündigen, Mainboard oder so - wenn nicht die Platte einen weg hat. Mal die SMART-Daten kontrolliert?
EDIT: Achja, Vorsicht: Die Zeile "SMART overall-health self-assessment test result:" von smartctl ist Schwachsinn (und gehört imho entfernt), da stand auch PASSED bei Platten die kurz vorm Exitus waren (oder schon dahinter). Man muss die Details weiter unten angucken (smartctl -a /dev/XXX).

[Mit müden Augen]

AUA! https://hackaday.com/2022/01/26/major-b ... ributions/

researchers recently found a major bug found in most major Linux distributions that allows anyone to run code as the root user

[oldfield2283]

Ich gebe mal einen Zwischenbericht zum Grub-Problem... Die Windowsplatte läuft wieder und bootet sogar, allerdings in einem 3.PC, wo die Platten aber nicht bleiben können (einfach kein Raum frei, da sind schon 3). Das Mirakel mit dem Dualboot und was es mit den BSOD auf sich hat in den Fällen A-D, muß ich noch untersuchen, schreibe dann noch dazu.

Ich habe heute aber ein anderes Problem: Ich habe bei einem Laptop nicht aufgepaßt und die Linux-Mint Partition eines Dualbootes zu klein (50GB) gewählt. Wie vergrößere ich die ohne Neuinstallation (ginge schon aber wenn es nicht sein muß) auf 200 GB? Den erforderlichen Platz habe ich Windows schon abgeknappst - mir stellt sich für den Linuxteil jedoch die Frage:
a) per Gparted vom Stick?
b) per Gparted im Mint selber (kann der das?)
c) ein externes Programm unter Windows (AOMEI)

Ich denke c) wird es kaputt machen. Hat jemand das schon gemacht?

[The Poet]

Ich gebe mal einen Zwischenbericht zum Grub-Problem... Die Windowsplatte läuft wieder und bootet sogar,

allerdings in einem 3.PC, wo die Platten aber nicht bleiben können (einfach kein Raum frei, da sind schon 3). Das Mirakel mit dem Dualboot und was es mit den BSOD auf sich hat in den Fällen A-D, muß ich noch untersuchen, schreibe dann noch dazu.

Ich habe heute aber ein anderes Problem: Ich habe bei einem Laptop nicht aufgepaßt und die Linux-Mint Partition eines Dualbootes zu klein (50GB) gewählt. Wie vergrößere ich die ohne Neuinstallation (ginge schon aber wenn es nicht sein muß) auf 200 GB? Den erforderlichen Platz habe ich Windows schon abgeknappst - mir stellt sich für den Linuxteil jedoch die Frage:
a) per Gparted vom Stick?
b) per Gparted im Mint selber (kann der das?)
c) ein externes Programm unter Windows (AOMEI)

Ich denke c) wird es kaputt machen. Hat jemand das schon gemacht?

a) gparted vom Stick hat bei mir bislang immer reibungslos funktioniert für diesen Use Case.

b) Nein, kann er net, das Dateisystem ist ja gemounted, das on-the-fly zu vergrößern würde $badthings / $therebedragons / $hicsuntdracones / $fubar fürs OS und seine (sowie deine) Daten darauf bedeuten. (Wäre eine ähnlich dumme Idee, wie von Linux auf eine Windows-Partition zuzugreifen, während Windows dort gerade gehibernated ist. )

Zu c) kann ich nix sagen. Da es ein Linux-Bordmittel ist, passt gparted aber glaub ich "kulturell" einfach besser

[Jack]

Ich habe heute aber ein anderes Problem: Ich habe bei einem Laptop nicht aufgepaßt und die Linux-Mint Partition eines Dualbootes zu klein (50GB) gewählt. Wie vergrößere ich die ohne Neuinstallation (ginge schon aber wenn es nicht sein muß) auf 200 GB? Den erforderlichen Platz habe ich Windows schon abgeknappst - mir stellt sich für den Linuxteil jedoch die Frage:
a) per Gparted vom Stick?
b) per Gparted im Mint selber (kann der das?)
c) ein externes Programm unter Windows (AOMEI)

Ich denke c) wird es kaputt machen. Hat jemand das schon gemacht?

ist zwar schon etwas her aber das sollte kein Problem sein.

1. Daten sichern
2. gparted im Mint nutzen um Partition zu vergrößern
3. resize2fs im Mint nutzen um Dateisystem anzupassen
4. reboot
5. Profit


c) könnte funktionieren...
Partition dürfte kein Problem sein, das ist Standard.
aber das Dateisystem anpassen? zweifelhaft...
ext4 & btrfs sind nicht immer 100% unterstützt

[Jack]

b) Nein, kann er net, das Dateisystem ist ja gemounted, das on-the-fly zu vergrößern würde $badthings / $therebedragons / $hicsuntdracones / $fubar fürs OS und seine (sowie deine) Daten darauf bedeuten.

Doch, entsprechend aktuelle Software (Kernel, resize2fs, etc.) vorausgesetzt ist das kein Problem.
Nur verkleinern geht nicht (vermutlich weil Daten verschoben werden müssten u.ä.)
Vergrößern fügt nur freien Speicher und einige Verwaltungsdaten dazu, sehr viel einfacher.

[The Poet]

b) Nein, kann er net, das Dateisystem ist ja gemounted, das on-the-fly zu vergrößern würde $badthings / $therebedragons / $hicsuntdracones / $fubar fürs OS und seine (sowie deine) Daten darauf bedeuten.

Doch, entsprechend aktuelle Software (Kernel, resize2fs, etc.) vorausgesetzt ist das kein Problem.
Nur verkleinern geht nicht (vermutlich weil Daten verschoben werden müssten u.ä.)
Vergrößern fügt nur freien Speicher und einige Verwaltungsdaten dazu, sehr viel einfacher.

Ah, gut, man lernt nie aus.

Aber nur nach hinten hin, oder?

Die primären Verwaltungsdaten vom FS stehen doch am Anfang der Partition, sprich wenn Linux nicht die erste Partition auf der Platte ist (man z.B. gerade eine andere Partition *davor* gelöscht hat) und man in den freien Bereich vor Linux hineinexpandieren wollte, müssten die verschoben werden. Oder geht das mittlerweile auch, dank improvements der Software?


Naja, egal, ich würd's vermeiden wollen, aber ich bin eh ein Security-Fanatiker