When capturing a production Linux OS with partitions that are a non traditional format. (see example below) As you can see the partition 8 and 9 they are not set to the standard linux partition. When capture and deploy happen then partition 8 and partition 9 never get captured and partition 4 shrinks due to those partitions never getting captured.
Device |
Boot |
Start |
End |
Blocks |
Id |
System |
/dev/sda1 |
* |
1 |
3 |
24066 |
83 |
Linux |
/dev/sda2 |
|
4 |
6 |
24097+ |
83 |
Linux |
/dev/sda3 |
|
7 |
268 |
2104515 |
82 |
Linux swap / Solaris |
/dev/sda4 |
|
269 |
7832 |
60757830 |
f |
W95 Ext'd (LBA) |
/dev/sda5 |
|
269 |
1518 |
10040593+ |
83 |
Linux |
/dev/sda6 |
|
1519 |
2768 |
10040593+ |
83 |
Linux |
/dev/sda7 |
|
2769 |
2899 |
1052226 |
83 |
Linux |
/dev/sda8 |
|
2900 |
2963 |
514048+ |
0 |
Empty |
/dev/sda9 |
|
2964 |
6880 |
31463271 |
0 |
Empty |
Showdisk will actually show this output in automation
Disk: edd driver is present
Disk: edd: int13_dev80: sig=0x000667c7, h=255, s=63, size=125829120
/dev/sda: kernel reports 7832/255/63 = 125821080 total sectors
/dev/sda: kernel reports 125829120 total sectors
/dev/sda: translated geometry is 7832/255/63
/dev/sda: disk signature is 0x000667c7
/dev/sda: kernel geometry matches edd geometry
Disk 1 (SCSI): 7832/255/63, 125829120 sectors, 60.00 GB (MBR, sig=000667c7)
Type |
Boot |
Begin |
Size |
1 Ext2 |
* |
63 0/1/1 |
23.50 MB, 9.01 MB used |
2 Ext2 |
|
48195 3/0/1 |
23.53 MB, 966.00 KB used |
3 Linux Swap |
|
96390 6/0/1 |
2.01 GB, 4.00 KB used |
4 Extended |
|
4305420 268/0/1 |
|
+5 Reiser |
|
4305483 268/1/1 |
9.58 GB, 9.58 GB used |
+6 Reiser |
|
24386733 1518/1/1 |
9.58 GB, 9.58 GB used |
+7 Reiser |
|
44467983 2768/1/1 |
1.00 GB, 1.00 GB used |
As you can see the partition 8 and 9 in fdisk output is missing in showdisk.
Cause
When a partition is marked as a 0 (binary) in the boot record, rdeploy doesn't see them in automation. When rdeploy captures it will only capture what it sees.
Workaround
When running these scripts you have to prepare the partitions before imaging and then run and script to put back the partitions back they way the were before imaging. So you will have a runscript task and a capture imaging task in the first job, then a deploy image task and run script task on your push image job.
There are 2 workarounds for this issue.
You need to jot down what key strokes that are necessary to accomplish your task at hand.
1. you can create an answer file and store it in the express share. Create a file copy to the production os like the "/tmp" directory and then run this script to change the partition binary from 0 to 83. Then create script to call the answer file and pipe that back into the fdisk command.
fdisk /dev/dev/hdX < fdisk.before (See below for sample)
t
8
0
w
Here is another example that can be used to have one answer file to change the partition table before imaging and then change it back after imaging. The sleep command is necessary to allow fdisk to finish its process and report back to adlagent with a success. If the sleep command is removed a error 1 in script execution will be returned and fdisk will never run.
#!/bin/sh
if
test -f /tmp/fdisk.before; then fdisk /dev/sda < /tmp/fdisk.before
else fdisk /dev/sda < /tmp/fdisk.after
sleep 10
2. You can create a run script task to do the following so you dont have to copy down answer files and do it all in one script
#!/bin/bash
fdisk /dev/hdX <<EOF
d
3
d
2
d
1
n
p
1
16
p
q
EOF