#3241 Issue closed: mkrescue fails¶
Labels: support / question, old version
BobMCT opened issue at 2024-06-09 20:48:¶
My goal is to create a recoverable OS on an 8GB USB using mkrescue and then make a mkbackuponly to a different USB 4TB hdd. Is this possible? Then after installing ReaR and updating my site.conf file I formatted my 8GB USB for --efi using the format subcommand I found in the help guide. I seems to almost complete but then exits with an error. Here is the last part of the log:
2024-06-04 21:10:11.072292987 Finished running 'pack' stage in 73 seconds
2024-06-04 21:10:11.073807372 ======================
2024-06-04 21:10:11.075236991 Running 'output' stage
2024-06-04 21:10:11.076741607 ======================
2024-06-04 21:10:11.084629786 Including output/default/010_set_umask.sh
2024-06-04 21:10:11.086240721 Setting umask to 077
2024-06-04 21:10:11.090784042 Including output/USB/Linux-i386/100_create_efiboot.sh
2024-06-04 21:10:11.092519660 Configuring device for EFI boot
'/boot/efi/EFI/ubuntu/grubx64.efi' -> '/tmp/rear-efi.5diMF75R3L//EFI/BOOT/BOOTX64.efi'
'/boot/vmlinuz-5.15.0-107-generic' -> '/tmp/rear-efi.5diMF75R3L//EFI/BOOT/kernel'
'/tmp/rear.m3s6uLmRauQk9tM/tmp/initrd.cgz' -> '/tmp/rear-efi.5diMF75R3L//EFI/BOOT/initrd.cgz'
cp: error writing '/tmp/rear-efi.5diMF75R3L//EFI/BOOT/initrd.cgz': No space left on device
Which device? The /tmp tree on the primary drive? Its a 1TB drive with only Linux Mint 21.3 installed. Is there a way at this point to determine how much space/workspace is required? Is there a mechanism to define/redirect the workspace to a different drive?
2024-06-04 21:10:11.849242837 ERROR: Failed to copy initrd to /tmp/rear-efi.5diMF75R3L//EFI/BOOT/initrd.cgz
===== Stack trace =====
Trace 0: /usr/sbin/rear:541 main
Trace 1: /usr/share/rear/lib/mkrescue-workflow.sh:22 WORKFLOW_mkrescue
Trace 2: /usr/share/rear/lib/framework-functions.sh:116 SourceStage
Trace 3: /usr/share/rear/lib/framework-functions.sh:56 Source
Trace 4: /usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh:38 source
=== End stack trace ===
2024-06-04 21:10:11.855077402 Exiting rear mkrescue (PID 945750) and its descendant processes ...
2024-06-04 21:10:14.915445172 rear,945750 /usr/sbin/rear -v mkrescue
-rear,962356 /usr/sbin/rear -v mkrescue-pstree,962357 -Aplau 945750
/usr/share/rear/lib/_input-output-functions.sh: line 151: kill: (962360) - No such process
2024-06-04 21:10:14.939148826 Running exit tasks
2024-06-04 21:10:14.940788399 Finished in 102 seconds
2024-06-04 21:10:14.942317038 Removing build area /tmp/rear.m3s6uLmRauQk9tM
removed directory '/tmp/rear.m3s6uLmRauQk9tM'
2024-06-04 21:10:15.502230134 End of program reached
If you would be so kink could you advise what step I may have missed and/or how I can remedy it?
At your convenience. Thank you, BobMCT
jsmeix commented at 2024-06-10 07:15:¶
@rear/contributors
the URL of this issue is
https://github.com/rear/rear/issues/3241
while our normal ReaR issues have URLs like
https://github.com/rear/rear/issues/3238
so this issue seems to be in a wrong place.
jsmeix commented at 2024-06-10 07:24:¶
Now I see:
This one had been created under
https://github.com/rear/rear-issues/issues
I found
https://docs.github.com/en/issues/tracking-your-work-with-issues/transferring-an-issue-to-another-repository
so I transferred it right now from
https://github.com/rear/rear-issues/issues
to
https://github.com/rear/rear/issues
jsmeix commented at 2024-06-10 07:56:¶
@BobMCT
see
https://raw.githubusercontent.com/rear/rear/master/.github/ISSUE_TEMPLATE.md
what information we usually need in issues
to be able to understand what geos on.
I guess you use OUTPUT=USB together
with BACKUP=NETFS and BACKUP_URL=usb://
This method is normally meant to be used
with only one disk, for example as described at
http://relax-and-recover.org/documentation/getting-started
I never tried it with two disks,
one for the ReaR recovery system
and another one for the backup.
Offhandedly I think this could be possible
but I assume you would have to adjust things
in the ReaR config file(s) to make this special kind
of usage work - in particular during "rear recover".
But I do not understand why you like to have the
ReaR recovery system on another disk than the backup?
Why not have the ReaR recovery system and the backup
on one same disk as usual?
Regarding
cp: error writing '/tmp/rear-efi.5diMF75R3L//EFI/BOOT/initrd.cgz': No space left on device
...
Trace 4: /usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh
The code in
usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh:38
seems to be from ReaR 2.6 in your case which is
cp -p $v "$TMP_DIR/$REAR_INITRD_FILENAME" "$EFI_DST/$REAR_INITRD_FILENAME" || Error "Failed to copy initrd to $EFI_DST/$REAR_INITRD_FILENAME"
So there is no space left on device for $EFI_DST
which is ${EFI_MPT}/${EFI_DIR} where ${EFI_MPT}
is hardcoded /tmp/rear-efi.XXXXXXXXXX
in mktemp -d /tmp/rear-efi.XXXXXXXXXX
so it is hardcoded /tmp on the system disk
where "rear mkrescue" runs.
In ReaR 2.7 this was improved to
mktemp -d $TMPDIR/rear-efi.XXXXXXXXXX
So upgrading to ReaR 2.7
see
http://relax-and-recover.org/download/
and then setting $TMPDIR (and exporting it)
to a directory with more space (e.g. /var/tmp/
which is already the default since ReaR 2.7)
should help before calling "rear mkrescue".
See the description about TMPDIR in
usr/share/rear/conf/default.conf
for RerR 2.7 at
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L44
jsmeix commented at 2024-06-10 08:26:¶
@BobMCT
I think that my above analysis was wrong.
Reason:
At /tmp/rear-efi.XXXXXXXXXX the ESP gets mounted
so it is not '/tmp/' on the system disk
where there is no space left on device
but it is the ESP (EFI System Partition)
on the USB disk where there is no space left on device.
To solve that specifiy a sufficiently big
USB_UEFI_PART_SIZE in your ReaR configuration.
In ReaR 2.6 its default was 400 MIB
https://github.com/rear/rear/blob/rear-2.6/usr/share/rear/conf/default.conf#L841
In ReaR 2.7 it was increased to 1 GiB
https://github.com/rear/rear/blob/rear-2.7/usr/share/rear/conf/default.conf#L1053
BobMCT commented at 2024-06-11 00:37:¶
Regarding using two separate disks for mkrescue and mkbackuponly:
My reasoning is thus: The mkrescue would be executed significantly
less frequently perhaps weekly or bi-weekly but mkbackuponly would be
executed most likely daily. If both disks were formatted as Rear-000
then would that suffice?
However, if the target disk was an external 4TB hdd then could both
the
mkrescue and the mkbackuponly be written to the same device?
Does the target device have to be reformatted prior to EACH execution
if
the results were to be written to the target drive with newer versions?
Finally, where can I get a deb file of the rear 2.7 version that I can
install on my development machine (because I do not have compile
capability - all my work is done remotely or with interpreted
languages).
Thanks for your help.
BobMCT
schlomo commented at 2024-06-11 08:10:¶
@BobMCT you can download pre-built packages of our master code from
https://github.com/rear/rear/releases/tag/snapshot
I'd recommend to simply use rear mkbackup all the time and forego the
rather little optimisation gained by mkbackuponly. The time to run
mkrescue is much shorter compared to the backup time, typically. The
rescue image disk space requirements are rather small in comparison to a
typical backup - and you will gain a significant improvement in the
handling and convenience.
To answer your other question please share your ReaR configuration.
To use different disks please make sure to set a different
USB_DEVICE_FILESYSTEM_LABEL
You can also experiment with having multiple ReaR configs that you pull
in via the -C option.
But, again, my honest advice would be to simply only use mkbackup all
the time. That also ensures that - no matter what - your rescue image
and your backup always fit together.
pcahyna commented at 2024-06-18 16:26:¶
I am afraid that there is confusion in the USB code regarding the usage
of BACKUP_URL vs. OUTPUT_URL, so using different disks for output
and backup may have issues.
https://github.com/rear/rear/pull/3102#issuecomment-1850236912
jsmeix commented at 2024-06-19 06:31:¶
@BobMCT
to avoid generic problems when backup and ReaR recovery system
are separated and to avoid problems with our imperfect USB code
I would much recommend to follow the advice of @schlomo and
only use "rear mkbackup" with single disks all the time.
This is what basically all others do so this way is proven
to work reasonably well "out there in the wild".
Regarding generic problems when "rear mkrescue"
and "rear mkbackuponly" are called at different times
instead of using "rear mkbackup" see in the section
"Relax-and-Recover versus backup and restore" in
https://en.opensuse.org/SDB:Disaster_Recovery
in particular the parts about
"ensure your backup is consistent".
Regarding "use 'rear mkbackup' with single disks"
versus "use 'rear mkbackup' with a single disk"
see in the same section in particular the part about
"ensure your backups are kept safe" that reads
It is your task to ensure your backups are kept safe at a
sufficiently secure place. In particular the place where
ReaR writes a new backup (e.g. a NFS share or a USB disk)
is not a really safe place to also keep old backups
(arbitrary things might go wrong when writing there).
So if you use only one disk where already a backup is
stored, something might go terribly wrong when writing
a subsequent beckup there (via "rear mkbackup")
so in the end all might be lost on that disk.
I.e. to be reasonably on the safe side
you should use at least two separated disks.
schlomo commented at 2024-07-12 09:00:¶
Closing this as it seems to be that alls has been said. You can reopen for new thoughts on this topic.
[Export of Github issue for rear/rear.]