#26 Issue closed: Device name has carriage return during file system creation

Labels: waiting for info, support / question

dagwieers opened issue at 2012-03-28 11:59:

Bug reported on SourceForge by Dan Miller as SF#3298288

Original report

This appears to be a strange issue with the dos "Carriage Return" appended to the device names of the hard drive partitions when the scripts run the mkfs.ext3 on the disk drive partitions. The script will fail if I run via rear recover but if I run them with rear -S recover and step through the scripts everything works. The script I believe is in question is /usr/share/rear/GNU/Linux/31_create_filesystems.sh but I am not 100% sure since it works when run in "step" mode. The logs show

Additional not by Dan Miller on 2011-05-06 06:47:57 PDT

Sorry for being a newbee with this bug submission. To finish the bug report if you look at the attached log file (In Linux/Unix) you will see a ^M appended to the device name in the log on line 81. Additional digging showed the device name listed as /dev/sda2/^M. If I run the scripts in the step mode I do not see the ^M anywhere and everythiing completes successfully. I downloaded this file in a gz format and unpacked it/installed it on the Linux system. I ran the install script to install the package.

Additional note by retvog on 2011-06-09 01:47:16 PDT

Did you already found a solution for the "CR"-Problem? I have the same issue here on one Red Hat Server. On all others the backup and recovery works.

And it is the same way as you described it. When I use the step mode everything works fine. But when I use the normal mode with enabled debugging (-D / -d) I also get the ^M in the log file - the same pattern as you submitted.

Regards
Reto

Additional note by Dan Miller on 2011-06-10 06:32:16 PDT

Reto, I still don't have a solution to this issue other than using the
"Step" mode. This works every time but it would be nice to have a more
automated approach.

Additional note by retvog on 2011-06-10 06:49:40 PDT

It's a pity.

I was investigating the problem these days and figured out, that the problem exists on more than one system.

Here some further thoughts concering the problem:

The strange phenomen is, that the problematic systems all have an own partition mounted to /tmp. The servers on which the process works don't have such a tmp partition. This is currently the one and only difference on the servers.
It's really curious. The partitioning process works fine I think, because after the error I checked the partitions with fdisk and they got created. Due to this I think the problem occurs during the mkfs process...
Is it possible, that the problem is already on the running system where I create the ISO?

Hope anybody knows a way to solve the problem :-).

cheers

Additional note by Gratien D'haese on 2011-08-18 01:18:54 PDT

you were using rear-1.10.0. Is it possible to download the latest snapshot version (0.0.669) and give it another try?

dagwieers commented at 2012-03-29 14:25:

We are waiting for feedback from the original reporter in order to get this ball rolling again...

@gdha: Is there a possibility to get in contact with the reporter using private email ?

gdha commented at 2012-03-30 08:27:

send a note via SF to Dan Miller

dagwieers commented at 2012-04-05 18:37:

Alright, closing this issue because we lack feedback about a recent and relevant release. If this is still an issue, please re-open this issue.

[Export of Github issue for rear/rear.]