#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's initrd.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.]