I am repairing a computer for someone that has two distinct disks. Populated and partitioned as follows:

  1. is filled with multiple Operating systems on multiple partitions
  2. is an internal data drive with a single partition (i.e. undivided)

Now unfortunately the data drive is the one that got the partition table.

  • The way I understand it is they started by installing windows, then arch linux but since they left the data drive plugged in, they ended up with the wrong drive getting the partition table.
  • They didn't notice for many months, proceeding to install arch linux side by side windows, and only noticed recently when they unplugged their data drive that the partition table disapeared.
  • The problem I am faced with before attempting to copy and then remove the partition table, is that I don't have the space backup their data ahead of time just in case

My Question:

So I am curious if in general procedures to copy the partition table between disks and then make both disks useable by reseting/randomizing the GUID is safe and independent of the allready existing data?

sgdisk -R=/dev/sdb /dev/sda
sgdisk -G /dev/sdb

I got the two sgdisk commands from this answer: https://unix.stackexchange.com/a/60393/173317

Setup Specifics

The results of lsblk -fa

NAME   FSTYPE LABEL           UUID                                             MOUNTPOINT
└─sda2 ntfs   COMPUTER        16 digit alpha numeric code
├─sdb1 ntfs   System Reserved 16 digit alpha numeric code                     
├─sdb2 ntfs                   16 digit alpha numeric code                     
├─sdb3 ntfs                   16 digit alpha numeric code                     
├─sdb5 swap   SWAP            8 digits-4 digits-4 digits-4 digits-12 digits     [SWAP]
├─sdb6 ext4   BOOT            8 digits-4 digits-4 digits-4 digits-12 digits     /boot
├─sdb7 ext4   ROOT            8 digits-4 digits-4 digits-4 digits-12 digits     /
└─sdb8 ext4   HOME            8 digits-4 digits-4 digits-4 digits-12 digits     /home

The results of parted -l

Model: ATA ST3500320AS (scsi)
Disk /dev/sda: 500GB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    File system  Name                  Flags
1      17.4kB  1018kB  1000kB                                     bios_grub
2      1049kB  500GB   500GB   ntfs         Basic data partition  msftdata

Model: ATA ST2000DX001-1CM1 (scsi)
Disk /dev/sdb: 2000GB
Sector size (logical/physical): 512B/4096B
Partition Table: msdos
Disk Flags: 

Number  Start   End     Size    Type      File system     Flags
1      1049kB  106MB   105MB   primary   ntfs            boot
2      106MB   107GB   107GB   primary   ntfs
3      107GB   107GB   472MB   primary   ntfs            diag
4      107GB   2000GB  1893GB  extended                  lba
5      107GB   116GB   8590MB  logical   linux-swap(v1)
6      116GB   117GB   1074MB  logical   ext4            boot
7      117GB   139GB   21.7GB  logical   ext4
8      139GB   192GB   53.7GB  logical   ext4

The results of fdisk -l

Disk /dev/sda: 465.8 GiB, 500107862016 bytes, 976773168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 8 digits-4 digits-4 digits-4 digits-12 digits

Device     Start       End   Sectors   Size Type
/dev/sda1     34      1987      1954   977K BIOS boot
/dev/sda2   2048 976771071 976769024 465.8G Microsoft basic data

Disk /dev/sdb: 1.8 TiB, 2000398934016 bytes, 3907029168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 10 alpha numeric (hex) digits

Device     Boot     Start        End    Sectors  Size Id Type
/dev/sdb1  *         2048     206847     204800  100M  7 HPFS/NTFS/exFAT
/dev/sdb2          206848  208795647  208588800 99.5G  7 HPFS/NTFS/exFAT
/dev/sdb3       208795648  209717247     921600  450M 27 Hidden NTFS WinRE
/dev/sdb4       209717248 3907026943 3697309696  1.7T  f W95 Ext'd (LBA)
/dev/sdb5       209719296  226496511   16777216    8G 82 Linux swap / Solaris
/dev/sdb6  *    226498560  228595711    2097152    1G 83 Linux
/dev/sdb7       228597760  271032319   42434560 20.2G 83 Linux
/dev/sdb8       271034368  375891967  104857600   50G 83 Linux

Running sgdisk -p from home and the root of the data drive both return nothing.


You should be fine with the GUID of the disk but be careful with that. The UUIDs of the partitions and filesystems are more often used to and swapping those can be dangerous. The GUID is generally used by the bootloader to identify a disk type/use (Windows, FreeBSD, CoreOS Linux, etc). From what you have described that should be safe. To be even more safe back up the partition tables to a USB drive to restore them if need be. (sgdisk -b). This is because editing the partition table doesn't modify the blocks of data, only the boundaries of where they are.

To go into more detail about the UUIDs of partitions/filesystems:

Oftentimes the UUID of the filesystem can used for identify a boot device on a linux system. e.g.:

BOOT_IMAGE=/vmlinuz-4.4.14-200.fc22.x86_64 root=/dev/mapper/f20-root ro rd.lvm.lv=f20/root vconsole.font=latarcyrheb-sun16 rd.luks.uuid=luks-8cf2f2dc-5a3d-4cb4-9c09-e036b3812eac rd.lvm.lv=f20/swap rhgb quiet LANG=en_US.UTF-8

If you change the UUID on that disk, things will go haywire. Another place where things can get wonky on the partition side of things is in /etc/fstab:

# /etc/fstab
# Created by anaconda on Fri Dec 20 18:47:10 2013
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
 /dev/mapper/f20-root    /                                           ext4   defaults,x-systemd.device-timeout=0 1 1
UUID=44450fe5-24d0-468b-b20b-10c0127308dd /boot                      ext4   defaults        1 2
/dev/mapper/f20-home    /home                                        ext4   defaults,x-systemd.device-timeout=0 1 2
/dev/mapper/f20-swap    swap                                         swap   defaults,x-systemd.device-timeout=0 0 0

To get a better survey start out by running:

 lsblk -fa

This will show you all of the UUID information so you can swap around as needed.

  • Thanks! Quick initial question while I rund lsblk: Having never used sgdisk before, would running either of these commands really put me at risk of altering the UUID? I was under the impression that GUID and UUID were completely independent... I thought UUID was hardware dependent/specific. – EngBIRD Aug 22 '16 at 1:50
  • You are correct. They are independent. I just decided to err on the side of over explaining things to provide as much context as possible. If you save the output of sgdisk -b, sgdisk -p (just for a more readable version), and lsblk -fa (if you want to get really crazy you can do lsblk -O) and put them all on a USB disk you should be ready for anything partition wise. – Brian Redbeard Aug 22 '16 at 1:52
  • And no, they shouldn't modify the UUID. :) – Brian Redbeard Aug 22 '16 at 1:53
  • Thanks, a lot. I'm glad you added the UUID info, I got to learn something a little deeper. The confusion leading to my question, must have been some other disk "table" or index that is what is responsible for structuring bytes into files, that I was worried about overwritting. – EngBIRD Aug 22 '16 at 1:56
  • I hope this isn't a stupid question, but when I run sgdisk -p I don't get anything, and the when I check the manual it explicitly says "displays" not saves. Is this possibly a bad sign? – EngBIRD Aug 22 '16 at 2:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.