#352 Issue `closed`: rear issue for Suse 10 SP3 on dell 2950¶

Labels: bug, waiting for info

huawiceo opened issue at 2014-01-03 10:06:¶

For rear testing work, I have prepared one physical server installed Suse 10 SP3.
After backup OS successfully via rear tool, I use to iso file to recover OS. But met below issue. Please help to solve. Thx

picture device independent bitmap
1

huawiceo commented at 2014-01-03 10:09:¶

disklayout file:

#disk /dev/hda 4294965248 
disk /dev/sda 300000000000 msdos
part /dev/sda 65769984 32256 primary boot /dev/sda1
part /dev/sda 3224277504 26946049536 logical none /dev/sda10
part /dev/sda 8595417600 65802240 primary none /dev/sda2
part /dev/sda 2155023360 8661219840 primary none /dev/sda3
part /dev/sda 1024 10816243200 extended lba /dev/sda4
part /dev/sda 3224277504 10816275456 logical none /dev/sda5
part /dev/sda 3224277504 14040585216 logical none /dev/sda6
part /dev/sda 3224277504 17264894976 logical none /dev/sda7
part /dev/sda 2154991104 20489204736 logical none /dev/sda8
part /dev/sda 4301789184 22644228096 logical none /dev/sda9
#disk /dev/sdb 300000000000 msdos
#disk /dev/sdc 0 
#disk /dev/sdd 16777216 
fs /dev/sda3 / ext3 uuid=ca5a243d-dd73-46e8-a04e-1a4baaa8fbdd label= blocksize=4096 reserved_blocks=4% max_mounts=500 check_interval=60d bytes_per_inode=8184 options=rw,acl,user_xattr
fs /dev/sda10 /app ext3 uuid=4162a99f-48e3-471d-bcb9-495afa8554dc label= blocksize=4096 reserved_blocks=4% max_mounts=500 check_interval=60d bytes_per_inode=8191 options=rw,acl,user_xattr
fs /dev/sda1 /boot ext3 uuid=e0ae41cb-b340-4775-b2ef-b70409693de3 label= blocksize=1024 reserved_blocks=4% max_mounts=500 check_interval=60d bytes_per_inode=4094 options=rw,acl,user_xattr
fs /dev/sda9 /home ext3 uuid=654c37c6-bd76-4fa1-9de6-3a6f2020fce7 label= blocksize=4096 reserved_blocks=4% max_mounts=500 check_interval=60d bytes_per_inode=8180 options=rw,acl,user_xattr
fs /dev/sda7 /opt ext3 uuid=8fcd032a-044f-4d2d-ad51-c5241e1454da label= blocksize=4096 reserved_blocks=4% max_mounts=500 check_interval=60d bytes_per_inode=8191 options=rw,acl,user_xattr
fs /dev/sda8 /tmp ext3 uuid=373716e7-5b2e-42b7-bdd4-cb62fcb1e629 label= blocksize=4096 reserved_blocks=5% max_mounts=500 check_interval=60d bytes_per_inode=8184 options=rw,acl,user_xattr
fs /dev/sda5 /usr ext3 uuid=758819ab-9ce8-4d68-9b5a-514d60ddd9c3 label= blocksize=4096 reserved_blocks=4% max_mounts=500 check_interval=60d bytes_per_inode=8191 options=rw,acl,user_xattr
fs /dev/sda6 /var ext3 uuid=689d4bfc-bee9-405a-8383-5e5940e51ca4 label= blocksize=4096 reserved_blocks=4% max_mounts=500 check_interval=60d bytes_per_inode=8191 options=rw,acl,user_xattr
swap /dev/sda2 uuid= label=

gdha commented at 2014-01-03 12:20:¶

@huawiceo could you try to edit the disklayout file and move the line (before recovering):

part /dev/sda 3224277504 26946049536 logical none /dev/sda10 just after the line part /dev/sda 4301789184 22644228096 logical none /dev/sda9 and retry a rear -v recover

Let us know if this help? If yes, then we hit a bug in our savelayout workflow.