Deployment Solution

 View Only

How to Work Around Rdploy Not Being Able to Capture Non-traditional Linux Partitions  

Sep 17, 2009 02:45 PM

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

Statistics
0 Favorited
0 Views
0 Files
0 Shares
0 Downloads

Tags and Keywords

Related Entries and Links

No Related Resource entered.