On 07/28/2011 02:21 AM, Alexander Hunt wrote:
On 07/28/2011 12:48 AM, Yasha Karant wrote:
On 07/27/2011 11:23 PM, Steven J. Yellin wrote:
On Wed, 27 Jul 2011, Yasha Karant wrote:
...
Is it safe to do the merry chase down the dependency trail to port a
later parted to SL 6 or will some of these cause SL 6 to fail/become
unstable? Does anyone have a SL 6 port of either parted or gparted
that is more recent than the stock SL 6 versions?

You asked about SL6, but my experience with SL5 may be relevant. The
stock SL5 parted wouldn't make a label on a 3TB WD USB drive (4096 byte
sectors), so I compiled what was then the latest version, parted-2.4,
from ftp://ftp.gnu.org/gnu/parted/. There were no absent dependencies,
installation put the result into /usr/local/sbin, leaving the stock
version alone, and the compiled version was adequate. They're up to
parted-3.0 now.

Steven Yellin

I tried your suggested approach first but did not mention this in my
posting. Below is the failure from configure of parted-3.0 on SL 6 :

checking for uuid_generate in -luuid... no
configure: error: GNU Parted requires libuuid - a part of the
util-linux-ng package (but
usually distributed separately in libuuid-devel, uuid-dev or similar)
This can probably be found on your distribution's CD or FTP site or at:
http://userweb.kernel.org/~kzak/util-linux-ng/
Note: originally, libuuid was part of the e2fsprogs package. Later, it
moved to util-linux-ng-2.16, and that package is now the preferred
source.

End output.

I was going to start chasing down the above dependencies, but instead
attempted the Fedora path -- and again faced a chase as I previously
have noted. If I install / build the various parts that parted-3.0
requires, will I break SL 6? One option is to build (configure, make)
all of the parts without make install and customize the configure/make
paths in each component to find the parts in non-standard locations so
as not to "clobber" the stock SL 6 components.

Does anyone have a parted-3.0 ported to SL 6?

Yasha Karant
Have you considered using a live CD of one of the fedora versions (I
prefer F13 for that, but maybe it would have a problem with those drives
too, so perhaps F14 or 15) to do the partitioning and then do the SL
install? I've had to use that method in the past with Seagate drives.
Just a thought to keep you out of dep hell.
There is also the new parted magic live CD that may be better than
Fedora because the tools are already in the distro.
http://distrowatch.com/table.php?distribution=partedmagic

Thank you for the suggestion. I actually had, but for the moment, have rejected the idea. I shall explain my reasoning and please correct it.

My machine does not have eSATA -- although I may have to get an eSATAp card that does not have a controller but merely connects to an available SATA data cable and then the necessary cable to attach any of the various form factors of SATA drives (the docking station I have will accept either a desktop workstation or a laptop form factor SATA drive). The motherboard on my workstation has ample free SATA ports and a large enough power supply (1.5 kW) to supply an eSATAp without issue.

Without eSATA, and given the difficulties that I have encountered with USB 3 support in stock SL 6 (USB 2 is prohibitively slow to clone a drive in the TByte capacity range), would one of these live CDs allow ("see") an external USB 3 drive as /dev/sdX (or /dev/hdX or ... ) for some X? With eSATA, this should not be an issue.

Details:

I am using my faculty workstation for now to clone hard drives in that we do not have a dedicated cloning facility. Unfortunately, the drive from which I am cloning is a standard 512 byte sector drive, whereas the drive that is the target is one of the WD Advanced Format units, and thus a regular dd operation -- even with different input and output block sizes -- would not work because the input file system format would have partitions and internal file pointer contents (in an inode, for example) that would not point to the correct locations on a drive with very different internal block boundaries. If the sector sizes are the same on two disks, and other compatibility issues are met, and because the internal firmware on modern drives and controllers handles typical bad block issues, if one has two devices (say /dev/sdX and /dev/sdY, X .NE. Y), then a simple dd from sdX to sdY should copy all of the relevant partition and file system information, allowing one to mount the various top level directories of the cloned drive and make any necessary changes (such as the IP address for the target machine if, e. g., DHCP is not in use). Given the data rate of USB 3 and the existence of USB 3 SATA drive docking stations (e.g., an external USB 3 drive enclosure without the need of mechanically opening and closing an enclosure to insert or remove a drive), my plan was to use dd over USB 3.

Yasha Karant

Reply via email to