I have ab 8GB USB thumb drive that has a regular (not LiveUSB) install of openSUSE 11.3 on it. It works great. But there are a number of things I’d like to do to that installation to cutomize it for substantially improved security. But, of course, any of those things I would do could destroy the operation openSUSE. So, instead of fooling around with my only copy, I’d like to clone the “production” USB installation of openSUSE to another 8GB USB thumb drive and then use that thumb drive for my testing (call it my “development” USB thumb drive).
Now, I’ve tried to clone the existing USB thumb drive to an identical one (same size, same manufacturer, same model) using dd, by using the following command:
sudo dd if=/dev/sdc of=/dev/sdd (in my case, since there are already two other drives, my input USB ends up being sdc and the output USB ends up being sdd)
Then I let it run and it appears to complete successfully. But when I try to boot off of the clone of the USB drive, it fails. I’ve tried this process with several different input USB drives (each one having a different distro on it; RHEL 6.2, Ubuntu 10.10, openSUSE 11.3) and while dd always seems to finish successfully, when I try to boot off the USB drive I’ve just created, it always fails (always indicating in some manner that it is unable to find the partitions). With openSUSE, I got more info during the failure and it appears that during the normal installation of the operating system onto the originnal USB thumb drive, when it recorded the drive info, it appears that it incorporated the serial number of the USB thumb drive. Thus, after cloning that install to a different USB thumb drive, the drive information (including the USB drives serial number) is still incorporated into the installation but now that installation is on a USB drive with a different serial number, so when I try to boot up, it looks for disk partitions with a different serial number than the serial number of the new USB thumb drive and it can’t find them, so it fails to boot up (or something to that effect).
Does anyone know what is going on and how I can fix the output system so that it will boot up properly?
On 2012-03-27 18:56, sktd wrote:
> With openSUSE, I got
> more info during the failure and it appears that during the normal
> installation of the operating system onto the originnal USB thumb drive,
> when it recorded the drive info, it appears that it incorporated the
> serial number of the USB thumb drive. Thus, after cloning that install
> to a different USB thumb drive, the drive information (including the USB
> drives serial number) is still incorporated into the installation but
> now that installation is on a USB drive with a different serial number,
You have to manually edit /etc/fstab, /boot/grub/menu.lst and
/boot/grub/devices.map on the copy.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)
Carlos E. R. wrote:
> On 2012-03-27 18:56, sktd wrote:
>> With openSUSE, I got
>> more info during the failure and it appears that during the normal
>> installation of the operating system onto the originnal USB thumb drive,
>> when it recorded the drive info, it appears that it incorporated the
>> serial number of the USB thumb drive. Thus, after cloning that install
>> to a different USB thumb drive, the drive information (including the USB
>> drives serial number) is still incorporated into the installation but
>> now that installation is on a USB drive with a different serial number,
>
> You have to manually edit /etc/fstab, /boot/grub/menu.lst and
> /boot/grub/devices.map on the copy.
By default openSUSE uses disk identifiers that are tied to the model and
serial number of the hardware. As you have discovered, this makes it
difficult to clone a system. There are two other choices of identifier
that make this problem go away - UUID and label. Tell openSUSE to use
one of those instead and your cloned system should be bootable.
Thanks Carlos. That was exactly what the problem was. I figured that there had to be some configuration file somwhere that needed to be modified but I didn’t know what file(s) or where they would be. Editing those three files solved the problem.
You know, it’s too bad someone does write a little program in Python or Perl or something that would ask you for the source drives identifier (such as sdc), ask you for the target drive’s identifier (such as sdd), interrogate the source drive for its serial number, interrogate the target drive for its serial number, run dd for you (dd if=/dev/sd? of=/dev/sd?), and then automatically edit the three pertinent files on the target drive to use the target drive’s serial number (replacing the source drive’s serial number with the target drive’s serial number). That would sure make doing USB to USB clones a whole lot easier. If I knew how to program using Perl or Python, I’d do it myself and then make the script available to everyone.
sktd wrote:
> You know, it’s too bad someone does write a little program in Python or
> Perl or something that would ask you for the source drives identifier
> (such as sdc), ask you for the target drive’s identifier (such as sdd),
> interrogate the source drive for its serial number, interrogate the
> target drive for its serial number, run dd for you (dd if=/dev/sd?
> of=/dev/sd?), and then automatically edit the three pertinent files on
> the target drive to use the target drive’s serial number (replacing the
> source drive’s serial number with the target drive’s serial number).
> That would sure make doing USB to USB clones a whole lot easier. If I
> knew how to program using Perl or Python, I’d do it myself and then make
> the script available to everyone.
But the whole thing is completely unnecessary if you don’t use the
hardware-specific IDs in the first place …
On 2012-03-28 16:46, sktd wrote:
>
> Thanks Carlos. That was exactly what the problem was. I figured that
> there had to be some configuration file somwhere that needed to be
> modified but I didn’t know what file(s) or where they would be. Editing
> those three files solved the problem.
Glad it worked.
It is possible, thinking again, that the initrd is also affected. It
happens sometimes.
–
Cheers / Saludos,
Carlos E. R.
(from 11.4 x86_64 “Celadon” at Telcontar)