Hi,
speefak schrieb:
> Das scheint dann ein Bug von rear-backup für amd64 Architekturen zu sein.
Sofern Du Dich nicht beim Experimentieren verhaspelt hast wuerde ich das
auch so sehen.
Gucken wir nochmal ueber die Fakten in diesem Thread:
https://bugzilla.redhat.com/show_bug.cgi?id=1462189
deutet an, dass genisoimage nicht korrekt auf -iso-level 3 reagiert,
xorrisofs das aber tut. (Man berichtet, dass die Verwendung von xorrisofs
das Problem in Fedora loest.)
Ich kann das leider nur bestaetigen:
Code: Alles auswählen
$ genisoimage -iso-level 3 -o test.iso KNOPPIX_V8.6-2019-08-08-EN.iso
I: -input-charset not specified, using utf-8 (detected in locale settings)
File KNOPPIX_V8.6-2019-08-08-EN.iso is larger than 4GiB-1.
-allow-limited-size was not specified. There is no way do represent this file size. Aborting.
(Repariert wird in genisoimage nix mehr. Auch wenn wir sehr betteln.)
Die Variable ISO_FILE_SIZE_LIMIT ist in offenbar auf den sehr konservativen
Wert 2147483648 (minus 1) gesetzt.
Das koennte die entscheidende Neuerung in Debian 12 sein. In der Version von
Debian 11 kommt ISO_FILE_SIZE_LIMIT nicht in der Defaultkonfiguration vor:
https://sources.debian.org/src/rear/2.6 ... ault.conf/
In der von Debian 12 schon:
https://sources.debian.org/src/rear/2.7 ... ault.conf/
http://lists.relax-and-recover.org/pipe ... 02437.html
deutet an, dass "rear recover" ein Problem mit Files >= 2 GiB in
ISO 9660 Filesystemen haben kann.
Das ist erstaunlich, weil zumindest in Linux und MS-Windows im Jahr 2020
wirklich keine aktuellen Probleme mit dieser Groesse auftreten sollten.
Aber gut, man kann ISO_FILE_SIZE_LIMIT aendern und dann probieren, ob die
Wiederherstellung eines Backups klappt.
(Wenn's nicht klappt ist rear einfach kein ernstzunehmendes Backupsystem.)
Du hast ISO_FILE_SIZE_LIMIT in /usr/share/rear/conf/default.conf geaendert
aber keine positive Wirkung gesehen. Erst als Du die Funktion
assert_ISO_FILE_SIZE_LIMIT gehackt hast um den Test abzuwuergen, gab es
Fortschritt.
Die Aenderung an ISO_FILE_SIZE_LIMIT scheint also nicht wirksam geworden
zu sein. Vielleicht wegen diesen Stueck Code:
https://sources.debian.org/src/rear/2.7 ... ?hl=23#L13
Code: Alles auswählen
# Enforce 2GiB ISO_FILE_SIZE_LIMIT when the MODULES array contains 'loaded_modules'
...
ISO_FILE_SIZE_LIMIT=2147483648
-------------------------------------------------------------------
Dann kamen Berichte von Dir, die noch Fragen offen lassen:
> EDIT 4.5 GB Scheint die max Archivgröße zu sein um es noch auf eine ISO zu bekommen.
Wie hat sich diese Grenze genau beim rear-Lauf geaeussert ?
Irgendwelche Originalmeldungen nach denen man im Code suchen koennte ?
> Wenn ich in der rear config xorriso als "isotool" angebe passt irgendwas
> mit der Syntax wieder nicht.
> xorriso/rear Fehler: unknown argument "-isolevel" "3" "."
Die Debian Codesuche findet das Wort "isolevel" nicht in rear, ebensowenig
wie "unknown argument". Ich sehe auch bei "xorriso" keinen speziellen
Test im Code, der -iso-level pruefen wuerde.
Du muesstest dringend rausfinden, wo diese Fehlermeldung herkommt.
Da koennte ein reparierbarer Bug sitzen.
> 2- xorriso Befehl mit Script "mappen"
xorriso laeuft auch im mkisofs-Emulationsmodus, wenn es als "mkisofs"
oder "genisoimage" aufgerufen wird.
Du koenntest also Dein /usr/bin/genisoimage umnennen (z.B. real_genisoimage)
und dann /usr/bin/xorriso auf /usr/bin/genisoimage kopieren oder einen
Softlink von /usr/bin/genisoimage nach xorriso legen.
Aber das hat Nachteile bei anderer Software, wie die Fedora-User
feststellen muessen, denen das nun so untergeschoben wird. Programme
beschweren sich ueber die Versionsnummer oder wollen Option -udf benutzen,
die xorrisofs nicht unterstuetzt.
Es waere also viel besser, wenn Du rear mit einem ehrlichen Aufruf von
xorrisofs zum Laufen bekaemst.
--------------------------------------------------------------------
Nach Deinem EDIT:
> xorriso -as mkisofs -iso-level 3 file.mkv -o test.iso
> xorriso 1.5.0 : RockRidge filesystem manipulator, libburnia project.
> ...
> funktioniert.
Das ist aber nicht die xorriso Version von Debian 12 (muesste 1.5.4 sein),
sondern die von Debian 10.
Nichtsdestotrotz ist der Erfolg auch bei aelteren Versionen zu erwarten.
> So ganz ist mir der Zusammenhang zwischen xorriso und mkisofs nicht klar.
> Ist xorriso kein eigenständiges Programm
EDIT:
xorriso ist voellig unabhaengig von mkisofs oder cdrecord. Es basiert auf den
Libraries libisofs, libburn und ist implementiert in libisoburn. Ein Version, die ihre
eigenen Libraries mitbringt, wird zeitgleich mit libisoburn als "GNU xorriso"
veroffentlicht. Debian benutzt aber die einzelnen Libraries.
EDIT Ende.
xorrisofs ist ein Eingabemodus des Programms xorriso. Der wird entweder durch
das xorriso Kommando "-as" "mkisofs" gestartet, oder wenn xorriso ueber einen
der Namen "xorrisofs", "mkisofs" oder "genisoimage" gestartet wird.
Dieser Modus aendert einige Grundeinstellungen (zB. das ISO Level), wenn sie
nicht schon durch vorherige xorriso Befehle geaendert wurden.
xorriso in seinem eigenen Kommandomodus erlaubt Level 3 als Grundeinstellung
und limitiert die Filegroesse auf 400 GiB - 200 KiB. Man kann das aendern
mit den Befehlen -compliance "iso_level=..." oder -file_size_limit.
Die man-Pages von xorriso und xorrisofs sind gefuerchtet fuer ihre Laenge
und beruechtigt dafuer, dass man die Loesung immer erst im Text findet, wenn
man sie sich muehsam zusammengeraetselt hat.
(Ich habe in 16 Jahren niemanden gefunden, der eine Anleitung aus Anwendersicht
schreiben wuerde.)
> und nutzt daher mkisofs
Nein. Nur die Namen von vielen Optionen und ggf. den Programmnamen.
man xorrisofs sagt ziemlich am Anfang:
Code: Alles auswählen
xorrisofs understands options of program mkisofs from cdrtools by Joerg
Schilling. Its implementation is part of program xorriso which shares
no source code with cdrtools.
Es sind spaeter einige Optionen dazugekommen, die Faehigkeiten von xorriso
im mkisofs-Modus bereitstellen. ZB. fuer die Produktion von ISOs, die vom
USB Stick booten.
Hauptnachteil von xorrisofs gegenueber mkisofs ist, dass die Optionen -udf
und -hfs nicht unterstuetzt werden. UDF finde ich persoenlich bloed und HFS
ist so tot, dass einige Linux Entwickler es aus dem Kernel schmeissen wollen.
Meine Motivation fuer xorriso ist Backup und die meiner User ist Booten.
--------------------------------------------------------------------
Und noch eine neue Botschaft waehrend ich hier tippe:
> Kann es vllt sein, dass eien bootbare ISO mit iso Level 3 nicht möglich ist
Die beiden haben wenig miteinander zu tun. Die bootenden Systeme muessen mit
Level 3 umgehen koennen oder duerfen sich nicht fuer die grossen Files
interessieren. Vielleicht muss man also die Files klein halten, die der
Bootloader selbst lesen oder an Linux weitergeben muss (initrd ?). Aber ein
fetter Datenfile, der erst von einem voll gebooteten Linux gelesen werden
soll, duerfte keine Probleme machen.
Level 3 wird im ISO nicht extra angekuendigt. Man merkt es erst, wenn man
auf einen grossen File mit mehr als einem Extent stoesst.
Have a nice day
Thomas
)
Es war so ein geniales tool für o.g. Zwecke, aber wenn durch die Verwendung von ebiso mit den 2 GB Einschränkungen jetzt nur noch max 2 GB bzw. 1,7 nach Abzug der 250mb iso boot Dateien als Backarchiv möglich sind, ist realex and recover de facto nicht mehr nutzbar 
