You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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 withrear -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 showAdditional 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:
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?
The text was updated successfully, but these errors were encountered: