#2127 Issue closed
: rescue system boots with "md5sum: ./path/to/some.file~: No such file or directory"¶
Labels: fixed / solved / done
, minor bug
OliverO2 opened issue at 2019-04-28 21:28:¶
-
ReaR version ("/usr/sbin/rear -V"): 2.4 / Git (a49ccdbd)
-
OS version ("cat /etc/rear/os.conf" or "lsb_release -a" or "cat /etc/os-release"): Ubuntu 18.04.2 LTS
-
System architecture (x86 compatible or PPC64/PPC64LE or what exact ARM device): x86 compatible
-
Firmware (BIOS or UEFI or Open Firmware) and bootloader (GRUB or ELILO or Petitboot): UEFI, Grub 2.02
-
Description of the issue (ideally so that others can reproduce it):
Message when booting into the rescue system:
Verifying md5sums of the files in the Relax-and-Recover rescue system md5sum: ./boot/grub/menu.lst~: No such file or directory ./boot/grub/menu.lst~: FAILED open or read md5sum: WARNING: 1 listed file could not be read Possibly corrupted Relax-and-Recover rescue system Proceeding 'bona fide' nevertheless...
-
Workaround, if any:
Add
EXCLUDE_MD5SUM_VERIFICATION='/boot/grub/menu\.lst~'
to a configuration file. -
Remarks:
The original system generates
/boot/grub/menu.lst~
automatically along with/boot/grub/menu.lst
. I have verified that there is a$ROOTFS_DIR/boot/grub/menu.lst~
present when md5sum.txt is created. I have also verified there is no/boot/grub/menu.lst~
in the rescue system'sinitrd.cgz
. So the file is removed at some point.
jsmeix commented at 2019-04-29 11:20:¶
I can reproduce it with
# cp -a /boot/grub/menu.lst /boot/grub/menu.lst~
# cp -a /etc/udev/udev.conf /etc/udev/udev.conf~
# rear mkrescue
and the boot that ReaR recovery system.
I also have $ROOTFS_DIR/boot/grub/menu.lst~
and $ROOTFS_DIR/etc/udev/udev.conf~
but
inside the ReaR recovery system both are no longer there.
jsmeix commented at 2019-04-29 11:26:¶
The reason is in pack/GNU/Linux/900_create_initramfs.sh
# grep '~' usr/share/rear/pack/GNU/Linux/900_create_initramfs.sh
if find . ! -name "*~" | cpio -H newc --create --quiet | lz4 -l > "$TMP_DIR/$REAR_INITRD_FILENAME" ; then
if find . ! -name "*~" | cpio -H newc --create --quiet | xz --format=lzma --compress --stdout > "$TMP_DIR/$REAR_INITRD_FILENAME" ; then
if find . ! -name "*~" | cpio -H newc --create --quiet | gzip --fast > "$TMP_DIR/$REAR_INITRD_FILENAME" ; then
if find . ! -name "*~" | cpio -H newc --create --quiet | gzip --best > "$TMP_DIR/$REAR_INITRD_FILENAME" ; then
if find . ! -name "*~" | cpio -H newc --create --quiet | gzip > "$TMP_DIR/$REAR_INITRD_FILENAME" ; then
so I need to adapt build/default/995_md5sums_rootfs.sh accordingly...
OliverO2 commented at 2019-04-29 11:32:¶
Excellent! I did not dare to grep such a little thingy like '~' in ReaR but I hoped that someone would come up with the right idea. Thanks!
jsmeix commented at 2019-04-29 11:51:¶
Fixed for ReaR 2.5 via
https://github.com/rear/rear/commit/f315790691ba35a031dc5152dfed00207b2a5c1f
and added to the ReaR 2.5 release notes via
https://github.com/rear/rear.github.com/commit/205dfccb00550a5d38999fb332d38ac06c8afe9d
jsmeix commented at 2019-04-29 11:56:¶
@OliverO2
thank you for your issue report that makes ReaR a bit more perfect.
By the way:
My "right idea" was that I know I run
build/default/995_md5sums_rootfs.sh
as late as possible so that there are not much scripts that could
change
the recovery system contents after it - actually (at least for me)
pack/GNU/Linux/900_create_initramfs.sh runs directly afterwards
(cf. rear -s mkrescue
) so it was the first of "the usual suspects".
[Export of Github issue for rear/rear.]