[solved] Relax and Recover - D12 <2GB Error and lib not found

Du hast Probleme mit Deinem eMail-Programm, Webbrowser oder Textprogramm? Dein Lieblingsprogramm streikt?
Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: Relax and Recover - Bugs - läuft das bei jmd unter D12 ?

Beitrag von speefak » 21.07.2023 13:29:54

Isofilesiuze config habe ich nach dem test wieder auf default gesetzt

Code: Alles auswählen

cat /usr/share/rear/conf/default.conf | grep ISO_FILE_SIZE_LIMIT=
# can be skipped with ISO_FILE_SIZE_LIMIT=0 in etc/rear/local.conf
ISO_FILE_SIZE_LIMIT=2147483648
"xorrisofs das aber tut. (Man berichtet, dass die Verwendung von xorrisofs
das Problem in Fedora loest.)"
=> ja für fedora - für debian nicht so ganz :/

"Das ist erstaunlich, weil zumindest in Linux und MS-Windows im Jahr 2020
wirklich keine aktuellen Probleme mit dieser Groesse auftreten sollten."
Genau das dachte ich mir auch und hatte da erst gar nicht mit gerechnet - Stichwort "Downgrade der technischen Möglichkeiten bei OS Upgrade"

"Aber gut, man kann ISO_FILE_SIZE_LIMIT aendern und dann probieren, ob die
Wiederherstellung eines Backups klappt."
=> das werd ich gleich nochmal testen ( in der /usr/share/rear/conf/default.conf und der /etc/rear/local.conf

"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:"
=> Das ist genau mein Problem. Die Scripte nutzen übergebene Variablen und daher ist sehr schwierig die entsprechende Variable an der entsprechenden Stelle in der entsprechenden Skript Datei zu finden. eine Änderung der Skript Dateien vermeide ich auch solange es geht ( paket updates, Fehler anderer Programme/Funktionen ).

"Wie hat sich diese Grenze genau beim rear-Lauf geaeussert ?
Irgendwelche Originalmeldungen nach denen man im Code suchen koennte ?"
=> Gute Frage, das is mehr als 1 Jahr her :roll:

"Du muesstest dringend rausfinden, wo diese Fehlermeldung herkommt.
Da koennte ein reparierbarer Bug sitzen.
> 2- xorriso Befehl mit Script "mappen""
=> Das war nur ein Versuch, den ich aufgrund der vielen Parameter gleich wieder aufgeben habe. Bei Befehlen die nur eine handvoll Parameter haben kann man ein "Syntaxmapper" schreiben. für nmap, xorriso, apt und co ist das sinnlos.

"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."
=> das wäre die Holzhammermethode. Ggf könnte man ein Skript schreiben, was nur bei dem Aufruf von rear die Programmsubstitution temporär vornimmt. Optimal ist das aber auch nicht :cry:

"Das ist aber nicht die xorriso Version von Debian 12 (muesste 1.5.4 sein),..."
=> korrekt das war ein test unter D10, xorriso 1.5.4 ists in D12. Test geht aber bei beiden OS Versionen

"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."
=> Ahhh ... Also xorriso Configoptionen und kein eigenständiger Programmaufruf von mkisofs durch xorriso ?!

"Die manPages von xorriso und xorrisofs sind gefuerchtet fuer ihre Laenge"
Das habe in den letzten Tagen auch schon festgestellt 8O

"Hauptnachteil von xorrisofs gegenueber mkisofs ist, dass die Optionen -udf
und -hfs nicht unterstuetzt werden. UDF finde ich persoenlich bloed und HFS"
=> ergo irrelevant :)

Mit folgender Konfiguration läuft es (etc/rear/local.conf) (11GB OS auf :

Code: Alles auswählen

		OUTPUT=ISO
		ISO_DIR=/mnt/speefak@192.168.1.20_ReaR/ReaR_Backups
		ISO_PREFIX="blackbox-gui-gnome_2023-07-21-131028_OS"
		OUTPUT_URL=null
		BACKUP=NETFS
		BACKUP_URL="iso:///backup"

	

		BACKUP_PROG_COMPRESS_OPTIONS=( --use-compress-program=pigz )
		REQUIRED_PROGS+=( pigz )

		USER_INPUT_TIMEOUT=30

		AUTORESIZE_PARTITIONS=true
#		AUTORESIZE_PARTITIONS=( /dev/sda3 )
#		AUTORESIZE_EXCLUDE_PARTITIONS=( /dev/sda2 )

		BACKUP_PROG_EXCLUDE=( '/home/rear_tmp/*' '/mnt/*' '/media/*' '/home/vbox/*' '/home/Archiv/*' '/home/vdr_recdir/*' '/home/.Trash*/*' '/var/tmp/*' '/var/lib/rear/output/*'  )

		MKISOFS_BIN=xorriso
		USE_XORRISO=true
Tests mit Debian 12 :

Code: Alles auswählen

used OS size: 8.1 GB
tar image size (lt rear output log ): 3.1 GB
isofile size: 3.6 GB
isofile tarimage ( tar file in isoimage): 3.3 GB
=> works
...
used OS size: 11,2 GB
tar image size (lt rear output log ): 5.4 GB
isofile size: 6.1 GB
isofile tarimage ( tar file in isoimage): 5.8 GB
=> works
...
Größeres Datenvolumen auf / kann ich nicht testen, da kein Platz mehr auf der Disk ist und der TMPDIR export beim Restore einen Fehler verursacht.

Sämtliche o.g. Änderungen an den rear Skripten habe ich rückgängig gemacht und in der /etc/rear/local.conf folgende Optionen gesetzt :

Code: Alles auswählen

MKISOFS_BIN=xorriso
USE_XORRISO=true
[code]

Damit scheint es zu laufen: ISO Backup und OS Restore

Test für iso export auf USB Stick läuft grad.

scdbackup
Beiträge: 59
Registriert: 15.10.2011 11:11:51

Re: Relax and Recover - Bugs - läuft das bei jmd unter D12 ?

Beitrag von scdbackup » 21.07.2023 14:34:03

Hi,

> => works

\o/ Hurra !

> Sämtliche o.g. Änderungen an den rear Skripten habe ich rückgängig gemacht
> und in der /etc/rear/local.conf folgende Optionen gesetzt :
> MKISOFS_BIN=xorriso
> USE_XORRISO=true

Und warum spuckt Dir jetzt ISO_FILE_SIZE_LIMIT nicht mehr in die Suppe ?

Bist Du sicher, dass es nicht "ISO_MKISOFS_BIN" sein muesste anstelle
von "MKISOFS_BIN" ?
(Naja, wenn das so funktioniert, dann ist diese Zeile vielleicht garnicht
noetig und USE_XORRISO reicht schon ? Aber USE_XORRISO findet die Debian
Codesuche nicht in rear. Sowas wie einen Ueberblick aller
Konfigurationsvariablen finde ich auch nicht im Netz.)

Have a nice day :)

Thomas

Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: Relax and Recover - Bugs - läuft das bei jmd unter D12 ?

Beitrag von speefak » 21.07.2023 14:47:56

Es funktioniert :hail: :hail: :hail:

Erstellen eines bootfähigen USB sticks aus der mit rearbackup erstellten ISO Datei :

Code: Alles auswählen

sudo rear-backup -eISO /home/speefak/ReaR_Backups/_OS.iso

 image exists ✔ (/home/speefak/ReaR_Backups/OS.iso)
 ISO filesystem ✔
 bootable ISO image ✔
                            
 select USB drive: 
 1	USB drive detected:  /dev/sda  Samsung SSD 850  238GiB (256GB)     partitioned partitioned:dos
 2	USB drive detected:  /dev/sdc  USB DISK 2.0  3936MiB (4127MB)   removeable

 2	USB drive selected:  /dev/sdc  USB DISK 2.0  3936MiB (4127MB)   removeable

 ALL DATA ON THIS DEVICE WILL BE LOST ! Really use this drive (y/N)? y

 format USB drive (/dev/sdc) with vFAT filesystem
mkfs.fat 4.1 (2017-01-24)
attribute "partition" not found

 copy ISO file for header update
 change ISO headerisohybrid: Warning: more than 1024 cylinders: 3397
isohybrid: Not all BIOSes will be able to boot this device

 write ISO file to USB drive
3,32GiB 0:07:24 [7,64MiB/s] [===============================================================================================================>] 100%            
speefak@speenux:~$ 
Boot und Restore mit dem USB Stick funktioniert ebenfalls - ENDLICH !

Da mit rearbackup nur ein bootfähiger USBStick direkt am Host erstellt werden kann, muss ich den Umweg über rear => iso => usbstick nehmen. Das Quell OS kann ich in der VM konfigurieren und mit rear dann eine ISO erstellen und wenn nötig aus der ISO Datei an einem anderen System eine bootfähige USB Stick erstellen.

Rear-backup Skript : https://github.com/speefak/rear-backup

Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: Relax and Recover - Bugs - läuft das bei jmd unter D12 ?

Beitrag von speefak » 21.07.2023 15:19:31

"(Naja, wenn das so funktioniert, dann ist diese Zeile vielleicht garnicht
noetig und USE_XORRISO reicht schon ? Aber USE_XORRISO findet die Debian
Codesuche nicht in rear. Sowas wie einen Ueberblick aller
Konfigurationsvariablen finde ich auch nicht im Netz.)"
=> ja ... das Problem hatte ich auch schon. Dazu kommen auch noch Unterschiede zwischen den Distros und den Versionen der verwendeten Programme von rear ... und und und. Es gibt Projekte da ist die Fehlersucher einfacher ...

"Und warum spuckt Dir jetzt ISO_FILE_SIZE_LIMIT nicht mehr in die Suppe ?"
=> Gute Frage. vllt liegt es daran : https://github.com/rear/rear/issues/253 ... -734731740 :
Usually 'mkisofs' is called with '-udf -allow-limited-size'
cf. usr/share/rear/prep/ISO/GNU/Linux/320_verify_mkisofs.sh
but only if the '--help' output of ISO_MKISOFS_BIN shows '-allow-limited-size'"
/usr/share/rear/prep/ISO/GNU/Linux/320_verify_mkisofs.sh :

Code: Alles auswählen

if $ISO_MKISOFS_BIN --help 2>&1 >/dev/null | grep -qw -- -allow-limited-size ; then
    ISO_MKISOFS_OPTS+=" -allow-limited-size"
fi

Code: Alles auswählen

mkisofs --help 2>&1 >/dev/null | grep -w  --  -allow-limited-size
  -allow-limited-size         Allow different file sizes in ISO9660/UDF on large files
EDIT: :facepalm: oder einfach weil in der /usr/share/rear/lib/output-functions.sh noch der "continue" "Fehlerübersprung drin steht :facepalm:

Code: Alles auswählen

function assert_ISO_FILE_SIZE_LIMIT () {
    # Skip when there is no usable ISO_FILE_SIZE_LIMIT set (in particular for ISO_FILE_SIZE_LIMIT=0):
    is_positive_integer $ISO_FILE_SIZE_LIMIT || return 0
    local file_for_iso file_for_iso_size
    for file_for_iso in "$@" ; do
        file_for_iso_size=$( stat -L -c '%s' $file_for_iso )
        # Continue "bona fide" with testing the next one if size could not be determined (assume the current one is OK):
        is_positive_integer $file_for_iso_size || continue
        # Continue testing the next one when this one is below the file size limit:
        test $file_for_iso_size -lt $ISO_FILE_SIZE_LIMIT && continue
        # Show only basename to avoid the meaningless ReaR-internal path where files for the ISO are (temporarily) located:
continue
        Error "File for ISO $( basename $file_for_iso ) size $file_for_iso_size greater or equal ISO_FILE_SIZE_LIMIT=$ISO_FILE_SIZE_LIMIT"
    done
}
Test ohne Fehlerübersprung läuft gerade

Falsche Syntax bei der rear Optionsabfrage für mkisofs ( habe den Aufruf getestet, allow-limited-size ist in der mkisofs manpage enthalten => pos. Respose der Funktion fürs Setzten des allow-limited-size flags :roll: ) ? Wenn allow-limited-size ( oder ein anderer Flag ) gesetzt ist, wird die Option ISO_FILE_SIZE_LIMIT vllt. ignoriert ( macht ja auch Sinn ).


"Bist Du sicher, dass es nicht "ISO_MKISOFS_BIN" sein muesste anstelle"
:lol: :lol: :lol: Aber es gibt auch keine Fehlermeldung ;)

scdbackup
Beiträge: 59
Registriert: 15.10.2011 11:11:51

Re: Relax and Recover - Bugs - läuft das bei jmd unter D12 ?

Beitrag von scdbackup » 21.07.2023 15:22:47

Hi,

> change ISO headerisohybrid: Warning: more than 1024 cylinders: 3397
> isohybrid: Not all BIOSes will be able to boot this device

Aha. Sie haben also die Faehigkeit zum Booten von USB-Stick nicht in
das ISO gebacken sondern geben sie erst beim Kopieren auf den Stick dazu.

Was bekommst Du denn ueber das ISO erzaehlt von:

Code: Alles auswählen

xorriso -indev /home/speefak/ReaR_Backups/OS.iso -report_system_area plain -report_el_torito plain
Und was ueber den USB-Stick ?

Code: Alles auswählen

lsblk -o NAME,SIZE,TYPE,FSTYPE /dev/sdc
xorriso -indev stdio:/dev/sdc -report_system_area plain -report_el_torito plain
(Ich wundere mich ueber die Kombination "format USB drive (/dev/sdc)
with vFAT filesystem" und "isohybrid". Eigentlich muss ein isohybrid ISO
die Partitionstabelle und meist auch das Filesystem ueberschreiben.
Packt rear vielleicht das ISO in ein FAT Filesystem aus ? So wie es
Rufus gerne macht. Drum die Frage zum USB-Stick.)

Have a nice day :)

Thomas

scdbackup
Beiträge: 59
Registriert: 15.10.2011 11:11:51

Re: Relax and Recover - Bugs - läuft das bei jmd unter D12 ?

Beitrag von scdbackup » 21.07.2023 15:35:23

Hi,

> oder einfach weil in der /usr/share/rear/lib/output-functions.sh
> noch der "continue" "Fehlerübersprung drin steht

Tja. Da wirst Du vielleicht doch alle Vorkommen von
ISO_FILE_SIZE_LIMIT=2147483648
abklappern muessen und probieren, ob sie den Erfolg verhindern.
In der Upstream-Version sind das zwei
https://sources.debian.org/src/rear/2.7 ... l=882#L882
https://sources.debian.org/src/rear/2.7 ... ?hl=23#L23

Aber die Debian-Paketinstallation koennte diese Grenze auch in anderen
rear-Files auf Deinem Rechner eingetragen haben. Such besser nochmal lokal.

> > "Bist Du sicher, dass es nicht "ISO_MKISOFS_BIN" sein muesste anstelle"

> NÖ :lol: :lol: :lol: Aber es gibt auch keine Fehlermeldung ;)

Im Konfigurationsfile steht, dass der einfach als Liste von Shellbefehlen
ausgefuehrt wird. Das gibt dem Konfigurierenden viel Freiheit aber es
meckert auch nicht, wenn Du die Variable PUMUCKEL mit 1 belegst.

Have a nice day :)

Thomas

Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: Relax and Recover - Bugs - läuft das bei jmd unter D12 ?

Beitrag von speefak » 21.07.2023 15:57:23

Mein Skript ist schon ein wenig älter und seit Debian 10 im Einsatz.

Das Grundlegende Problem war, dass mit rear kein bootbares USB Sickimage am Host erzeugt werden kann, es ist nur das Erstellen von einem USB Stick direkt am Host möglich. Nur blöd wenn kein Realzugriff auf den Host/USB möglich oder nur sehr umständlich wie z.B. bei VMs

Mit rear erstelle ISOs sind nicht selbständig bootfähig ( stand damals ) darum der Umweg über hybridiso. Es gab/gibt ein tool das einiges besser war als isohybrod weil es viel mehr Sicherheitsabfragen hat ( und buntere Textausgaben :D ) - allerdings war es nicht in den Default repos erhältlich.

Test mit Fehlerprüfung ( ohne überspringen mit continue ) in datei /usr/share/rear/lib/output-functions.sh erfolgreich ( viewtopic.php?t=187376#p1332789 )
/usr/share/rear/lib/output-functions.sh unverändert/Originalzustand


"Im Konfigurationsfile steht, dass der einfach als Liste von Shellbefehlen
ausgefuehrt wird. Das gibt dem Konfigurierenden viel Freiheit aber es
meckert auch nicht, wenn Du die Variable PUMUCKEL mit 1 belegst."
=> schade ich dachte das "get rich" flag würde greifen :lol:

Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: Relax and Recover - Bugs - läuft das bei jmd unter D12 ?

Beitrag von speefak » 21.07.2023 16:24:23

Ich denke der Groschen ist gefallen ! Wer lesen kann ist klar im Vorteil :facepalm: :facepalm: :facepalm:

/usr/share/rear/conf/default.conf :
# Error out when files greater or equal ISO_FILE_SIZE_LIMIT should be included in the ISO.
# There is a limit of the ISO 9660 file system that is 2GiB or 4GiB according to
# https://en.wikipedia.org/wiki/ISO_9660# ... size_limit
# Usually 'mkisofs' is called with '-iso-level 3'
# cf. usr/share/rear/prep/ISO/GNU/Linux/320_verify_mkisofs.sh
# but there are cases where ISO 9660 level 1 or 2 is used that has a 2GiB file size limit.
# For example when 'ebiso' is used there is a 2GiB file size limit
# cf. https://github.com/gozora/ebiso/issues/12
# but also other tools that are specified by ISO_MKISOFS_BIN could have that limit.
# Accordingly to be by default on the safe side we use by default a 2GiB limit
# cf. https://github.com/rear/rear/pull/2525
# Under normal circumstances files greater or equal 2GiB should not appear in the ISO.
# An exception is when the backup is included in the ISO with BACKUP_URL=iso://
# where the backup archive file (e.g. backup.tar.gz) could be greater or equal 2GiB.
# The user might adapt ISO_FILE_SIZE_LIMIT provided he verified that "rear recover"
# actually works in his particular environment even when there are files in his ISO
# (in particular backup.tar.gz) that are actually greater than the default 2GiB limit.
# When there is a 2GiB file size limit a backup.tar.gz that is greater than 2GiB
# will get corrupted in the ISO so backup restore via "rear recover" would fail
# which is a dead end because the backup in the ISO got corrupted which is a severe error.
# Also the ReaR recovery system initrd could become greater or equal 2GiB
# (e.g. because of accidentally too much in COPY_AS_IS) which is likely an error
# that could let booting or running the recovery system fail because
# a recovery system in a 2GiB or bigger compressed initrd will need
# more memory space when uncompressed and running in the ramdisk.
# By default we error out when files greater or equal ISO_FILE_SIZE_LIMIT should be
# included in the ISO but if really needed this ISO_FILE_SIZE_LIMIT test
# can be skipped with ISO_FILE_SIZE_LIMIT=0 in etc/rear/local.conf
# (2 GiB = 2 * 1024 * 1024 * 1024 bytes = 2147483648 bytes):
Mkisofs geniso und co sind scheinbar nicht in der Lage ISO im (U)EFI Modus zu starten und darum wird auf ebiso zurückgegriffen ( stand so sinngemäß in einem der rear Scripte )

"# For example when 'ebiso' is used there is a 2GiB file size limit" => ebiso hat das 2GB Limit, welches in der Datei /usr/share/rear/conf/default.conf mit dem Parameter "ISO_FILE_SIZE_LIMIT=2147483648" per default auf 2 GB begrenzt ist. Rear geht scheinbar per default davon aus, dass nur (U)EFI Systeme existieren, daher ebiso genutzt wird und daher ein 2GB Limit per default eingestellt ist. Eine Abfrage ob nun der (U)EFI oder normale BIOS Modus genutzt wird wäre schön. Dann wüßte rear auch ob das 2GB Limit aktiviert werden muss oder nicht.

Wenn man das 2GB Limit GENERELL deaktivieren möchte, muss die Option ISO_FILE_SIZE_LIMIT=0 in der Datei /usr/share/rear/conf/default.conf gesetzt werden. Das kann aber schadhafte Backups zur Folge haben wenn ebiso im Falle von (U)EFI Systemen genutzt wird.

Das Limit kann aber auch frei konfiguriert werden : ISO_FILE_SIZE_LIMIT="X Bytes" ( bis ca. 6 GB mit xorriso unter Debian 12 getestet )
=> 2147483648 => 2 GB
=> 4294967296 => 4 GB
usw.

EDIT: Wenn der Parameter ISO_FILE_SIZE_LIMIT=0 gesetzt ist, sind die Prameter

Code: Alles auswählen

                ISO_MKISOFS_BIN=xorriso
		MKISOFS_BIN=xorriso
		USE_XORRISO=true
in der /etc/rear/local.conf nicht nötig.

- Eingangpost um Lösungslinks ergänzt
- Thread auf [solved] gesetzt

In dem Sinne Danke für die ausführlichen Infos :THX:

scdbackup
Beiträge: 59
Registriert: 15.10.2011 11:11:51

Re: [solved] Relax and Recover - D12 <2GB Error and lib not found

Beitrag von scdbackup » 21.07.2023 16:54:09

Hi,

> Mkisofs geniso und co sind scheinbar nicht in der Lage ISO im
> (U)EFI Modus zu starten

mkisofs und xorrisofs koennen EFI Bootimages fuers Booten von optischen Medien
markieren (El Torito Plattform 0xEF).
isohybrid mit Option --uefi koennte sie dann mit einer Partitionstabelle
fuers Booten vom USB Stick ausstatten.

Aber xorrisofs kann den isohybrid-Schritt auch selbst ausfuehren.
Hier wird demonstriert, wie Debian es fuer altes PC-BIOS und fuer EFI
in den Installations-ISOs fuer amd64 macht:
https://wiki.debian.org/RepackBootableI ... 64_or_i386

Man muss allerdings den MBR file isohdpfx.bin aus ISOLINUX und ein
passend zurechtgemachtes FAT Filesystemimage mit \EFI\BOOT Directory
und genuegend GRUB drin haben, damit GRUB dann Linux vom ISO 9660 Filesystem
starten kann. Als Beispiel koennen die ersten 432 Bytes des ISOs und der File
/boot/grub/efi.img aus den aktuellen Debian ISOs dienen.

Have a nice day :)

Thomas

Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: [solved] Relax and Recover - D12 <2GB Error and lib not found

Beitrag von speefak » 21.07.2023 17:44:36

Erschlagen von Infos :THX:
Ich wunderte mich auch als ich das las aber rear nutzt hier wohl für (U)EFI Systeme ebiso. KP ob den Jungs der Umweg wie du ihn geschildert hast zu umständlich ist ?!

"Man muss allerdings den MBR file [...]"
=> Traumatische Erinnerungen kommen auf ... hatte mir schon mal mein Hauptsystem beim rumbasteln an Partitionconfigs auf Bitebene zerschossen.

Ich finde die Idee hinter (U)EFI nicht schlecht ( Treiber vom OS zu abstrahieren ) aber die Umsetzung ist ne Katastrophe in meinen Augen. Multi-OS-Boot, Erstellen von Images ( s. Thread hier ), Sicherheitslücken, und zig Besonderheiten beim Partitionieren uvm. Das schlimme daran ist, dass Operationen an diesen Datenstrukturen beim kleinsten Fehler echt üble OS Fehler nach sich ziehen können oder die Partitionen unbrauchbar machen können.

scdbackup
Beiträge: 59
Registriert: 15.10.2011 11:11:51

Re: [solved] Relax and Recover - D12 <2GB Error and lib not found

Beitrag von scdbackup » 21.07.2023 20:54:13

Hi,

ich habe nach "ebiso" gegoogelt. Ziemlich wenig zu sehen. Dabei ist es
offenbar ein spartanisch gesinnter Konkurrent zu mkisofs und xorriso.

Es braucht wie xorrisofs ein fertiges FAT Image mit EFI-basierten Programmen,
die dann den Inhalt des ISO 9660 Filesystems zum Leben erwecken.
In
https://gitlab.com/gozora/ebiso/-/wikis/Usage
heisst es "boot/centos.img". Dieses FAT Image muesste dann eigentlich von
rear hergestellt oder beschafft worden sein. Damit waere schon mal die
komplizierteste Zutat fuer eine Umstellung auf xorrisofs vorhanden.

Im Code von https://github.com/gozora/ebiso sehe ich in der Tat keine
Vorkehrungen fuer Files groesser als 4 GiB - 1. Aber einen Grund fuer die
Einschraenkung auf 2 GiB - 1 habe ich nicht gefunden.

Have a nice day :)

Thomas

Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: [solved] Relax and Recover - D12 <2GB Error and lib not found

Beitrag von speefak » 22.07.2023 09:24:10

Ich nutze aus. o.g. Gründen keine UEFI Installation und solange der BIOS Modus noch verfügbar ist verwende ich den. Wie schon gesagt wurde: Wenn der Bootprozess ans OS übergeben wurde ist UEFI überflüssig ( UEFI wurde nie sinnvoll eingesetzt => keine OS Treiber mehr installieren ). Treiber müssen auch heute nach wie vor im OS installiert werden.

Ein Rear Test mit ebiso und ~3.5 GB OS BackupImage würde Klarheit schaffen, setzt aber lt- rear UEFI voraus ( vllt geht auch in der local.conf mit der Option MKISOFS ? )

scdbackup
Beiträge: 59
Registriert: 15.10.2011 11:11:51

Re: [solved] Relax and Recover - D12 <2GB Error and lib not found

Beitrag von scdbackup » 22.07.2023 10:00:23

Hi,

> Ein Rear Test mit ebiso und ~3.5 GB OS BackupImage würde Klarheit schaffen,
> setzt aber lt- rear UEFI voraus

Vielleicht packt es die Files aus der Bootpartition des Rechners in das
FAT Image und gibt das dann an ebiso weiter.
(2 GiB = 2147483648 Bytes wuerden schon reichen. Vielleicht noch ein
paar Kilobyte mehr, nur zur Sicherheit.)

> ( vllt geht auch in der local.conf mit der Option MKISOFS ? )

Kann schon sein (natuerlich mit dem vollen Variablennamen).

Aber wenn weder Du noch ich ebiso benutzen, koennen wir es auch anderen
ueberlassen, die Grenzen auszuloten.
Als xorriso User kannst Du Dich zuruecklehnen und das Backupmachen geniessen.

Have a nice day :)

Thomas

Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: [solved] Relax and Recover - D12 <2GB Error and lib not found

Beitrag von speefak » 22.07.2023 16:57:46

"Aber wenn weder Du noch ich ebiso benutzen, koennen wir es auch anderen
ueberlassen, die Grenzen auszuloten. "
=> das stimmt, rear ist wohl daher unter D12 mit maximaler Kompatibilität, sprich 2GB Limit konfiguriert.

Wundert mich nur wenn UEFI mit mkisofs und genisoimage auch umsetzbar ist warum dann auf ebiso mit seinen Beschränkungen zurückgegriffen wird :roll:

scdbackup
Beiträge: 59
Registriert: 15.10.2011 11:11:51

Re: [solved] Relax and Recover - D12 <2GB Error and lib not found

Beitrag von scdbackup » 23.07.2023 08:57:44

Hi,

> Wundert mich nur wenn UEFI mit mkisofs und genisoimage auch umsetzbar
> ist warum dann auf ebiso mit seinen Beschränkungen zurückgegriffen wird :roll:

Mit dem original geforkten genisoimage kann man kein EFI-Bootimage
im ISO darstellen. (Es ist aber recht einfach nachzuruesten, weil man die
Option -b fuer BIOS-Bootimages wiederverwenden kann und nur die Platform-Id
im El-Torito Bootkatalog auf 0xEF statt auf 0x00 setzen muss.)

Der Entwickler von ebiso war wohl besser im Programmieren als im Googeln.
Erste Release ebiso v0.0.1 war im September 2015:
https://github.com/gozora/ebiso/tags?after=v0.1.2

Das xorriso ChangeLog sagt, dass die erste EFI Unterstuetzung in xorriso
Release 0.5.6 im Mai 2010 auftauchte.
Die Faehigkeit fuer EFI vom USB-Stick kam mit Release 1.2.4 im Juli 2012.
Die ist wie isohybrid --uefi, nur mit einem halben Dutzend Bugs weniger.
isohybrid Option --uefi stammt auch aus dem Jahr 2012 und wurde fuer Fedora
und sein aufgebohrtes genisoimage entwickelt:
https://mjg59.dreamwidth.org/11285.html
Ich kann nicht genau sagen, wann Debian anfing, solche ISOs herzustellen.
Vermutlich war es mit Debian 7.0 im Mai 2013. (Ich versuche gerade ein
7.0.0-netinst ISO zusammensetzen zu lassen. snapshot.debian.org ist heute
etwa so schnell wie ein ISDN Modem ... der Fluch des Jigdo-Downloads ...
Update am naechsten Morgen: Ja, es hat EFI Bootausruestung.)

mkisofs hat offenbar vor dem August 2015 die Faehigkeit bekommen, die
El-Torito Platform-Id zu waehlen:
https://www.pro-linux.de/artikel/2/1785 ... d-dvd.html

Es gab also im Jahr 2015 genug ISO-Generatoren, die EFI konnten.
Aber vielleicht waren sie alle noch nicht in SuSE ES.

Have a nice day :)

Thomas

Benutzeravatar
speefak
Beiträge: 449
Registriert: 27.04.2008 13:54:20

Re: [solved] Relax and Recover - D12 <2GB Error and lib not found

Beitrag von speefak » 23.07.2023 09:53:35

Noch unverständlicher warum ebiso dann mit rear genutzt wurde.

THX 4 Info

Antworten