1

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
sda                                                                
├─sda1                                                             
└─sda2 ntfs   COMPUTER        16 digit alpha numeric code
sdb                                                                
├─sdb1 ntfs   System Reserved 16 digit alpha numeric code                     
├─sdb2 ntfs                   16 digit alpha numeric code                     
├─sdb3 ntfs                   16 digit alpha numeric code                     
├─sdb4                                                             
├─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
sr0

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.

Community
  • 1
EngBIRD
  • 111

1 Answers1

1

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.

Brian Redbeard
  • 3,018
  • 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 01: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 01:52
  • And no, they shouldn't modify the UUID. :) – Brian Redbeard Aug 22 '16 at 01: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 01: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 02:08
  • Potentially, yes. That could mean that there is no partition on the disk. In the case of your raw data disk, that's (probably) OK as you mentioned that the entire device was in use. It's not great as having a partition on there would be better, but not catastrophic. – Brian Redbeard Aug 22 '16 at 02:09
  • Very strange, I can clearly see the partition table when I run lsblk -fa, and the computer only boots when this data drive is plugged in so there must be a partition table. Didn't occur to me before, but perhaps running sgdisk -p from the OS itself, didn't see the data drive, and only saw the disk where the root partition was. Still things to investigate tomorrow. – EngBIRD Aug 22 '16 at 02:22
  • Ahh, then that disk doesn't have a GPT, it has an MBR. In that case run fdisk -l on the disk to print it. – Brian Redbeard Aug 22 '16 at 02:36
  • It should be expected that each disk would have a different partition table right? I see a GPT table and a MSDOS table in the new information I added to my question. Will these existing MSDOS formated tables interfere with the sgdisk commands? – EngBIRD Aug 25 '16 at 19:26
  • That is correct. Also the MBR (Master boot record) and GPT are stored at different places on disk so making a change to one does not always mean it will be implemented on the other. Some commands like gdisk will detect differences and warn the user. Upon start, sgdisk attempts to identify the partition type in use on the disk. From the man page: "If it finds valid GPT data, sgdisk will use it. If sgdisk finds a valid MBR or BSD disklabel but no GPT data, it will attempt to convert the MBR or disklabel into GPT form." http://linux.die.net/man/8/sgdisk – Brian Redbeard Aug 27 '16 at 21:22