Das Paragon LFS for windows (Lizenzgebühren!!!) ist nicht mehr kompatibel mit dem Debian OS Trixie!
Man kann also unter windows nun nicht mehr die Root Partition der RaspberryPI SD-Card (r/w) mounten.
Offensichtlich verkauft Paragon immer noch Lizenzen, obwohl längst nicht mehr funktionsfähig.
Mal abgesehen davon ist’s nach wie vor ext4 – da hat sich nicht sonderlich viel verändert. Wenn’s also mit Bookworm funktioniert, dann sollte es auch mit Trixie tun.
Mal abgesehen davon ist’s nach wie vor ext4 – da hat sich nicht
sonderlich viel verändert. Wenn’s also mit Bookworm funktioniert, dann
sollte es auch mit Trixie tun.
Ja, sowas wollte ich auch erst antworten, aber ich verifiziere meine Ansicht ja ganz gerne und so habe ich im Forum der Raspi-Leute das hier [1] gefunden. Kurzfassung: Debian Trixie scheint einige ext4-Optionen zu aktivieren, die zuvor nicht genutzt wurden, und das scheint die obengenannte Software aus dem Tritt zu bringen.
Mal abgesehen davon ist’s nach wie vor ext4 – da hat sich nicht
sonderlich viel verändert. Wenn’s also mit Bookworm funktioniert, dann
sollte es auch mit Trixie tun.
Ja und nein: Es haben sich wohl ein paar Parameter beim Erstellen des Filesystems bei Trixie (genauer gesagt wurde wohl die Entwicklungsmaschine upgedatet) veraendert. Und die Implementierung bei Paragon ist wohl nicht vollstaendig (vulgo fehlerhaft).
Je nach Lizenzvertrag kann man auch eine Maengelruege bei Paragon in Freiburg reinkippen. Ob der Treiber noch weiter entwickelt wird, weiss ich natuerlich nicht.
Zum TO: Freundlich anfragen hilft manchmal (eventuell ist Paragon das Problem gar nicht bewusst), ansonst eskalieren (ist ja ein Mangel).
Debian Trixie scheint einige ext4-Optionen zu
aktivieren, die zuvor nicht genutzt wurden, und das scheint die
obengenannte Software aus dem Tritt zu bringen.
Interessant, danke. Ich hab an dieser Stelle tatsächlich angenommen, dass Paragon das Dateisystem vollständig implementiert hätte – ist ja nicht so, als wäre da was geheim.
FAQ auf der Paragon-Webseite, einsehbar bevor man sich zum Kauf entschließt:
Fast alle Funktionen von Ext4, dem aktuellsten Dateisystem von Linux,
werden unterstützt: 64bit, dir_index, extent, extra_isize, ext_attr,
flex_bg, has_journal etc. Die Funktionen bigalloc, journal_dev, meta_bg,
inline_data werden von Linux File Systems für Windows von
Paragon Software momentan noch nicht unterstützt.
Genauso deutlich weist die Webseite darauf hin, dass XFS und btrfs nur Read-Only gehen.
Die Funktionen bigalloc, journal_dev, meta_bg,
inline_data werden von Linux File Systems für Windows von
Paragon Software momentan noch nicht unterstützt.
Vielleicht kann man die inkompatiblen Funktionen mit "tune2fs" abschalten? Scheint ja nichts lebensnotwendiges zu sein.
Die Funktionen bigalloc, journal_dev, meta_bg,
inline_data werden von Linux File Systems für Windows von
Paragon Software momentan noch nicht unterstützt.
Vielleicht kann man die inkompatiblen Funktionen mit "tune2fs"
abschalten? Scheint ja nichts lebensnotwendiges zu sein.
Ich meine, das geht nicht. Also tar -c, mke2fs, tar -x
Man kann also unter windows nun nicht mehr die Root Partition der
RaspberryPI SD-Card (r/w) mounten.
Nur interessehalber: wofür braucht man das?
Erfahrungsgemäß kann man viele Daten einfach per USB-Stick übertragen.
Darüberhinaus können VMWare oder Cygwin oder andere Emulatoren wie Bochs auch gute Dienste leisten.
Wenn der Raspberry nicht bootet, weil man sich irgendeine zum Booten nötige Konfigurationsdatei zerschossen hat, hilft einem ssh nicht weiter. Und wenn man nicht eh' schon einen Linux-Rechner herumstehen hat, muss man sich mit was anderem behelfen, und das ist, so sehr es die Linux-Fanbois auch schmerzt, doch sehr oft ein Windows-Rechner.
Und wenn man nicht eh' schon einen Linux-Rechner herumstehen
hat,
oder wenn man auch keine USB-Boots einrichten kann(oder Backups).., oder keine keine Reparaturversuche im Internet lesen kann, oder einfach nicht viel Erfahrung mit Datenaustausch zwischen Windows und Linux hat, und so eher kritische (kostenpflichtige) Erleichterungen einsetzen muss.
Eine Norton "hier-hast-du-alles"- Installation mit unbedingter DOS-Partition auf Windows ME hatte mir auch mal die komplette ME-Installation zerschossen - nicht Norton allein - aber einfacher wurden z.B. Probleme mit dem Grafikkartentreiber oder dem Maustreiber dadurch auch nicht.
Ich glaube, Rcx' eigentliche Frage war: warum möchte man die
Root-Partition eines Raspberry Pi unter Windows r/w mounten ;-)
Wenn ›ssh user@raspberry‹ zu umständlich ist. ;-)
Das gibt ja nur einen Shellzugriff über SSH (und wenn man das häufiger braucht hilft eine passende ~/.ssh/config), für einen Dateizugriff braucht es so etwas wie scp(1), sftp(1), sshfs(1) oder rsync(1)... Außerdem würd ich unter Windows anstelle von Kommandozeilenwerkzeugen eher so etwas wie FileZilla, WinSCP oder vor allem Moba Xterm empfehlen. Letzteres ermöglicht dabei gleichzeitig Shell- und Dateizugriffe in einer Oberfläche, die dem Windows Explorer ähnelt.
Wenn der Raspberry nicht bootet, weil man sich irgendeine zum Booten
nötige Konfigurationsdatei zerschossen hat, hilft einem ssh nicht
weiter.
Das ist richtig. (Hoffentlich nur äußerst selten…)
Wenn man jedoch sein System mit so schöner Regelmäßigkeit zerkonfiguriert, dass die armseligen Überreste zuckend und wimmernd am Boden liegen, dann gilt es erst einmal eine Reihe anderer Probleme zu lösen.
FAQ auf der Paragon-Webseite, einsehbar bevor man sich zum Kauf
entschließt:
Fast alle Funktionen von Ext4, dem aktuellsten Dateisystem von Linux,
werden unterstützt: 64bit, dir_index, extent, extra_isize, ext_attr,
flex_bg, has_journal etc. Die Funktionen bigalloc, journal_dev, meta_bg,
inline_data werden von Linux File Systems für Windows von
Paragon Software momentan noch nicht unterstützt.
Genauso deutlich weist die Webseite darauf hin, dass XFS und btrfs nur
Read-Only gehen.
EXT4 SD-Cards (Trixie) werden erst gar nicht mehr gemounted!
Read - Only geht also auch nicht!
Ausserdem habe ich r/w für ext4 bezahlt! (Lebenslange Lizenz).
Man kann also unter windows nun nicht mehr die Root Partition der
RaspberryPI SD-Card (r/w) mounten.
Ist tatsächlich manchmal der einfachste/schnellste Weg, um
Konfigurationsfehler zu beheben.
Ich glaube, Rcx' eigentliche Frage war: warum möchte man die
Root-Partition eines Raspberry Pi unter Windows r/w mounten? ;-)
z.B. weil ich mir die ext4-partition hinsichtlich ihres Inhalts unter windows in 30 Sekunden einmal ganz kurz anschauen möchte (... wenn ich z.B. 100 SD-Karten im Fundus habe)
Mir hat das LFS in den letzten Jahren oft schnell und gut geholfen - auch schreibend.
Aber ich habe im Web (dank des Hinweises in diesem Thread - Danke!) eine schöne Beschreibung gefunden, wie man die ext4 Partition auch unter WSL2 r/w mounten kann.
EXT4 SD-Cards (Trixie) werden erst gar nicht mehr gemounted!
Read - Only geht also auch nicht!
Ausserdem habe ich r/w für ext4 bezahlt! (Lebenslange Lizenz).
Das haben wir verstanden. Aber was möchtest Du jetzt? Möchtest Du uns vor dieser Software und / oder ihrem Hersteller warnen? Möchtest Du einen Rat haben, wie Du mit der Situation umgehen sollst, oder kannst? Ich hätte da möglicherweise Ideen, wie ich das handhaben würde, allerdings... wenn die Anzahl der Ausrufezeichen in Deinen Beiträgen einen Rückschluß auf Deinen Erregungszustand zuläßt, werden meine Ideen für Dich nicht funktionieren.
FAQ auf der Paragon-Webseite, einsehbar bevor man sich zum Kauf
entschließt:
Fast alle Funktionen von Ext4, dem aktuellsten Dateisystem von Linux,
werden unterstützt: 64bit, dir_index, extent, extra_isize, ext_attr,
flex_bg, has_journal etc. Die Funktionen bigalloc, journal_dev, meta_bg,
inline_data werden von Linux File Systems für Windows von
Paragon Software momentan noch nicht unterstützt.
Genauso deutlich weist die Webseite darauf hin, dass XFS und btrfs nur
Read-Only gehen.
Es wird aber nicht darauf hingeweisen, dass Trixie nicht funktioniert!
EXT4 SD-Cards (Trixie) werden erst gar nicht mehr gemounted!
Read - Only geht also auch nicht!
Ausserdem habe ich r/w für ext4 bezahlt! (Lebenslange Lizenz).
Das haben wir verstanden. Aber was möchtest Du jetzt? Möchtest Du uns
vor dieser Software und / oder ihrem Hersteller warnen? Möchtest Du
einen Rat haben, wie Du mit der Situation umgehen sollst, oder kannst?
Ich hätte da möglicherweise Ideen, wie ich das handhaben würde,
allerdings... wenn die Anzahl der Ausrufezeichen in Deinen Beiträgen
einen Rückschluß auf Deinen Erregungszustand zuläßt, werden meine Ideen
für Dich nicht funktionieren.
Ihr habt mir schon geholfen (Thomas W.) - mit WSL2 lässt sich von windows aus Trixie r/w mounten!
Es hat mit der ext4 Version zu tun, welche in einem Kernel module residiert.
Welche Distribution auch immer einen halbwegs modernen Kernel nutzt, wird das gleiche Phänomen hervorrufen.
Ausserdem habe ich r/w für ext4 bezahlt! (Lebenslange Lizenz).
Du hast für ext4-R/W bezahlt, solange das ext4 keine der Optionen bigalloc, journal_dev, meta_bg oder inline_data verwendet.
Und genau das hast du bekommen. Sogar noch mehr, die Möglichkeit, dass Paragon einige dieser Features per Update nachliefert.
Wenn du dein debian selber installierst, kannst du festlegen, wie das Dateisystem formatiert wird, also dafür sorgen dass es mit Paragon kompatibel bleibt.
Wenn du ein vorgefertigtes Dateisystem-Image verwendest, ist das eben so formatiert, wie es der Image-Ersteller gemacht hat.
(Evtl. ist das Image auch noch OK, aber das automatische Resize des Images auf die volle SD-Card-Größe hat das meta_bg-Flag gesetzt)
Dann musst du das Betriebssystem eben umkopieren (sh. oben) oder eine andere Möglichkeit nutzen, um darauf zuzugreifen (sh. oben).
Ausserdem habe ich r/w für ext4 bezahlt! (Lebenslange Lizenz).
Du hast für ext4-R/W bezahlt, solange das ext4 keine der Optionen
bigalloc, journal_dev, meta_bg oder inline_data verwendet.
Und genau das hast du bekommen. Sogar noch mehr, die Möglichkeit, dass
Paragon einige dieser Features per Update nachliefert.
Wenn du dein debian selber installierst, kannst du festlegen, wie das
Dateisystem formatiert wird, also dafür sorgen dass es mit Paragon
kompatibel bleibt.
Wenn du ein vorgefertigtes Dateisystem-Image verwendest, ist das eben so
formatiert, wie es der Image-Ersteller gemacht hat.
(Evtl. ist das Image auch noch OK, aber das automatische Resize des
Images auf die volle SD-Card-Größe hat das meta_bg-Flag gesetzt)
Dann musst du das Betriebssystem eben umkopieren (sh. oben) oder eine
andere Möglichkeit nutzen, um darauf zuzugreifen (sh. oben).
Hääh? Bestimmt nicht! Ich lege die von RaspiImager original installierte Trixie SD in den SD-Mikroschacht meines w10 PCs ... und habe via WSL2 r/w Vollzugriff auf das RaspianOS (Trixie ext4). Weniger als 30 Sekunden ...!
Und was die Antwort von Paragon angeht - einfach meinen Eingangs-Thread durchlesen - nämlich keine Reaktion!
Es hat mit der ext4 Version zu tun, welche in einem Kernel module
residiert.
Welche Distribution auch immer einen halbwegs modernen Kernel nutzt,
wird das gleiche Phänomen hervorrufen.
Moderner Kernel – veraltete Software.
ext4 ist bei Trixie erweitert worden - dazu gibt es genügend Erklärungen im Netz! Einfach 'mal googeln (oder ChatGPT).
Außerdem würd ich unter Windows anstelle von Kommandozeilenwerkzeugen
eher so etwas wie FileZilla, WinSCP oder vor allem Moba Xterm empfehlen.
Ich bevorzuge den BitWise SSH-Clienten (https://bitvise.com/ssh-client). Der kann so ziemlich alles was ich zur Wartung/Administration meiner headless Linuxsysteme brauche. Sehr angenehm ist das ich über diesen Clienten die Dateien auf den Linuxsystemen direkt mit PSPad komfortabel editieren kann.
Ach das ist gar nicht mehr im Kernel?
Das gehört jetzt Debian?
Nein, du verstehst einfach nicht. Das deine komische EXT Mount Software nicht das gesamte EXT4 Format einlesen kann. Ganz einfach, das hat NICHTS mit Trixie zu tun. Werden die Flags z.b. bei Bookworm gesetzt dann kannst du auch diese nicht lesen, ganz einfach!
Aber das haben dir hier schon zig Leute versucht zu erklären, du willst es einfach nur nicht warhaben. Schuld ist nicht Trixie oder EXT4 sondern einfach deine Mount Software... Diese kann man aber auch keine Schuld geben, da sie explizit darauf hinweise das einige EXT4 Flags nicht gehen.
Der einzigste der also an dieser ganzen Miesere Schuld ist bist du: Du kanns einfach nicht verstehend lesen!
Eine Frage an den TO: Offensichtlich musst Du haeufiger Linux-Ext4-SD-Card (OK, Wechsel-Datentraeger) bearbeiten. Ich haette mir einen Linux-Rechner (z.B. einen Raspberry3) genommen, Kartenleser brauchst Du so oder so, einen Samba-Server aufgesetzt und mir eine "SD-Card-Modi-Station" gebaut. Copy & Paste mit dem Windows-Exploder. Das NL/CR-NL-Problem hat man so oder so wenn Windows im Spiel ist.
Du haettest jetzt natuerlich auch ein Problem mit dem Lesen des ext4-Volumens bekommen, aber vielleicht vernuenftige Fehlermeldungen. Und wenn man wirklich mal z.B. Ownerships oder Protections (acl) geradeziehen muss, dann ist eine richtige Shell Gold wert.
Eine Frage an den TO: Offensichtlich musst Du haeufiger
Linux-Ext4-SD-Card (OK, Wechsel-Datentraeger) bearbeiten. Ich haette mir
einen Linux-Rechner (z.B. einen Raspberry3) genommen, Kartenleser
brauchst Du so oder so, einen Samba-Server aufgesetzt und mir eine
"SD-Card-Modi-Station" gebaut. Copy & Paste mit dem Windows-Exploder.
Das NL/CR-NL-Problem hat man so oder so wenn Windows im Spiel ist.
Du haettest jetzt natuerlich auch ein Problem mit dem Lesen des
ext4-Volumens bekommen, aber vielleicht vernuenftige Fehlermeldungen.
Und wenn man wirklich mal z.B. Ownerships oder Protections (acl)
geradeziehen muss, dann ist eine richtige Shell Gold wert.
Wenn ich mir als häufiger Raspi-Verwender vor etlichen Jahren eine Paragon LFS Lizenz gekauft habe, um die ext4 Partion r/w von windows aus zu mounten, hat das mit Sicherheit sehr gewichtigen Gründe - auch wenn Du diese aus Deinem Tunnel-Blickwinkel nicht nachvollziehen kannst.
Ein Grund z.B., dass ich auf Bahn- oder Flugreisen nicht unbedingt zusätzlich einen Linux Rechner (Raspi) "zur Hand" habe (oder bei der Sicherheitskontrolle auspacken und erklären möchte).
Da greife ich dann unterwegs lieber per windows von meinem Notebook auf die ext4 der SD-Karte zu.
Aber da das nun aus WSL2 genauso gut geht, ist mein Anliegen durch den Hinweis diesen Thread gelöst! Danke an alle konstruktiven Mitstreiter - besonders an Thomas W. und diesen Link https://forums.raspberrypi.com/viewtopic.php?t=392565
Auch ist dort von Experten exakt das ext4 Problem mit der neuen Trixie Version beschrieben (bestätigt) worden - empfehlenswert für alle Besserwissenden hier ...!
Nein, du verstehst einfach nicht. Das deine komische EXT Mount Software
nicht das gesamte EXT4 Format einlesen kann.
Rene, das ist nicht meine komische EXT Mount Software! Lies besser.
Ganz einfach, das hat
NICHTS mit Trixie zu tun. Werden die Flags z.b. bei Bookworm gesetzt
dann kannst du auch diese nicht lesen, ganz einfach!
Das sage ich bereits die ganze Zeit. Lies besser.
Der einzigste der also an dieser ganzen Miesere Schuld ist bist du: Du
kanns einfach nicht verstehend lesen!
Tja, du bist ganz offensichtlich um ein Vielfaches zu dämlich zum verstehenden Lesen.
Ich wiederhole es ein paar mal für dich.
Hendrik hat das Problem!
Hendrik hat das Problem!
Hendrik hat das Problem!
Hendrik hat das Problem!
Wir versuchen ihm das klar zu machen!
Na ja, und nun auch dir.
Und als kleine Zusatzinformation für die anderen Mitlesenden:
Zwischen Kernel 5.10.0 (in Debian 11 Bullseye) und Kernel 6.1.0 (in Debian 12 Bookworm) gab es keine Kernel-module-ext4 Unterschiede.
Bei Kernel 6.12.48 (in Debian 13 Trixie), da hat sich etwas im Kernel-module ext4 geändert. Per default werden nun beim Erstellen die Optionen +orphan_file +metadata_csum_seed automagisch hinzu genommen.
Und nein, falls die Frage kommt, das hat mit /etc/mke2fs.conf nichts zu tun. Die kann man stumpf löschen und erhält dennoch das gleiche Ergebnis.
Kleiner tipp: wenn ihr einfach UDF als Rootfs nehmt, kann auch Windows drauf zugreifen. Einfach schauen, dass man den richtigen Medientype, und eine von allen unterstützte Version nimmt.
(ACHTUNG: Beim Formatieren einer Partition gehen alle darauf vorhandenen Daten verloren, also macht vorher ein Backup davon, z.B. mit "tar -cvzf").
Geht mit Windows und Linux, Mac müsste es theoretisch auch supporten, hab das aber nicht ausprobiert.
Wenn ihr es auf eine Partition packt, bei MBR typ 07 (HPFS/NTFS/exFAT) nehmen, sonst zeigt MS es nicht an, und bei GPT EBD0A0A2-B9E5-4433-87C0-68B6B72699C7 (Microsoft basic data). Ohne Partitionstabell oder Hybrid hab ich es noch nicht probiert, kann sein, das man das braucht, wenn es auch auf Mac gehen soll.
UDF ist das Universal Disk Format. Das ist Universell, geht überall. Dafür ist es da.
Nein, du verstehst einfach nicht. Das deine komische EXT Mount Software
nicht das gesamte EXT4 Format einlesen kann.
Rene, das ist nicht meine komische EXT Mount Software! Lies besser.
Ganz einfach, das hat
NICHTS mit Trixie zu tun. Werden die Flags z.b. bei Bookworm gesetzt
dann kannst du auch diese nicht lesen, ganz einfach!
Das sage ich bereits die ganze Zeit. Lies besser.
Der einzigste der also an dieser ganzen Miesere Schuld ist bist du: Du
kanns einfach nicht verstehend lesen!
Tja, du bist ganz offensichtlich um ein Vielfaches zu dämlich zum
verstehenden Lesen.
Ich wiederhole es ein paar mal für dich.
Hendrik hat das Problem!
Hendrik hat das Problem!
Hendrik hat das Problem!
Hendrik hat das Problem!
Wir versuchen ihm das klar zu machen!
Na ja, und nun auch dir.
Was wollt Ihr mir denn klar machen ???
Ich habe den Thread mit dem Hinweis eröffnet, dass Paragon LFS mit Trixie nicht mehr funktioniert. Warum ist mir eigentlich total egal ... bin an der Bit-Toggelei auf Driver Level gar nicht interessiert.
Ich will auf ext4 Ebene auch gar keinen Work-Around ... es soll éinfach nur funktionieren (wie bisher ... in 30 Sekunden).
Und da Paragon nicht reagiert hat, obwohl ich bezahlt habe (für eine Live Time Licence - wohlgemerkt), habe ich hier eine Lösung gesucht / gefunden!
Die "wissenschaftliche" Begründung, wo das eigentliche Problem liegt ... und wie man es evtl. umschiffen könnte, interessiert mich nicht die Bohne - bin lösungsorientiert.
WSL2 ist der zu Paragon LFS ebenbürtige Problemlöser - wie Paragon LFS for windows es einmal war.
Und - jetzt auch ohne neue Lizenkosten - als windows Dreingabe..., die Lösung habe ich gesucht!
Kleiner tipp: wenn ihr einfach UDF als Rootfs nehmt, kann auch Windows
drauf zugreifen. Einfach schauen, dass man den richtigen Medientype, und
eine von allen unterstützte Version nimmt.
Und - jetzt auch ohne neue Lizenkosten - als windows Dreingabe..., die
Lösung habe ich gesucht!
Eigentlich ist die WSL2 eine Linux VM, Linux kommt nicht von Microsoft, da braucht man ihnen keine Kredits für zu geben.
Und der Zugriff auf die WSL2 nutzt das P9 Protocol, das kommt von Plan9.
Es ist also nicht so, dass Windows seit der WSL2 ext4 Dateisysteme lesen könnte. Stattdessen mountet die Linux VM das Ext4 Laufwerk in seinem VFS Tree, und auf den greift Windows als P9 Netzlaufwerk zu.
Wenn die SD-Karte mit dem RasPi Imager erstellt wurde, ist das Rootfs
immer ext4 - eine Checkbox UDF gibt es dort nicht!
Ja, irgendwie ist ausser mir niemand ein Fan von dem Dateisystem. Ich Bootstrappe meine Systeme immer selbst (auch die RPIs), und hab da deshalb mehr Kontrolle darüber, wie das System funktioniert.
Ich könnte mal als kleine Demo so ein Spezielles Image erstellen, falls jemand Interesse hat.
Noch eine Anmerkung (die von Mario M. bereits vorgeschlagen wurde):
1
tune2fs -O^metadata_csum_seed /dev/whatever
2
tune2fs -O^orphan_file /dev/whatever
Damit hättest du deine Installationen problemlos ins letzte Jahrtausend bomben können, so dass sie mit der Windows-Software aus dem gleichen Zeitraum kompatibel ist.
Ja, irgendwie ist ausser mir niemand ein Fan von dem Dateisystem.
Sicher eine interessante Lösung wenn man keinerlei Security/Zugriffskontrolle benötigt. Genau bei ›mandatory access control‹ hapert es jedoch, wodurch mit einiger Wahrscheinlichkeit kein SE-Linux oder ähnlich wirkende Sicherheitsmechanismen greifen würden.
Zugegeben, für den durchschnittlichen Heim-Anwender zumeist kein Problem. Aber stark einschränkend.
Das ganze MAC/LSM Zeugs ist eh viel zu kompliziert. Ich finde, das ganz normale DAC bietet mehr als genug Zugriffskontrolle, und ist viel einfacher zu verwenden.
Das ganze MAC/LSM Zeugs ist eh viel zu kompliziert. Ich finde, das
ganz
normale DAC bietet mehr als genug Zugriffskontrolle, und ist viel
einfacher zu verwenden.
Sagt man, bis es einen dann doch erwischt.
Ich habe jedenfalls nicht die geringsten Bedenken, dass sich ein illegaler ssh-Einwähler irgendwie root Rechte beschafft.
Da müssen mein System und ich beide zugleich heftig lachen.
Ach ja, und das Logfile bekommt einen Eintrag.
Bei einem /normalen/ ugo Rechtesystem darf man dann eine frische Installation vornehmen.
Ich habe jedenfalls nicht die geringsten Bedenken, dass sich ein
illegaler ssh-Einwähler irgendwie root Rechte beschafft.
Hab ich auch nicht, auch ganz ohne MAC. Auch nur mit DAC kann man nicht einfach so überall hinschreiben, oder einfach so Root werden.
Ok, man muss etwas aufpassen, dass man Sachen wie sudo und polkit richtig Konfiguriert hat (sofern man die installiert hat), docker vermeidet, usw. aber das ist einfacher, als Selinux oder Apparmor richtig zu konfigurieren. (Wobei, Polkit hab ich sowieso nur auf meinem Laptop, für so Sachen wie KDE Discover. Würde ich eigentlich auch gerne mal loswerden, aber ist halt bequem... Naja, wenigstens hab ich kein Systemd mit Machinectl und Socket Activation usw., wo es nochmal ein dutzend Interfaces mehr gibt, die zur Privilege Eskalation genutzt werden könnten, wenn man nicht aufpasst...)
Wobei, dass sich jemand bei mir unerlaubt per SSH Einwählt ist sowieso ausgeschlossen, in der SSH Config ist nämlich nur mein eigener Account freigeschalten, und der ist gut geschützt.
Hab ich auch nicht, auch ganz ohne MAC. Auch nur mit DAC kann man nicht
einfach so überall hinschreiben, oder einfach so Root werden.
Der Punkt ist: Er darf gerne, zB. über eine unentdeckte Sicherheitslücke, ›root‹ werden.
Interessiert nicht im Geringsten.
Als ›root‹ hat er in diesem Kontext keinerlei zusätzlichen Rechte.
Aber das hier führt in eine völlig andere Richtung als der Thread.
Außerdem würd ich unter Windows anstelle von Kommandozeilenwerkzeugen
eher so etwas wie FileZilla, WinSCP oder vor allem Moba Xterm empfehlen.
Ich bevorzuge den BitWise SSH-Clienten (https://bitvise.com/ssh-client).
Der kann so ziemlich alles was ich zur Wartung/Administration meiner
headless Linuxsysteme brauche. Sehr angenehm ist das ich über diesen
Clienten die Dateien auf den Linuxsystemen direkt mit PSPad komfortabel
editieren kann.
Das scheint so etwas Ähnliches wie Moba XTerm zu sein mit dem Vorzug, daß der Client auch für kommerzielle und produktive Zwecke kostenlos zu sein scheint. Danke für den Hinweis, ich werde meinen Windows-Kollegen eine Evaluation der Software empfehlen.
Und - jetzt auch ohne neue Lizenkosten - als windows Dreingabe..., die
Lösung habe ich gesucht!
Eigentlich ist die WSL2 eine Linux VM, Linux kommt nicht von Microsoft,
da braucht man ihnen keine Kredits für zu geben.
Und der Zugriff auf die WSL2 nutzt das P9 Protocol, das kommt von Plan9.
Es ist also nicht so, dass Windows seit der WSL2 ext4 Dateisysteme lesen
könnte. Stattdessen mountet die Linux VM das Ext4 Laufwerk in seinem VFS
Tree, und auf den greift Windows als P9 Netzlaufwerk zu.
Das ist nicht korrekt - der mount in Linux reicht nicht - ich muss vorher einen "bind" aus der Windows Powershell heraus machen. Erst wenn der erfolgreich ist, klappt der mount aus Ubuntu!
Aber das ist nun völliges OffTopic an dieser Stelle. Ist ja im Raspi-Forum bestens beschrieben und funzt - habe ich selbst getestet.
Das ist nicht korrekt - der mount in Linux reicht nicht - ich muss
vorher einen "bind" aus der Windows Powershell heraus machen.
Es ist korrekt.
Klar muss man ein Gerät erstmal der VM verfügbar machen, bevor man es darin verwenden kann (also hier das bind zeugs). Aber das macht was ich gesagt habe nicht falsch. Ich würde sogar soweit gehen zu behaupten, dass es für mein Argument irrelevant ist.
Die Funktionen bigalloc, journal_dev, meta_bg,
inline_data werden von Linux File Systems für Windows von
Paragon Software momentan noch nicht unterstützt.
Vielleicht kann man die inkompatiblen Funktionen mit "tune2fs"
abschalten? Scheint ja nichts lebensnotwendiges zu sein.
Ich meine, das geht nicht. Also tar -c, mke2fs, tar -x
fchk
Laut Raspberry-Forum kann man das störende Feature sogar online löschen.
Das ist nicht korrekt - der mount in Linux reicht nicht - ich muss
vorher einen "bind" aus der Windows Powershell heraus machen.
Es ist korrekt.
Klar muss man ein Gerät erstmal der VM verfügbar machen, bevor man es
darin verwenden kann (also hier das bind zeugs). Aber das macht was ich
gesagt habe nicht falsch. Ich würde sogar soweit gehen zu behaupten,
dass es für mein Argument irrelevant ist.
Wenn ich 'mal schnell auf die Karte (ext4) unter windows / Ubuntu zugreifen möchte, muss ich immer zwei Dinge ausführen - den BIND unter Powershell und den Mount unter Ubuntu. Wenn Du Dich in der Ubuntu Umgebung befindest und lediglich den mount machst, siehst du die Partition nicht - weder unter Ubuntu, noch unter windows.
Insofern kommst Du um die Windows VM (WSL2) nicht herum. Die Ubuntu Aktivierung unter windows allein reicht nicht!
Mehr noch - der Linux Kernel liegt in der VM und kommt kommt somit von Microsoft!
Es ist also sehr wohl so, dass windows (native im OS - ohne Zusatzprodukte) erst mit der WSL2 ext4 lesen / schreiben kann!
WSL (allgemein) ist inzwischen ein von Microsoft offiziell unterstütztes Windows-Feature – es kommt direkt von Microsoft, ist dokumentiert und wird gepflegt!
WSL 2 ist die „neue“ Generation davon (mit echtem Linux-Kernel und besserer Performance) und ist bei aktuellen Windows-10-Versionen (ab 1903/1904 mit passendem Build) und unter Windows 11 verfügbar.
Also: ein offizielles Microsoft-Feature. WSL2 gehört also zu windows - ist standardmässig enthalten.
Engegengesetzt: Andere Third Party VMs (z.B. Virtualbox) hosten alles - also auch den Linux Kernel (innerhalb von Ubuntu mitgeliefert)!