SCIENTIFIC-LINUX-USERS Archives

May 2021

SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Alec Habig <[log in to unmask]>
Reply To:
Alec Habig <[log in to unmask]>
Date:
Tue, 11 May 2021 22:34:15 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (26 lines)
If you clone the whole thing using a lowlevel tool, say "dd": it will
also clone the UUIDs.

In your case, if you plan on removing the old disk before booting up
with the new disk, that means it should just happily "wake up" in its
new disk and never know the difference.

On the other hand, if you're trying to clone partitions around onto new
disks this way without pulling the old disk out (trying to expand your
storage), then the duplicate UUIDs cause you trouble, because you'd have
devices with the same UUID.  You can generate new UUIDs if this is the
case, by temporarily addressing things using hardware addresses instead.

I've done this using similar disks (replacing failing drives) and it
worked fine.  But, I'm not sure if the differences in low-level
geometry/blocksizes between different technology disks could cause a
problem.  I suppose it can't hurt to try: you can always reformat the
new disk if it doesn't work.

-- 
			       Alec Habig
		     University of Minnesota Duluth
		     Dept. of Physics and Astronomy
			     [log in to unmask]
		   https://urldefense.proofpoint.com/v2/url?u=http-3A__neutrino.d.umn.edu_-7Ehabig_&d=DwIBAw&c=gRgGjJ3BkIsb5y6s49QqsA&r=gd8BzeSQcySVxr0gDWSEbN-P-pgDXkdyCtaMqdCgPPdW1cyL5RIpaIYrCn8C5x2A&m=aTI04QiwYwL5FAiBUAkMdUQuFOGFmznVGqe2mvxW9pY&s=Om1zMT_zxu5HQQuUYbfw2kJy4b_960ullxhb1xd81Mc&e= 

ATOM RSS1 RSS2