What is the relation between UUID and a disk image? - linux

In order to create two VMs on VirtualBox for same Fedora 17 vdi, I first installed Fedora, then I copied Fedora17.vdi using dd command. Then I changed the UUID of the new image using the command
$ VBoxManage internalcommands sethduuid /home/pradeep/Fedora_New.vdi "NewUUID"
But this doesnot work..I am interested to know what is the relation between the UUID value of a disk and its disk image and how it is calculated.

How did you use dd to create the copy? My guess is that is where things went south most likely.
The best way to duplicate a virtual disk image is to use the clonehd command:
VBoxManage clonehd original.vdi copy.vdi
This will also clean up the UUID as the copy is created.

Related

Missing VolumeGUIDs in Windows 2016 MountedDevices registry key

Our software runs on Linux and we need to create a mapping between Linux device name(something like /dev/sda1) and VolumeGUID as it appears in Windows, since we are examining Windows disks/partitions.
We get this information from MountedDevices Windows Registry subkey.
Problem occurs on Windows 2016, where Volume{GUID}s are no longer listed in MountedDevices subkey.
I managed to figure out, that Volume{GUID} is not a random GUID anymore(which is probably why they do not have to be stored it registry anymore), but it gets composed from data in the partition table.
In case of GPT, the VolumeGUID is actually a GPT partition GUID, which is great, because I can easily reconstruct those VolumeGUIDs.
In case of MBR, it is something like:
\?\Volume{46e21ed5-0000-0000-0000-100000000000}\
\?\Volume{46e21ed5-0000-0000-0000-104000000000}\
\?\Volume{46e21ed5-0000-0000-0000-108000000000}\
\?\Volume{46e21ed5-0000-0000-0000-20c000000000}\
...
Where 46e21ed5 is actually a disk signature, but I'm not sure what other fields mean. It looks like there's a partition offset (0x400 = 1024, and each partition is 1024MB in the provided example), but something does not add up for the last partition which has 20C00.
Does anyone have more information on this subject and how these volume GUIDs get composed? (Google does not find any information on this subject)
Regards

Copy file to disk image (*.img)/analogue to mcopy on Mac

I want to copy few files to image of disk (*.img extension). On linux this command is used:
mcopy -i "$target_img" $file ::/
What is same command for mac (OS X)? How can I copy files to image?
Apparently my last answer doesn't fit the criteria of the moderator... well heres an answer acceptable in their "format." i guess i wont get back the little reputation i received that the admin stripped me from. its tough being 20 yr old silicon valley techy ;)
The hdiutil command can also be used to create a disk image based upon a folder.
hdiutil create {imagename}.dmg -volname "{Name of volume}" -srcfolder /{path to folder}'
Using the above command, we could perform the following:
hdiutil create ~/Desktop/newimage.dmg -volname "New Disk Image" -srcfolder ~/Desktop/myfolder
The name of the disk image and volume name are two different things, the first simply refers to the filename of the disk image created. When the image is mounted or restored to a disk, the volume name is what's referred to. So if I mount this new disk image, you'll see OS X mounts it as "New Disk Image".
Disk images generated using the above methods are read-only and formatted as HFS+ by default, though their size will be just enough to contain all the data needed.
Standard disk images cannot increase in size, so you'll need to specify a particular size if you intend to be adding data to it later. The parameter -size can be used to specify the size of the disk image to create.
If you need will need to modify or add more data to the disk image, use the parameter -format UDRW which represents read/write.
Combining all of the above, the command would be:
hdiutil create ~/Desktop/newimage.dmg -volname "New Disk Image" -size 1g -format UDRW -srcfolder ~/Desktop/myfolder

problems restoring image file with dd

I have a pendrive where I restore an image maked by dd command in other system.
When I restore the image, always I must do a fsck.
Is possbile that when I've generated the image the source system was corrupted or it is that I corrupt the pendrive when I restore the image file ?
Many thanks and sorry for my English!
To know if you have corruption in your data, when you create an image, you should compute a checksum (md5sum or sha1).
# dd if=/dev/sdb of=my_image.img # --> here you create your image
# md5sum /dev/sdb # --> here you compute your checksum
e2985322ca0ed3632027a6eb8fe70ae8 /dev/sdb
# md5sum my_image.img # --> check the integrity of the image
e2985322ca0ed3632027a6eb8fe70ae8 my_image.img
Thus, when you flash to another device, on an other computer or any system, you are able to check the integrity of data.
# dd if=my_image.img of=/dev/hdc # --> here you flash your image to a device
# md5sum /dev/hdc # --> check the integrity of the flashed data
e2985322ca0ed3632027a6eb8fe70ae8 /dev/hdc
Of course the obtained hash here is just an example but it is always the same for the same data. If any byte was altered the checksum would be totally different.
Obviously, if you copy with dd to a device (even from), be sure that one is not mounted using something like mount | grep /dev/hdc should return nothing if you want to flash the dev/hdc device.
This is just guessing, since you do not provide much information about the creation of the image, but yes, it is possible that the file system was in an unclean state when the image was taken. It is also possible that the file system was simply still mounted at that point of time - always unmount a file system (or mount it read-only) before you take an image of it.

How could I force minor number allocation for SAN on linux?

I've got a cluster both attached to a SAN (using multipath on linux), using RAW devices for ORACLE.
When each box boot they pick up differant minor number (I guess it's first come first serve), seems to be random allocation, not sure I need to find a way to force it. (Used to love my solaris box...).
Therefore ORACLE is using minor number and failover will just mean loosing all the data!
How could I force minor number allocation for SAN on linux?
You can set up user_friendly_names yes stanza in your multipath.conf file and enumerate all multipath devices on both nodes of your Oracle cluster:
multipaths {
multipath {
# LUN 123 on your array
alias ora01
wwid 36006abcdefabcdef0123456789abcdef1
}
}
Give to Oracle ASM the paths to customized names of your disks (/dev/mapper/ora01 in this example) and both cluster nodes will see the same disk with very same name.
wwid begins with 3 followed by WWN of your SAN disk (refer to documentation of your SAN vendor how to get these numbers...)

DD img different MD5's?

We have a smart media card with a linux install on it that we need to duplicate. We created an img with DD and then used dd to write the img back to a couple of new smart media cards. We have compared the MD5 checksum of both the original and the new copies and they are different.
Here is what we used:
dd if=/dev/sdb of=myimage.img
dd if=myimage.img of=/dev/sdb
dd if=/dev/sdb of=newimage.img
Anyone have any ideas of why these come out different?
If the cards are different sizes, dd'ing the smaller image to a larger card will not "fill it up", and zeros will remain at the end of the card. An image made from this card will be different than the original image.
It's also always possible that data was mis-written, mis-read, or otherwise corrupted in-transit.
The card capacities differ?
Running 'ls -l myimage.img newimage.img' might tell you something.
Running 'cmp -l myimage.img newimage.img' might tell you something.
If you mounted /dev/sdb in between it would be an answer. If I remember correctly ext2 and ext3 have a "mount counter".

Resources