#2180 Issue `closed`: Debian 10: during boot "rear udev" is called, causing delay during boot¶

Labels: bug, cleanup, fixed / solved / done

gaia opened issue at 2019-07-13 17:17:¶

Relax-and-Recover 2.4 / Git (installed via apt)
Debian 10
BareMetal
x86_64
UEFI + GRUB
Root on mdadm, NVME disk attached, rear on USB flash drive:
During bootup, "rear udev" is called. this stalls the boot process for about a minute, then it beeps 16 times (15 short + 1 long) and boot proceeds
Workaround: uninstalling rear. removing/reinstalling does not help

If I call "rear udev" in the shell, I get the same delay (1 minute) during which "Cannot include keyboard mappings (no keymaps default directory '')" appears. Then the beeps.

Maybe inserting a keyboard mapping will help? If yes, how can I do that?

jsmeix commented at 2019-07-15 08:37:¶

@gaia
I am neither a Debian user
nor do I know about packaging for Debian
so that I can neither reproduce your issue
nor can I verify how it could happen that on Debian

During bootup, "rear udev" is called

which should certainly not happen - at least never ever by default -
cf. https://github.com/rear/rear/issues/840
and https://github.com/rear/rear/issues/838

To avoid that the rear udev workflow is run during boot
it should help to remove its udev rule file,
cf. https://github.com/rear/rear/issues/838#issuecomment-219708975

Nothing like that should happen on RPM-based systems because
there is no ReaR udev rule file in ReaR RPM packages,
cf. https://github.com/rear/rear/issues/838#issuecomment-219724335

In contrast from what I see at
https://packages.debian.org/sid/amd64/rear/filelist

File list of package rear in sid of architecture amd64
...
/lib/udev/rules.d/60-rear.rules

it seems on Debian systems a ReaR udev rule file
might still get installed which is likely plain wrong.
But I do not know what that 60-rear.rules file contains.
Perhaps its content is same as our upstream 62-rear-usb.rules
https://github.com/rear/rear/blob/master/etc/udev/rules.d/62-rear-usb.rules
or perhaps that 60-rear.rules file is something Debian specific?

jsmeix commented at 2019-07-15 08:39:¶

@gdha
do you know a bit about packaging for Debian?
If yes, could you have a look whether or not perhaps for Debian
a udev rule file might get installed by default that causes
that during boot "rear udev" is called?

I fail to make sense of our packaging/debian files in
https://github.com/rear/rear/tree/master/packaging/debian

E.g. to me rear_1.13.0.orig.tar.gz in
https://github.com/rear/rear/blob/master/packaging/debian/rear.dsc
that is also on the openSUSE build service
https://build.opensuse.org/package/view_file/Archiving:Backup:Rear/rear-2.5/rear.dsc?expand=1
does not look right, I would expect some 2.5 version number?

gdha commented at 2019-07-15 12:42:¶

@frediz Was checking https://tracker.debian.org/pkg/rear - seems still be at 2.4 - any chance to get 2.5 in there? We would appreciate it a lot!

gdha commented at 2019-07-15 12:44:¶

@gaia sorry that we miss-used your case.
I need time to check the 'udev' rule again - it was added in 2012 I think by @dagwieers and @jhoekx

frediz commented at 2019-07-15 15:39:¶

@gdha Hey, Debian Buster was released beginning of July and package upload was frozen till that.
So now that the new Debian stable is released, I'll have a look at updating 2.5 in Debian unstable.

gaia commented at 2019-07-15 16:47:¶

Thank you for updating it, @frediz

@jsmeix, contents of /lib/udev/rules.d/60-rear.rules

ACTION=="add", SUBSYSTEM=="block", ENV{ID_FS_LABEL}=="REAR-000", RUN+="/usr/sbin/rear udev"

jsmeix commented at 2019-07-16 07:30:¶

Our upstream etc/udev/rules.d/62-rear-usb.rules file
https://github.com/rear/rear/blob/master/etc/udev/rules.d/62-rear-usb.rules
should be moved to a documentation directory
or removed and replaced by documentation text
so that it can never again happen that it (or any other udev rule)
gets installed accidentally by default on user systems.

Basically same as we did for ReaR 2.5 with our /etc/cron.d/rear file,
cf. https://github.com/rear/rear/issues/1892#issuecomment-410973078
and subsequent comments therein.

gdha commented at 2019-07-16 13:34:¶

Our upstream etc/udev/rules.d/62-rear-usb.rules file
https://github.com/rear/rear/blob/master/etc/udev/rules.d/62-rear-usb.rules
should be moved to a documentation directory
or removed and replaced by documentation text
so that it can never again happen that it (or any other udev rule)
gets installed accidentally by default on user systems.

Basically same as we did for ReaR 2.5 with our /etc/cron.d/rear file,
cf. #1892 (comment)
and subsequent comments therein.
@jsmeix Indeed seems a good idea to move it away as I think it is a bit outdated. Perhaps @dagwieers can bring up a reason why we should keep it?

gdha commented at 2019-09-11 09:13:¶

@jsmeix I believe "USB udev integration to trigger mkrescue on inserting USB device" was the motivation for this udev rule (see https://github.com/rear/rear/blame/master/doc/user-guide/01-introduction.adoc#L105), however, it was added 7 years ago. It might be that is an obsolete feature at this moment.

jsmeix commented at 2019-09-11 14:18:¶

@gdha
because of https://github.com/rear/rear/issues/840
I think the "USB udev integration to trigger mkrescue on inserting USB device"
functionality is not possible nowadays because it cannot work reliably.

I think only few users use it and those who use it have probably
just luck that it works in their particular case (e.g. because the
default UDEV_WORKFLOW=mkrescue completes sufficiently fast).

But by default there must not be such a functionality activated
i.e. a functionality that only works by luck.

So I think our etc/udev/rules.d/62-rear-usb.rules content
could be preserved to provide some backward compatibility
but only in a documentation file where it is also documented
that running "rear mkrescue" via the default UDEV_WORKFLOW=mkrescue
may work with some luck but e.g. UDEV_WORKFLOW=mkbackup
will fail "almost surely" cf. https://en.wikipedia.org/wiki/Almost_surely

jsmeix commented at 2020-04-29 15:58:¶

@gdha
I guess this is nothing that needs to be fixed inside the ReaR code
but perhaps outside in the Debian packaging scripts
so I think it can be postponed to ReaR 2.7

github-actions commented at 2020-06-29 01:37:¶

Stale issue message

[Export of Github issue for rear/rear.]

#2180 Issue closed: Debian 10: during boot "rear udev" is called, causing delay during boot¶