Hallo, Forum.
Einige der von mir erstellten MX-Snapshot-ISOs lassen sich nur als Live-system Booten, wenn ich das ISO aus Grub heraus direkt von seinem Ablageort auf der Festplatte boote.
In VB oder Qemu oder GnomeBoxes geht das nicht.
Auch nicht wenn ich das ISO mit MX-Live-USB-Erzeuger auf einem USB-Stick schreibe.
Nach dem das Bootmenü erscheint und dann den Bootvorgang einleitet, kommt erstmal die Meldung, dass nach dem Bootmedium gesucht wird, dann die Meldung, dass es nicht zu finden ist.
Kein Wunder, denn die Suche bezieht sich auf eine total irreführende Pfadangabe, die im der "grubc.fg" in der ISO hinterlegt ist.
Das Problem habe ich verursacht, ja.
Dazu ein andermal mehr, damit es jetzt nicht noch weiter von meiner Frage ablenkt.
Auf dem USB-Stick konnte ich diese Datei also bearbeiten und so korrigiert speichern.
Der USB-Stick bootet nun problemlos.
Na, dann mache ich das halt bei dem ISO auch so.
Und es könnte ja so einfach sein:
Dateimanager öffnen,
Zum ISO manövrieren,
rechter Mausklick auf das iso und aus dem Kontextmenü öffnen mit (Gnome-) Archivverwaltung öffnen.
( ARK oder Engrampha funktionieren zwar auch zu öffnen, reinschauen oder extrahieren aber nicht zum simplen Bearbeiten und aktualisieren.)
Also weiter mit (Gnome-) Archivverwaltung in der ISO-Struktur zu der "grub.cfg"
Mit Textbearbeitung ( featherpad ) Öffnen, Bearbeiten und auf speichern klicken.
Es erscheint die Rückfrage, ob das ISO mit der bearbeiteten Datei aktualisiert werden soll.
Ja, bitte.
es dauert einen Moment....
Fertig.
Die "neue" "grub.cfg" also öffnen und schauen, ob alles übernommen wurde ...
Ja. Supi.
ABER,
beim Aktualisieren des ISOs hat (Gnome-) Archivverwaltung wohl bemerkt, dass die ganze Dateisammlung grösser ist, als 4 GB.
Da kann (Gnome-) Archivverwaltung anscheinend, ganz old fashion, nicht mit umgehen,
und lässt eine "böse" Riesen-Datei, "linuxfx" mit 7,5 GB, einfach weg.
Operation gelungen, Patient tot.
Wie kann man diese übergrossen ISOs bearbeiten ohne dass sie zerstört werden.
Falls es noch keine Möglichkeit dafür gibt,
wäre es super, wenn MX ein entsprechendes Tool, ( das so einfach handhabbar ist wie (Gnome-) Archivverwaltung ) anfertigt und in den MX-Tools bereit stellt.
Danke.
Aber bis es so weit ist, hoffe ich auf eure Hilfe, damit ich die "grub.cfg" in mehreren MX-Snapshots reparieren kann.
MX-Snapshot-ISO - Boot-Optionen & boot-ISOs nachträglich bearbeiten ( grösser als 4GB ) [Solved]
MX-Snapshot-ISO - Boot-Optionen & boot-ISOs nachträglich bearbeiten ( grösser als 4GB )
Last edited by loik on Thu May 25, 2023 1:42 pm, edited 2 times in total.
Re: MX-Snapshot-ISO grösser als 4 GB nachträglich bearbeiten
Hallo loik,
vielleicht verstehe ich dich falsch, aber warum sollte QEMU nicht von einer ISO > 4GB booten können?
Ich habe einen MX-Schnappschuss (ca. 6.5 GB) auf einen USB-Stick gelagert, diese ISO dann im Virtual Machine Manager als IDE CDROM 1 ausgewählt (Pfad = /media/gn/Ventoy/MX-20230328_2155.iso) und in der Startreihenfolge, dass von der "CDROM" gebootet werden soll. Funktioniert ohne Probleme.
Reden wir also vielleicht aneinander vorbei?
Unabhängig davon, zum Bearbeiten von ISOs benutze ich gern isomaster
http://littlesvr.ca/isomaster/
da kann man z.B. Dateien aus ISOs entfernen oder hinzufügen. Gibt es in den Repos von MX.
viele Grüsse gosia
vielleicht verstehe ich dich falsch, aber warum sollte QEMU nicht von einer ISO > 4GB booten können?
Ich habe einen MX-Schnappschuss (ca. 6.5 GB) auf einen USB-Stick gelagert, diese ISO dann im Virtual Machine Manager als IDE CDROM 1 ausgewählt (Pfad = /media/gn/Ventoy/MX-20230328_2155.iso) und in der Startreihenfolge, dass von der "CDROM" gebootet werden soll. Funktioniert ohne Probleme.
Reden wir also vielleicht aneinander vorbei?
Unabhängig davon, zum Bearbeiten von ISOs benutze ich gern isomaster
http://littlesvr.ca/isomaster/
da kann man z.B. Dateien aus ISOs entfernen oder hinzufügen. Gibt es in den Repos von MX.
viele Grüsse gosia
Re: MX-Snapshot-ISO grösser als 4 GB nachträglich bearbeiten
Hallo, Gosia.
Danke für deine Antwort.
Ja, aneinander vorbei.
Die ISO größe macht den Virtuellen-Playern nichts aus.
Wohl aber, wenn sie beim Booten oder besser zum Booten auf die, in der ISO platzierte "grub.cfg" zu greifen und aus der eine Bootpfad herauslesen, der für das ISO gar nicht existiert.
Dann scheitert der Bootvorgang.
Bricht ab.
In der "grub.cfg" des ISOs ist nicht der Standart-Text eingetragen sondern ein Pfad von etwa 60 Zeichen, der zu iso X auf Festplatte Y führt.
Den Pfad habe ich erstellt, für eine ganz andere Situation, für die es auch funktioniert.
Der Pfad wurde nun aber versehentlich in die "boot.cfg" des ISOs übernommen.
Zwar weiß ich, was die Ursache des Fehlers ist, aber ich habe noch nicht verstanden wie er sich ( bei mehreren ISOs ) vollzogen hat.
Das wollte ich vorerst aber auch noch gar nicht klären.
Später.
Ein anderes Thema.
Jedenfalls muss dieser falsche Eintrag in der "boot.cfg" auf den Standarteintrag korrigiert werden.
Denn unabhängig von der ISO-Größe bootet es mit diesem falschen Eintrag nicht.
Bei der Größe ging es mir darum, dass sich das ISO mit der Archivverwaltung nicht unbeschädigt bearbeiten lässt.
Wohl weil es grösser ist, als die ISO-Spezifikation erlaubt.
Ich hatte IsoMaster schon geöffnet und kam damit nicht zurecht.
Wenn du mir sagst, dass sich mit IsoMaster, ISOs von 13 GB öffnen, bearbeiten und wieder speichern lassen, ohne das das ISO wegen eines Grössen-Konflikts kaputt geht, werde ich mich noch mal mit IsoMaster befassen.
Geht das nach deiner Erfahrung ?
Oder hat IsoMaster auch ein Grössenlimmit ?
Danke für deine Antwort.
Ja, aneinander vorbei.
Die ISO größe macht den Virtuellen-Playern nichts aus.
Wohl aber, wenn sie beim Booten oder besser zum Booten auf die, in der ISO platzierte "grub.cfg" zu greifen und aus der eine Bootpfad herauslesen, der für das ISO gar nicht existiert.
Dann scheitert der Bootvorgang.
Bricht ab.
In der "grub.cfg" des ISOs ist nicht der Standart-Text eingetragen sondern ein Pfad von etwa 60 Zeichen, der zu iso X auf Festplatte Y führt.
Den Pfad habe ich erstellt, für eine ganz andere Situation, für die es auch funktioniert.
Der Pfad wurde nun aber versehentlich in die "boot.cfg" des ISOs übernommen.
Zwar weiß ich, was die Ursache des Fehlers ist, aber ich habe noch nicht verstanden wie er sich ( bei mehreren ISOs ) vollzogen hat.
Das wollte ich vorerst aber auch noch gar nicht klären.
Später.
Ein anderes Thema.
Jedenfalls muss dieser falsche Eintrag in der "boot.cfg" auf den Standarteintrag korrigiert werden.
Denn unabhängig von der ISO-Größe bootet es mit diesem falschen Eintrag nicht.
Bei der Größe ging es mir darum, dass sich das ISO mit der Archivverwaltung nicht unbeschädigt bearbeiten lässt.
Wohl weil es grösser ist, als die ISO-Spezifikation erlaubt.
Ich hatte IsoMaster schon geöffnet und kam damit nicht zurecht.
Wenn du mir sagst, dass sich mit IsoMaster, ISOs von 13 GB öffnen, bearbeiten und wieder speichern lassen, ohne das das ISO wegen eines Grössen-Konflikts kaputt geht, werde ich mich noch mal mit IsoMaster befassen.
Geht das nach deiner Erfahrung ?
Oder hat IsoMaster auch ein Grössenlimmit ?
Re: MX-Snapshot-ISO grösser als 4 GB nachträglich bearbeiten
Hallo loik,
ob IsoMaster ein Grössenlimit hat weiss ich nicht, ich habe es bisher nur für ISOs von DVDs benutzt, die waren also maximal 4.7 GB gross. Zum Test habe ich jetzt mal die grub.cfg vom MX-Schnappschuss bearbeitet. Das hat funktioniert, die ISO bootet auch, aber es kommt dann eine Fehlermeldung, dass die Checksumme der ISO nicht stimmt. Es wird also irgendwo auf der ISO auch eine Checksumme abgespeichert (vielleicht SHA?) die dann mit der berechneten Checksumme der ISO übereinstimmen muss.
Insofern glaube ich, dass es nicht reicht, die grub.cfg zu bearbeiten oder auszutauschen, man muss wohl auch diese Checksumme neu berechnen und ebenfalls anpassen. Wie und wo weiss ich aber nicht.
viele Grüsse gosia
ob IsoMaster ein Grössenlimit hat weiss ich nicht, ich habe es bisher nur für ISOs von DVDs benutzt, die waren also maximal 4.7 GB gross. Zum Test habe ich jetzt mal die grub.cfg vom MX-Schnappschuss bearbeitet. Das hat funktioniert, die ISO bootet auch, aber es kommt dann eine Fehlermeldung, dass die Checksumme der ISO nicht stimmt. Es wird also irgendwo auf der ISO auch eine Checksumme abgespeichert (vielleicht SHA?) die dann mit der berechneten Checksumme der ISO übereinstimmen muss.
Insofern glaube ich, dass es nicht reicht, die grub.cfg zu bearbeiten oder auszutauschen, man muss wohl auch diese Checksumme neu berechnen und ebenfalls anpassen. Wie und wo weiss ich aber nicht.
viele Grüsse gosia
-
thebookkeeper
Re: MX-Snapshot-ISO grösser als 4 GB nachträglich bearbeiten
Für einen einzelnen User, der zu faul ist die Grub-Konfiguration seines Betriebssystems vor dem MX-Schnappschuss zu bereinigen? Normalerweise muss Keiner diese ISO's bearbeiten - das ist eigentlich exotische Vorgehensweise.loik wrote: Sun May 07, 2023 6:22 am... Wie kann man diese übergrossen ISOs bearbeiten ohne dass sie zerstört werden.
Falls es noch keine Möglichkeit dafür gibt,
wäre es super, wenn MX ein entsprechendes Tool, ( das so einfach handhabbar ist wie (Gnome-) Archivverwaltung ) anfertigt und in den MX-Tools bereit stellt ...
Wie dem auch sei, Cubic kann Live-ISO's bearbeiten => https://launchpad.net/cubic:
Cubic (Custom Ubuntu ISO Creator) is a GUI wizard to create a customized Live ISO image for Ubuntu and Debian † based distributions.
Cubic permits effortless navigation through the ISO customization steps and features an integrated virtual command line environment to customize the Linux file system. You can create new customization projects or modify existing projects ...
You do not have the required permissions to view the files attached to this post.
Re: MX-Snapshot-ISO grösser als 4 GB nachträglich bearbeiten
Hallo, Gosia.
Danke für s Testen.
Jetzt habe ich es noch mal Versucht mit einer SnapShot-ISO von 2,7 GB Größe und einer von 6,8 GB Größe.
Ich hatte die ISOs um Bearbeiten extra in mein Home-Verzeichnis kopiert, damit es nicht an Rechtekonflikten mit dem Dateisystem scheitert.
Beide ISOs habe ich auf die schnelle nur über den Dateimanager mit "Archivverwaltung" bearbeitet.
Beim Speichern und Aktualisieren des 2,7er-ISOs blieb "linuxfx" erhalten.
Beim Speichern und Aktualisieren des 6,8er-ISOs wurde "linuxfx" gelöscht.
Demnach stimmt hier meine Theorie zum zwanghaften Einhalten der ISO-Konformität bei "Archivverwaltung"
Mein Boot-Ergebnis bei dem Bearbeiteten 2,7er-ISO war ähnlich dem deinen.
Über unstimmige Checksumme wurde nicht geklagt.
Nur wurde auch kein Bootmedium gefunden.
Da hat "Archivverwaltung" wohl vergessen eine Boot-Markierung zu setzen.
Danke für s Testen.
Das hatte ich auch befürchtet, aber die ISO-Grösse und das damit Verbundene Löschen von "linuxfx" kam dem ja zuvor.
aber es kommt dann eine Fehlermeldung, dass die Checksumme der ISO nicht stimmt. Es wird also irgendwo auf der ISO auch eine Checksumme abgespeichert
Jetzt habe ich es noch mal Versucht mit einer SnapShot-ISO von 2,7 GB Größe und einer von 6,8 GB Größe.
Ich hatte die ISOs um Bearbeiten extra in mein Home-Verzeichnis kopiert, damit es nicht an Rechtekonflikten mit dem Dateisystem scheitert.
Beide ISOs habe ich auf die schnelle nur über den Dateimanager mit "Archivverwaltung" bearbeitet.
Beim Speichern und Aktualisieren des 2,7er-ISOs blieb "linuxfx" erhalten.
Beim Speichern und Aktualisieren des 6,8er-ISOs wurde "linuxfx" gelöscht.
Demnach stimmt hier meine Theorie zum zwanghaften Einhalten der ISO-Konformität bei "Archivverwaltung"
Mein Boot-Ergebnis bei dem Bearbeiteten 2,7er-ISO war ähnlich dem deinen.
Über unstimmige Checksumme wurde nicht geklagt.
Nur wurde auch kein Bootmedium gefunden.
Da hat "Archivverwaltung" wohl vergessen eine Boot-Markierung zu setzen.
Re: MX-Snapshot-ISO grösser als 4 GB nachträglich bearbeiten
Hallo, Bookkeeper.
Für einen einzelnen User, der zu faul ist...
Das hat eher mit Unwissenheit zu tun und nicht mit Bequemlichkeit.
Aber nun gab es einen Fehler.
Ich weiß an welcher Stelle er zu beheben ist, aber ich weiß nicht wie ich dran kommen soll.
Deshalb habe ich euch um Hilfe geragt.
Mein Vorschlag für, solche Situationen, in den MX-Tools, ein entsprechendes Werkzeug zu integrieren, welches suverän mit den außergewöhnlich großen MX-SnapShot-ISOs umgehen kann, war allgemeiner Natur.
Ich hatte nicht verlangt und erwartet, dass athock exlusiv für mich, jetzt so ein Tool angefertigt werden soll, damit ich meine Grub-Datei bearbeiten kann.
Wenn das so zu lesen war, habe ich mich schlecht ausgedrückt. Tut mir leid.
Ich halte es aber für eine gute Bereicherung der Tool-Sammlung.
Natürlich kann man auf andere Programme zurückgreifen oder, oder, oder
Aber man kann Grub auch über die Konsole Reparieren.
Und man kann das Bootmenü auch auf andere Weise gestalten, als mit den MX-Boot-Optionen.
Oder GPG-Schlüssel lassen sich auch von Hand und via Terminal aktualisieren.
Und doch stellt MX dafür extra Tools bereit, die das Computerleben an dieser Stelle einfacher machen.
Ein Tool für diese Sammlung vorzuschlagen, mit dem man übergroße MX-SnapShot-ISOs bearbeiten kann, ohne sie zu beschädigen, finde ich nicht vermessen.
Ich halte es eher für eine Bereicherung für alle.
Jedenfalls Danke, für den Tipp und den Link zu "cubic"
Leider hat es nicht geklappt zu installieren.
Weil die dpkg-Version in MX das neue Pack-Vormat nicht öffnen kann.
Da wurde in der Anleitung auch extra drauf hingewiesen.
https://github.com/PJ-Singh-001/Cubic/w ... erivatives
Man solle kurzzeitig auf die Sourcelist von "bookworm" umstellen,
um auf die aktuellere dpkg-Version zu aktualisieren.
Aber das ist schon daran gescheitert:
Wohl, weil in
nichts drinne ist, als ein Verweis auf
da es aber ein Verzeichnis und keine einzelne Datei ist, wusste ich nicht, wie ich den Befehl umstellen muss.
Vielleicht auch ganz gut so.
Geheuer war mir das eh nicht.
Und bei der nachträglichen Inspektion des System, von dem das SnapShot erstellt wurde, konnte ich keine Unreinheiten finden, in
/boot
/boot/Grub
/etc/default/grub.d
/etc/grub.d
Aber, wo das grad schreibe, fällt mir auf, ich habe übersehen
/etc/default/grub
Da könnte ich natürlich pfündig werden.
Gibt es noch irgendwelche Orte, die ich kontrollieren sollte ?
Für einen einzelnen User, der zu faul ist...
Das hat eher mit Unwissenheit zu tun und nicht mit Bequemlichkeit.
So ging mir dass in den letzten 5 Jahren auch bei dem ca. 60 SnapShots, die ich erstellt habe..... Normalerweise muss Keiner diese ISO's bearbeiten - das ist eigentlich exotische Vorgehensweise....
Aber nun gab es einen Fehler.
Ich weiß an welcher Stelle er zu beheben ist, aber ich weiß nicht wie ich dran kommen soll.
Deshalb habe ich euch um Hilfe geragt.
Mein Vorschlag für, solche Situationen, in den MX-Tools, ein entsprechendes Werkzeug zu integrieren, welches suverän mit den außergewöhnlich großen MX-SnapShot-ISOs umgehen kann, war allgemeiner Natur.
Ich hatte nicht verlangt und erwartet, dass athock exlusiv für mich, jetzt so ein Tool angefertigt werden soll, damit ich meine Grub-Datei bearbeiten kann.
Wenn das so zu lesen war, habe ich mich schlecht ausgedrückt. Tut mir leid.
Ich halte es aber für eine gute Bereicherung der Tool-Sammlung.
Natürlich kann man auf andere Programme zurückgreifen oder, oder, oder
Aber man kann Grub auch über die Konsole Reparieren.
Und man kann das Bootmenü auch auf andere Weise gestalten, als mit den MX-Boot-Optionen.
Oder GPG-Schlüssel lassen sich auch von Hand und via Terminal aktualisieren.
Und doch stellt MX dafür extra Tools bereit, die das Computerleben an dieser Stelle einfacher machen.
Ein Tool für diese Sammlung vorzuschlagen, mit dem man übergroße MX-SnapShot-ISOs bearbeiten kann, ohne sie zu beschädigen, finde ich nicht vermessen.
Ich halte es eher für eine Bereicherung für alle.
Jedenfalls Danke, für den Tipp und den Link zu "cubic"
Leider hat es nicht geklappt zu installieren.
Weil die dpkg-Version in MX das neue Pack-Vormat nicht öffnen kann.
Da wurde in der Anleitung auch extra drauf hingewiesen.
https://github.com/PJ-Singh-001/Cubic/w ... erivatives
Man solle kurzzeitig auf die Sourcelist von "bookworm" umstellen,
um auf die aktuellere dpkg-Version zu aktualisieren.
Aber das ist schon daran gescheitert:
Code: Select all
root@mx# cp sources.list.original sources.list
cp: der Aufruf von stat für 'sources.list.original' ist nicht möglich: Datei oder Verzeichnis nicht gefundenCode: Select all
/etc/apt/sources.list
Code: Select all
/etc/apt/sources.list.d
Vielleicht auch ganz gut so.
Geheuer war mir das eh nicht.
Das habe ich bei all den SnapShots der Vergangenheit auch noch nie machen müssen.... die Grub-Konfiguration seines Betriebssystems vor dem MX-Schnappschuss zu bereinigen ...
Und bei der nachträglichen Inspektion des System, von dem das SnapShot erstellt wurde, konnte ich keine Unreinheiten finden, in
/boot
/boot/Grub
/etc/default/grub.d
/etc/grub.d
Aber, wo das grad schreibe, fällt mir auf, ich habe übersehen
/etc/default/grub
Da könnte ich natürlich pfündig werden.
Gibt es noch irgendwelche Orte, die ich kontrollieren sollte ?
Re: MX-Snapshot-ISO grösser als 4 GB nachträglich bearbeiten
Nee.
/etc/default/grub
und
/etc/default/grub.ucf-dist
Sind auch sauber.
Ein Eintag aus 60 Zeichen in auffallender Gross-und-Kleinschreibung mit vielen Binde- und Unterstrichen ist auch nicht zu übersehen.
( so-etwa____4____Unterstriche__Hinter-ein-ander____um __Lücken__dar-zu-stellen__mit__Zahlen__2023-05--08__NICHT_zu-übersehen )
/etc/default/grub
und
/etc/default/grub.ucf-dist
Sind auch sauber.
Ein Eintag aus 60 Zeichen in auffallender Gross-und-Kleinschreibung mit vielen Binde- und Unterstrichen ist auch nicht zu übersehen.
( so-etwa____4____Unterstriche__Hinter-ein-ander____um __Lücken__dar-zu-stellen__mit__Zahlen__2023-05--08__NICHT_zu-übersehen )
-
thebookkeeper
Re: MX-Snapshot-ISO grösser als 4 GB nachträglich bearbeiten
Ich hatte den Befehl umgestellt für das ganze Verzeichnis, aber dann wird das MX-Repo auch umbenannt und das wird problematisch.loik wrote: Mon May 08, 2023 12:16 pm...da es aber ein Verzeichnis und keine einzelne Datei ist, wusste ich nicht, wie ich den Befehl umstellen muss.Code: Select all
/etc/apt/sources.list.d
...
Glück gehabt, dass das gescheitert ist, weil ich hab diese "bookworm-dpkg-Sache" mal getestet:loik wrote: Mon May 08, 2023 12:16 pm...
Leider hat es nicht geklappt zu installieren.
Weil die dpkg-Version in MX das neue Pack-Vormat nicht öffnen kann.
Da wurde in der Anleitung auch extra drauf hingewiesen.
https://github.com/PJ-Singh-001/Cubic/w ... erivatives
Man solle kurzzeitig auf die Sourcelist von "bookworm" umstellen,
um auf die aktuellere dpkg-Version zu aktualisieren.
Aber das ist schon daran gescheitert:...Code: Select all
root@mx# cp sources.list.original sources.list cp: der Aufruf von stat für 'sources.list.original' ist nicht möglich: Datei oder Verzeichnis nicht gefunden
Vielleicht auch ganz gut so.
Geheuer war mir das eh nicht ...
Code: Select all
thebookkeeper@mx-dell:~
$ sudo apt install dpkg
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut… Fertig
Statusinformationen werden eingelesen… Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
bluefish-data bluefish-plugins dvdauthor gir1.2-nm-1.0 gparted-common iptables libcolorhug2
libenca0 libept1.6.0 libextutils-pkgconfig-perl libgdata-common libgdata22 libgoa-1.0-0b
libgoa-1.0-common libgtkspell3-3-0 libgucharmap-2-90-7 libgusb2 libip6tc2 libjsoncpp24
libldap-2.5-0 libldb2 libmbim-glib4 libmbim-proxy libmm-glib0 libmozjs-78-0 libndp0
libnl-route-3-200 libnm0 libnma-common libnma0 libopenshot-audio7 libopenshot19 libqmi-glib5
libqmi-proxy libqrtr-glib0 libteamdctl0 libtevent0 libvorbisidec1 pkg-config pptp-linux
python3-dnspython python3-ldb python3-talloc python3-tdb samba-common ufw wpasupplicant
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
Die folgenden zusätzlichen Pakete werden installiert:
binutils binutils-common binutils-x86-64-linux-gnu bluefish-plugins dbus dbus-bin dbus-daemon
dbus-session-bus-common dbus-system-bus-common dbus-x11 fuse3 gcc-12-base gir1.2-pango-1.0
gnome-keyring gobject-introspection gparted-common gvfs gvfs-common gvfs-daemons gvfs-fuse
gvfs-libs hplip hplip-data libaom3 libapt-pkg-perl libatkmm-1.6-1v5 libaudio-flac-header-perl
libaudio-scan-perl libavcodec59 libavdevice59 libavfilter8 libavformat59 libavutil57
libb-hooks-op-check-perl libbinutils libboost-python1.74.0 libboost-thread1.74.0 libc-bin
libc-dev-bin libc-l10n libc6 libc6:i386 libc6-dev libcaca0 libcairo-gobject-perl
libcairo-gobject2 libcairo-perl libcairo2 libcairomm-1.0-1v5 libcjson1 libcodec2-1.0
libctf-nobfd0 libctf0 libcurses-perl libdav1d6 libdbus-1-3 libdevel-callchecker-perl
libdrm-common libdrm2 libffi8 libflac12 libfreetype6 libfuse3-3 libgcrypt20 libgdata22 libgdbm6
libgirepository-1.0-1 libgjs0g libglib-object-introspection-perl libglib-perl libglib2.0-0
libglib2.0-bin libglibmm-2.4-1v5 libgmp10 libgnutls30 libgprofng0 libgtkmm-3.0-1v5 libharfbuzz0b
libhpmud0 libhtml-parser-perl libhwy1 libjansson4 libjsoncpp25 libjxl0.7 liblcms2-2
libldap-2.5-0 libldb2 liblerc4 liblist-moreutils-xs-perl liblocale-gettext-perl liblzma5
libmbedcrypto7 libmbim-glib4 libmbim-proxy libmm-glib0 libmozjs-102-0 libmpg123-0 libmujs2
libnet-dbus-perl libnet-ssleay-perl libnewt0.52 libnm0 libnma-common libnma0 libopenshot-audio8
libopenshot21 libpango-1.0-0 libpangocairo-1.0-0 libpangoft2-1.0-0 libpangomm-1.4-1v5
libpangoxft-1.0-0 libparams-classify-perl libperl5.36 libpipewire-0.3-0 libplacebo208
libpostproc56 libpython3-stdlib libpython3.11 libpython3.11-minimal libpython3.11-stdlib
libqmi-glib5 libqmi-proxy libqpdf29 libqrtr-glib0 libraqm0 librav1e0 librist4 librubberband2
libsane-hpaio libsasl2-2 libsasl2-modules-db libsixel1 libsnappy1v5 libsnmp40 libsocket6-perl
libspa-0.2-modules libsqlite3-0 libsrt1.5-gnutls libssl3 libstdc++6 libsvtav1enc1 libswresample4
libswscale6 libtalloc2 libtdb1 libterm-readkey-perl libtevent0 libtext-charwidth-perl
libtext-iconv-perl libtiff6 libvpx7 libwayland-client0 libwayland-egl1 libwbclient0 libwebp7
libwebpdemux2 libwebpmux3 libx264-164 libx265-199 libxapian30 libxml-parser-perl libzimg2
libzstd1 locales mpv onboard perl perl-base perl-modules-5.36 perl-openssl-defaults
printer-driver-hpcups python3 python3-apt python3-bluez python3-brotli python3-cairo
python3-cffi-backend python3-cups python3-dbus python3-deprecation python3-distutils
python3-gattlib python3-gi python3-gi-cairo python3-ldb python3-lib2to3 python3-libapparmor
python3-lxml python3-markupsafe python3-minimal python3-openshot python3-packaging
python3-pikepdf python3-pil python3-psutil python3-py python3-pycryptodome python3-pyqt5.sip
python3-pyxattr python3-reportlab-accel python3-talloc python3-tdb python3-zmq python3.11
python3.11-minimal rpcsvc-proto samba-common systemd-sysv tlp
Die folgenden Pakete werden ENTFERNT:
bluefish blueman cgmanager colord dbus-user-session gparted gufw gvfs-backends libcgmanager0
libnih-dbus1 libnih1 libpam-systemd libsmbclient light-locker lightdm modem-manager-gui
modemmanager mplayer mx-pkexec mx-samba-config network-manager network-manager-gnome
network-manager-openconnect network-manager-openconnect-gnome network-manager-openvpn
network-manager-openvpn-gnome network-manager-pptp network-manager-vpnc policykit-1
policykit-1-gnome python3-devedeng python3-samba python3-smbc samba samba-common-bin samba-libs
synaptic systemd-shim sysvinit-core thunar-shares-plugin tlp-rdw
Die folgenden NEUEN Pakete werden installiert:
dbus-bin dbus-daemon dbus-session-bus-common dbus-system-bus-common gcc-12-base libaom3
libavcodec59 libavdevice59 libavfilter8 libavformat59 libavutil57 libcjson1 libcodec2-1.0
libdav1d6 libffi8 libflac12 libgprofng0 libhwy1 libjsoncpp25 libjxl0.7 libldap-2.5-0 liblerc4
libmbedcrypto7 libmozjs-102-0 libmujs2 libopenshot-audio8 libopenshot21 libperl5.36
libpipewire-0.3-0 libplacebo208 libpostproc56 libpython3.11 libpython3.11-minimal
libpython3.11-stdlib libqpdf29 libqrtr-glib0 libraqm0 librav1e0 librist4 libsixel1
libspa-0.2-modules libsrt1.5-gnutls libssl3 libsvtav1enc1 libswresample4 libswscale6 libtiff6
libvpx7 libwebp7 libx264-164 libx265-199 libzimg2 perl-modules-5.36 python3-cffi-backend
python3-deprecation python3-packaging python3-py python3.11 python3.11-minimal rpcsvc-proto
systemd-sysv
Die folgenden Pakete werden aktualisiert (Upgrade):
binutils binutils-common binutils-x86-64-linux-gnu bluefish-plugins dbus dbus-x11 dpkg fuse3
gir1.2-pango-1.0 gnome-keyring gobject-introspection gparted-common gvfs gvfs-common
gvfs-daemons gvfs-fuse gvfs-libs hplip hplip-data libapt-pkg-perl libatkmm-1.6-1v5
libaudio-flac-header-perl libaudio-scan-perl libb-hooks-op-check-perl libbinutils
libboost-python1.74.0 libboost-thread1.74.0 libc-bin libc-dev-bin libc-l10n libc6 libc6:i386
libc6-dev libcaca0 libcairo-gobject-perl libcairo-gobject2 libcairo-perl libcairo2
libcairomm-1.0-1v5 libctf-nobfd0 libctf0 libcurses-perl libdbus-1-3 libdevel-callchecker-perl
libdrm-common libdrm2 libfreetype6 libfuse3-3 libgcrypt20 libgdata22 libgdbm6
libgirepository-1.0-1 libgjs0g libglib-object-introspection-perl libglib-perl libglib2.0-0
libglib2.0-bin libglibmm-2.4-1v5 libgmp10 libgnutls30 libgtkmm-3.0-1v5 libharfbuzz0b libhpmud0
libhtml-parser-perl libjansson4 liblcms2-2 libldb2 liblist-moreutils-xs-perl
liblocale-gettext-perl liblzma5 libmbim-glib4 libmbim-proxy libmm-glib0 libmpg123-0
libnet-dbus-perl libnet-ssleay-perl libnewt0.52 libnm0 libnma-common libnma0 libpango-1.0-0
libpangocairo-1.0-0 libpangoft2-1.0-0 libpangomm-1.4-1v5 libpangoxft-1.0-0
libparams-classify-perl libpython3-stdlib libqmi-glib5 libqmi-proxy librubberband2 libsane-hpaio
libsasl2-2 libsasl2-modules-db libsnappy1v5 libsnmp40 libsocket6-perl libsqlite3-0 libstdc++6
libtalloc2 libtdb1 libterm-readkey-perl libtevent0 libtext-charwidth-perl libtext-iconv-perl
libwayland-client0 libwayland-egl1 libwbclient0 libwebpdemux2 libwebpmux3 libxapian30
libxml-parser-perl libzstd1 locales mpv onboard perl perl-base perl-openssl-defaults
printer-driver-hpcups python3 python3-apt python3-bluez python3-brotli python3-cairo
python3-cups python3-dbus python3-distutils python3-gattlib python3-gi python3-gi-cairo
python3-ldb python3-lib2to3 python3-libapparmor python3-lxml python3-markupsafe python3-minimal
python3-openshot python3-pikepdf python3-pil python3-psutil python3-pycryptodome
python3-pyqt5.sip python3-pyxattr python3-reportlab-accel python3-talloc python3-tdb python3-zmq
samba-common tlp
149 aktualisiert, 61 neu installiert, 41 zu entfernen und 1345 nicht aktualisiert.
Es müssen 124 MB an Archiven heruntergeladen werden.
Nach dieser Operation werden 75,5 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren? [J/n] Unter MX-Werkzeuge gibt's MX-Boot-Options, dieses Tool bearbeitet /etc/default/grubloik wrote: Mon May 08, 2023 12:16 pm......... die Grub-Konfiguration seines Betriebssystems vor dem MX-Schnappschuss zu bereinigen ...
Aber, wo das grad schreibe, fällt mir auf, ich habe übersehen
/etc/default/grub
...
Aber nach Änderungen in /etc/default/grub muss man ausführen im Terminal:
Code: Select all
sudo update-grubDie grub.cfg selbst, soll man im laufenden System nicht direkt ändern (außer sie ist eh' versaut).
Derartiges hast Du in der grub.cfg der MX-Schnappschuss-ISO ?loik wrote: Mon May 08, 2023 12:37 pm...
Ein Eintag aus 60 Zeichen in auffallender Gross-und-Kleinschreibung mit vielen Binde- und Unterstrichen ist auch nicht zu übersehen.
( so-etwa____4____Unterstriche__Hinter-ein-ander____um __Lücken__dar-zu-stellen__mit__Zahlen__2023-05--08__NICHT_zu-übersehen )
Zeig doch mal:
Code: Select all
cat /boot/grub/grub.cfgRe: MX-Snapshot-ISO grösser als 4 GB nachträglich bearbeiten
Moin.
Ich verstehe nicht, warum das heute immer noch so kompliziert gemacht werden muss, wenn es wichtig ist Spezial-Abhängigkeiten zu berücksichtigen.
Warum nicht einfach als AppImage bereitstellen, wo alles Notwendige bereits im Container enthalten ist.
Für die Bastelbegeisterten kann man dann ja trotzdem Sourcecodes zum Kompilieren anbieten.
Aber, warum einfach, wenn es auch kompliziert geht.
( ich weiß wovon ich spreche
)
Weil ich es dort eingetragen habe.
Bis zu 20 solcher Einträge befinden sich in jeder "40_custom" auf jedem System.
Die Systeme befinden sich auf Multibooplatten. Bis zu 10 Systeme.
Die Systeme habe jeweils bis zu 10 Kernel an Bord. Ich kann halt nix wegschmeißen.
Die
von diesen Systemen hat entsprechend sehr viele Einträge, allein schon wegen der OS-Prober-Schleife.
Den Kladderadatsch werde ich hier nicht Posten. Das ist nicht Zielführend.
Wenn ich das MX-SnapShot-Live-Iso am Laufen habe, dann zeigt
nichts an, weil es die Datei dort nicht gibt.
Ist halt ein Live-System.
Aber es gibt sie in der Dateistrucktur der ISO.
Also, wenn man den USB-Stick mit einem Dateimanager öffnet oder
Eine ISO-Datei mit der Archivverwaltung öffnet, dann findet man so einen Irreführenden Eintrag in
Ein Eintrag in diesen Datei sieht etwa so aus
( aus Syslinux )
In allen Drei Dateien der Gleiche Pfad, der auf ein ISO verweist, welches nicht dem entspricht, welches gerade gebootet werden soll.
Wenn ich in diesen Dateien die Einträge entferne, und gegen die Default-Einträge ersetze, wie das beim USB-Stick möglich ist, dann bootet dieser auch wieder, wie beabsichtigt.
Und dass würde ich gerne auch bei mehreren bereits erstellten ISOs machen, um sie in den VMs booten zu können.
Aber es scheitert daran, dass die ISOs beim Bearbeiten unbootbar beschädigt werden.
Entweder wegen der Größen-Barriere oder/und an der anschließend fehlenden Bootmarkierung oder der nicht mehr konformen Checksumme.
Natürlich gilt es für die Zukunft zu vermeiden, dass diese falschen Einträge entstehen.
Aber in Moment interessiert mich, wie ich diese ISOs sicher bearbeiten kann.
Hatte ich schon vermutet.Glück gehabt, dass das gescheitert ist, weil ich hab diese "bookworm-dpkg-Sache" mal getestet:
Ich verstehe nicht, warum das heute immer noch so kompliziert gemacht werden muss, wenn es wichtig ist Spezial-Abhängigkeiten zu berücksichtigen.
Warum nicht einfach als AppImage bereitstellen, wo alles Notwendige bereits im Container enthalten ist.
Für die Bastelbegeisterten kann man dann ja trotzdem Sourcecodes zum Kompilieren anbieten.
Aber, warum einfach, wenn es auch kompliziert geht.
( ich weiß wovon ich spreche
)Etwas derartiges habe ich bei jedem voll installierten System inEin Eintag aus 60 Zeichen in auffallender Gross-und-Kleinschreibung mit vielen Binde- und Unterstrichen ist auch nicht zu übersehen.
( so-etwa____4____Unterstriche__Hinter-ein-ander____um __Lücken__dar-zu-stellen__mit__Zahlen__2023-05--08__NICHT_zu-übersehen )
Derartiges hast Du in der grub.cfg der MX-Schnappschuss-ISO ?
Code: Select all
/etc/grub.d/40_customWeil ich es dort eingetragen habe.
Bis zu 20 solcher Einträge befinden sich in jeder "40_custom" auf jedem System.
Die Systeme befinden sich auf Multibooplatten. Bis zu 10 Systeme.
Die Systeme habe jeweils bis zu 10 Kernel an Bord. Ich kann halt nix wegschmeißen.
Die
Code: Select all
/boot/grub/grub.cfgDen Kladderadatsch werde ich hier nicht Posten. Das ist nicht Zielführend.
Wenn ich das MX-SnapShot-Live-Iso am Laufen habe, dann zeigt
Code: Select all
cat /boot/grub/grub.cfgIst halt ein Live-System.
Aber es gibt sie in der Dateistrucktur der ISO.
Also, wenn man den USB-Stick mit einem Dateimanager öffnet oder
Eine ISO-Datei mit der Archivverwaltung öffnet, dann findet man so einen Irreführenden Eintrag in
Code: Select all
/boot/isolinux/isolinux.cfg
/boot/syslinux/syslinux.cfg
und eben auch in
/boot/grub/grub.cfg( aus Syslinux )
Code: Select all
#--------------------------------------------------------------------
# This is the isolinux.cfg and/or syslinux.cfg file
# It controls the main menu in the bootloader on the live system.
# You can edit it to change the main bootloader menu on a LiveUSB.
# If you are not careful you can break the live system and prevent
# it from booting.
#--------------------------------------------------------------------
UI gfxboot gfx-cpio readme.msg
timeout 600
default live
MENU TITLE Welcome to MX-21.3_386 (Wildflower)
LABEL live
MENU LABEL MX-21.3_386 (März 18, 2023)
KERNEL /antiX/vmlinuz
APPEND bootuuid=461626C414D1DC4D fromiso=/so-etwa____4____Unterstriche__Hinter-ein-ander____um __Lücken__dar-zu-stellen__mit__Zahlen__2023-05--08__NICHT_zu-übersehen/MX-21-3_32bit_XFCE-KDE_snapshot-20230318_1144.iso lang=de quiet splash
INITRD /antiX/initrd.gz
LABEL harddisk
MENU LABEL Boot_from_Hard_Disk
COM32 chain.c32
APPEND hd1
LABEL memtest
MENU LABEL Memory_Test
KERNEL /boot/memtest
LABEL grub
MENU LABEL Switch_to_Grub_Bootloader
KERNEL /boot/grub/i386-pc/lnxboot.img
INITRD /boot/grub/i386-pc/core.img
Wenn ich in diesen Dateien die Einträge entferne, und gegen die Default-Einträge ersetze, wie das beim USB-Stick möglich ist, dann bootet dieser auch wieder, wie beabsichtigt.
Und dass würde ich gerne auch bei mehreren bereits erstellten ISOs machen, um sie in den VMs booten zu können.
Aber es scheitert daran, dass die ISOs beim Bearbeiten unbootbar beschädigt werden.
Entweder wegen der Größen-Barriere oder/und an der anschließend fehlenden Bootmarkierung oder der nicht mehr konformen Checksumme.
Natürlich gilt es für die Zukunft zu vermeiden, dass diese falschen Einträge entstehen.
Aber in Moment interessiert mich, wie ich diese ISOs sicher bearbeiten kann.