020_create_skeleton_dirs.sh line 31¶

Labels: support / question, fixed / solved / done, not ReaR / invalid, old version

hcowley opened issue at 2025-06-11 22:21:¶

Requesting support or just a question¶

Just trying to get rear 2,6 to work on Ubuntu 22.04 before I upgrade it. Ran this cmd to format the disk. rear -v format -- --efi /dev/sdb ad it mounts ok when I plug it in. So then I umount it before I run the rear cmd. I've tried a few different local.conf files with the same result.

Platform¶

Linux x64

Output¶

:~$ sudo /usr/sbin/rear -v -D mkrescue
Relax-and-Recover 2.6 / Git
Running rear mkrescue (PID 159577)
Using log file: /var/log/rear/rear-cowleyhu.log
Running workflow mkrescue on the normal/original system
Running workflow mkrescue on the normal/original system
Found EFI system partition /dev/sda3 on /boot/efi type vfat
Using UEFI Boot Loader for Linux (USING_UEFI_BOOTLOADER=1)
Using /usr/bin/python3 as Python interpreter and excluding all site/dist packages
Using autodetected kernel '/boot/vmlinuz-6.8.0-60-generic' as kernel in the recovery system
Cannot write protect USB disk of '/dev/disk/by-label/REAR-000' via ID (no ID found)
File system label of '/dev/disk/by-label/REAR-000' added to WRITE_PROTECTED_FS_LABEL_PATTERNS
Modified ReaR recovery system area after 'prep' stage (/tmp/rear.9xm0x216BbTGNeC/rootfs contains regular files)
Creating disk layout
Overwriting existing disk layout file /var/lib/rear/layout/disklayout.conf
Using guessed bootloader 'EFI' (found in first bytes on /dev/sdb)
Skip saving storage layout as 'barrel' devicegraph (no 'barrel' command)
Verifying that the entries in /var/lib/rear/layout/disklayout.conf are correct ...
Creating recovery system root filesystem skeleton layout
ERROR: 
====================
BUG in /usr/share/rear/rescue/default/020_create_skeleton_dirs.sh line 31:
''/tmp/rear.9xm0x216BbTGNeC/rootfs//var/run' already exists - remove '/var/run' from /usr/share/rear/skel if it is present there'
--------------------
Please report this issue at https://github.com/rear/rear/issues
and include the relevant parts from /var/log/rear/rear-cowleyhu.log
preferably with full debug information via 'rear -D mkrescue'
====================
Some latest log messages since the last called script 020_create_skeleton_dirs.sh:
  2025-06-11 22:55:53.007234363 Including rescue/default/020_create_skeleton_dirs.sh
  2025-06-11 22:55:53.009498573 Entering debugscript mode via 'set -x'.
Aborting due to an error, check /var/log/rear/rear-cowleyhu.log for details
Exiting rear mkrescue (PID 159577) and its descendant processes ...
Running exit tasks
You should also rm -Rf /tmp/rear.9xm0x216BbTGNeC
Terminated
a5ib9482@cowleyhu:~$

Additional information¶

rear-cowleyhu.log

jsmeix commented at 2025-06-12 11:49:¶

The usr/share/rear/rescue/default/020_create_skeleton_dirs.sh
script was added by
https://github.com/rear/rear/commit/c61b7a01481d4dda29c3354a253262441ea65bd1
via
https://github.com/rear/rear/pull/3380
because of
https://github.com/rear/rear/issues/3375

But according to

# git log | egrep -i ' release|c61b7a01481d4dda29c3354a253262441ea65bd1'
...
    ReaR 2.9 release
...
commit c61b7a01481d4dda29c3354a253262441ea65bd1
    ReaR 2.8 release

https://github.com/rear/rear/commit/c61b7a01481d4dda29c3354a253262441ea65bd1
happened directly after the "ReaR 2.8 release"
so ReaR 2.6 cannot have that
usr/share/rear/rescue/default/020_create_skeleton_dirs.sh
script, cf.
https://github.com/rear/rear/tree/rear-2.6/usr/share/rear/rescue/default
there is no '020_create_skeleton_dirs.sh' in ReaR 2.6.

FYI how things changed:
Up to ReaR 2.7
/usr/share/rear/skel/default/var/run was a directory
https://github.com/rear/rear/tree/rear-2.7/usr/share/rear/skel/default/var/run
but in ReaR 2.8 there was a
"change /var/run to be a symlink to /run"
https://github.com/rear/rear/blob/rear-2.8/usr/share/rear/skel/default/var/run
to fix certain (even severe) issues, see
https://github.com/rear/rear/commit/b838a352136811900511a209d06c809ce552e636
but this caused
https://github.com/rear/rear/issues/3375
because of a known limitation in RPM
(all was perfectly well in ReaR - that root cause is in RPM!)
so to avoid that RPM issue in ReaR 2.9
/usr/share/rear/skel/default/var/run was removed by
https://github.com/rear/rear/pull/3380/files
so in ReaR 2.9 there is no longer a sub-directory 'run' in
/usr/share/rear/skel/default/var
https://github.com/rear/rear/tree/rear-2.9/usr/share/rear/skel/default/var

@hcowley
accordingly it seems this issue here is not a bug in ReaR
but what is broken is your ReaR installation because
it seems what you actually have is a mix-up of
older ReaR 2.6 and newer ReaR 2.9 things.

So I suggest to first and foremost get a clean ReaR installation.

For example see the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery#Testing_current_ReaR_upstream_GitHub_master_code
how you can try out our current ReaR GitHub master code
without conflicts with your already installed ReaR version.

In general we at ReaR upstream do not support older ReaR versions.
We at ReaR upstream do not plain reject issues with older ReaR versions
(e.g. we may answer easy to solve questions also for older ReaR versions)
but we do not spend much time on issues with older ReaR versions because
we do not (and cannot) fix issues in released ReaR versions.
Issues in released ReaR versions are not fixed by us (by ReaR upstream).
Issues in released ReaR versions that got fixed in current ReaR upstream
GitHub master code might be fixed (if the fix can be backported with
reasonable effort) by the Linux distributor wherefrom you got ReaR.

In particular regarding Ubuntu / Debian
and Linux distributions which are based on them:

I am neither a Ubuntu user nor a Debian user nor a Linux Mint user.
Currently we at ReaR upstream do not have an active
maintainer for Ubuntu / Debian / Linux Mint.
So ReaR support for Ubuntu / Debian / Linux Mint
can be only as good as voluntary contributors
who use those Linux distributions contribute
which is much appreciated!

In particular regarding Ubuntu:
It seems Canonical is not sufficiently interested in ReaR
in contrast to Red Hat and SUSE who pay developers
(like me from SUSE and e.g. @pcahyna and @lzaoral from Red Hat)
to contribute to upstream ReaR because Red Hat and SUSE
support ReaR in their enterprise Linux distributions.

hcowley commented at 2025-06-12 21:28:¶

Hi,

Thanks you so much.
Been struggling for awhile with this.
It's my fault I originally did a git clone of the latest but then I tried to do a make and it said there was nothing to make and after a few weeks of trying various options I gave up and installed rear via apt-get install and did know it was the much older 2.6 version.

I thought I had removed the latest version but obviously not correctly.
I did the git clone again and moved the folder and all the options like excludes are working now after I really struggled with those as well.
I will have to find out how I remove everything now and go back to just one git clone install usig the latest version as that's what I really set out to do..
The backup is working ow but failing near the end with out of space on the
/tmp/rear-efi.XXXXX//EFI/BOOT/initrd.cgz
I see lots of comments on that so I 'll try and work my way through those first.
I really am very happy with your brilliant explanation. Keep up the good work.

Thanks again for all your help I really appreciate the detailed outline of the issue.
I spent ages trawling through that debug log before I contacted you and I see the issue in the log now and really wonder how I missed it before.
You cannot beat an experts view !!
Thanks a lot.
Thanks and regards,
Hugh

From: Johannes Meixner @.>
Sent: Thursday 12 June 2025 12:50
To: rear/rear @.>
Cc: hcowley @.>; Mention @.>
Subject: Re: [rear/rear] BUG in /usr/share/rear/rescue/default/020_create_skeleton_dirs.sh line 31 (Issue #3479)

[https://avatars.githubusercontent.com/u/1788608?s=20&v=4]jsmeix left a comment (rear/rear#3479)https://github.com/rear/rear/issues/3479#issuecomment-2966372203

The usr/share/rear/rescue/default/020_create_skeleton_dirs.sh
script was added by
c61b7a0https://github.com/rear/rear/commit/c61b7a01481d4dda29c3354a253262441ea65bd1
via
#3380https://github.com/rear/rear/pull/3380
because of
#3375https://github.com/rear/rear/issues/3375

But according to

git log | egrep -i ' release|c61b7a01481d4dda29c3354a253262441ea65bd1'¶

...
ReaR 2.9 release
...
commit c61b7a01481d4dda29c3354a253262441ea65bd1
ReaR 2.8 release

c61b7a0https://github.com/rear/rear/commit/c61b7a01481d4dda29c3354a253262441ea65bd1
happened directly after the "ReaR 2.8 release"
so ReaR 2.6 cannot have that
usr/share/rear/rescue/default/020_create_skeleton_dirs.sh
script, cf.
https://github.com/rear/rear/tree/rear-2.6/usr/share/rear/rescue/default
there is no '020_create_skeleton_dirs.sh' in ReaR 2.6.

@hcowleyhttps://github.com/hcowley
accordingly it seems this issue here is not a bug in ReaR
but what is broken is your ReaR installation because
it seems what you actually have is a mix-up of
older ReaR 2.6 and newer ReaR 2.9 things.

So I suggest to first and foremost get a clean ReaR installation.

For example see the section
"Testing current ReaR upstream GitHub master code" in
https://en.opensuse.org/SDB:Disaster_Recovery#Testing_current_ReaR_upstream_GitHub_master_code
how you can try out our current ReaR GitHub master code
without conflicts with your already installed ReaR version.

In general we at ReaR upstream do not support older ReaR versions.
We at ReaR upstream do not plain reject issues with older ReaR versions
(e.g. we may answer easy to solve questions also for older ReaR versions)
but we do not spend much time on issues with older ReaR versions because
we do not (and cannot) fix issues in released ReaR versions.
Issues in released ReaR versions are not fixed by us (by ReaR upstream).
Issues in released ReaR versions that got fixed in current ReaR upstream
GitHub master code might be fixed (if the fix can be backported with
reasonable effort) by the Linux distributor wherefrom you got ReaR.

In particular regarding Ubuntu / Debian
and Linux distributions which are based on them:

I am neither a Ubuntu user nor a Debian user nor a Linux Mint user.
Currently we at ReaR upstream do not have an active
maintainer for Ubuntu / Debian / Linux Mint.
So ReaR support for Ubuntu / Debian / Linux Mint
can be only as good as voluntary contributors
who use those Linux distributions contribute
which is much appreciated!

In particular regarding Ubuntu:
It seems Canonical is not sufficiently interested in ReaR
in contrast to Red Hat and SUSE who pay developers
(like me from SUSE and e.g. @pcahynahttps://github.com/pcahyna and @lzaoralhttps://github.com/lzaoral from Red Hat)
to contribute to upstream ReaR because Red Hat and SUSE
support ReaR in their enterprise Linux distributions.

—
Reply to this email directly, view it on GitHubhttps://github.com/rear/rear/issues/3479#issuecomment-2966372203, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BTPLAMT2FYCACIE5S4WTMWL3DFSOVAVCNFSM6AAAAAB7DYT3NGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDSNRWGM3TEMRQGM.
You are receiving this because you were mentioned.Message ID: @.***>

jsmeix commented at 2025-06-13 08:27:¶

@hcowley

when you call

# sudo /usr/sbin/rear -v -D mkrescue

the ReaR which is installed via apt-get
into system directories like '/usr/' (with leading '/')
will be run.

Normally when you do a "git clone"
the files are in some separated directory
and to run ReaR from such a "git clone" you need to
launch usr/sbin/rear (no leading '/') from within
that separated directory whereto ReaR was "git cloned", cf.

Note the relative paths "etc/rear/" and "usr/sbin/"

in https://en.opensuse.org/SDB:Disaster_Recovery#Testing_current_ReaR_upstream_GitHub_master_code

Regarding

out of space on the /tmp/rear-efi.XXXXX//EFI/BOOT/initrd.cgz

In ReaR 2.9 see
usr/share/rear/output/USB/Linux-i386/100_create_efiboot.sh

local efi_label="REAR-EFI"
local efi_part="/dev/disk/by-label/$efi_label"
...
efi_mpt=$( mktemp -d $TMPDIR/rear-efi.XXXXXXXXXX ) ...
...
mount $efi_part $efi_mpt ...

so /dev/disk/by-label/REAR-EFI gets mounted
at the mountpoint directory /tmp/rear-efi.XXXXXXXXXX

/dev/disk/by-label/REAR-EFI is for OUTPUT=USB
the EFI system partition (ESP) on your USB disk
so it is this ESP which is too small.

See the description of USB_UEFI_PART_SIZE in
usr/share/rear/conf/default.conf

In ReaR 2.9 there is by default

USB_UEFI_PART_SIZE="1024"

https://github.com/rear/rear/blob/master/usr/share/rear/conf/default.conf#L1260
while in ReaR 2.6 it was

USB_UEFI_PART_SIZE="400"

https://github.com/rear/rear/blob/rear-2.6/usr/share/rear/conf/default.conf#L841

See the description of USB_UEFI_PART_SIZE in
usr/share/rear/conf/default.conf in ReaR 2.9
why the ESP on a USB disk is now 1 GiB.

Depending on how big your initrd.cgz becomes
you may need more than 1 GiB for the ESP on your USB disk
i.e. you may need to format your USB disk again
with an appropriate setting of USB_UEFI_PART_SIZE
in your etc/rear/local.conf
when its ESP is too small.
All data on your USB disk will be lost
when you format your USB disk again.

[Export of Github issue for rear/rear.]

#3479 Issue closed: BUG in /usr/share/rear/rescue/default/020_create_skeleton_dirs.sh line 31¶