Mistakenly used wrong partition table format when backing up a drive

PhotonX · 2022-09-14 15:01:50

Hi guys,

I need to send in my laptop for a repair and thus have to back up my drive. I'm not at all familiars with backups, so what I did was simply copying all partitions of the internal SSD to an external HDD. I then wanted to test, if everything is in place and boot from the external HDD. Before doing so, I did a chroot, edited the fstab to reflect the changed UUID values and reinstalled GRUB. However, I still couldn't boot from the external HDD, grub said "no such partition" and put me into a rescue prompt.

So my guess is that stupid me forgot to recreate the partition table on the external HDD (gpt on the internal SSD, msdos on the external HDD). Is this a likely reason for the system refusing to boot? If so, is there anything I can do, which is not involving purging the external HDD, creating a new gpt partition table and doing the backup again?

Thanks for any hints!
PhotonX

jonno2002 · 2022-09-14 15:31:45

gpt to dos(mbr) partition table is fine, just make sure to install the correct grub, for example:

grub-install --target=i386-pc /dev/sdX

if you copied the efi partition over it just wont be used.

another issue could be not running mkinitcpio in the chroot so its compatible with the current setup.

EDIT: oh also when you re-installed grub did you run grub-mkconfig as well !

Last edited by jonno2002 (2022-09-14 15:37:38)

PhotonX · 2022-09-14 16:55:58

Well, initially, I didn't, but now I did. But it didn't help. What is it about the mkinitcpio?

I tried "ls" in the grub rescue shell and it gave me a "hd0" without further subvolumes (that's the HDD) and a "hd1" with subvolumes hd1,gpt1 to 3 (that's the SSD). So, grubb doesn't see any partitions on the HDD at all...

jonno2002 · 2022-09-15 02:05:23

post output of

fdisk -l

as for mkinitcpio im pretty sure that it looks for the uuid of the root file system and since you've changed that it wont work, it is recommended to be done here in the wiki: https://wiki.archlinux.org/title/Migrat … _to_bottom

PhotonX · 2022-09-15 08:14:15

This is the output, when attached the HDD to another laptop (no chroot):

Disk /dev/sdc: 149.05 GiB, 160041884672 bytes, 312581806 sectors
Disk model: Storage Device  
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: dos
Disk identifier: 0x000289bb

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sdc1            2048    616447    614400  300M 83 Linux
/dev/sdc2          616448 154216447 153600000 73.2G 83 Linux
/dev/sdc3       154216448 172673023  18456576  8.8G 82 Linux swap / Solaris
/dev/sdc4       172673024 312580095 139907072 66.7G  7 HPFS/NTFS/exFAT

Maybe an output from chroot is more helpful?

jonno2002 · 2022-09-15 15:13:51

that all looks fine, im guessing sdc1 is the efi partition which wont be used but you can still have it mounted in fstab as it wont do any harm, and may be required if it contains all of "/boot".

can you post your fstab as well please i should have asked for it before.

PhotonX · 2022-09-15 21:59:16

Sure! Here it is:

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a device; this may
# be used with UUID= as a more robust way to name devices that works even if
# disks are added and removed. See fstab(5).
#
# <file system>					<mount point>		<type>		<options>		<dump>  <pass>
UUID=C614-082A					/boot/efi		vfat		umask=0077		0	2
UUID=5d6faa93-bc73-4dc6-b177-162baab4fe33	/			ext4		defaults,noatime	0	1
UUID=846509b6-429c-44e7-9937-f73f0b1b6887	swap			swap		defaults,noatime	0	0

The UUIDs are from the sdc partitions listed in the fdisk output as reported by GParted (besides of the exfat partition which is not present in the fstab).

What is a bit strange is that the efi partition is correctly reported as fat32 in GParted (as it has been on the original machine) and correspondingly is mounted as vfat in the fstab but is recognized as "Linux" in the fdisk output -- is this correct? I'm not sure what the "Linux" partition type means in fdisk.

Last edited by PhotonX (2022-09-15 22:04:21)

jonno2002 · 2022-09-16 00:04:01

ok well it seems like youve done everything right, the efi partition is irrelevant as your not using it and i can now see that /boot is not on the efi partition which is what i thought might be happening.

you can remove the efi partition from the fstab if you want.

boot up from the ssd and mount "5d6faa93-bc73-4dc6-b177-162baab4fe33" to /mnt then chroot in and run these commands:

grub-install --target=i386-pc /dev/sdX
grub-mkconfig -o /boot/grub/grub.cfg
mkinitcpio -p linux

replace sdX with the hdd (sdc possibly but always check)

and that SHOULD work

EDIT: always forgot somthing... you should probably add the 'boot' flag to the root partition (5d6faa93-bc73-4dc6-b177-162baab4fe33), sounds like youve been using gparted so just use that to set the root partition as bootable.

Last edited by jonno2002 (2022-09-16 00:11:44)

cfr · 2022-09-16 04:34:29

Does your firmware support booting in legacy (compatibility) mode and, if so, is it configured to do so?

Better to use arch-chroot than plain chroot as it sets up various things which grub may look for when you're installing it.

PhotonX · 2022-09-16 08:52:44

Hi guys, thanks for the ideas!

In the mean time I had to send away the laptop and therefore it isn't necessary to check if the backup has worked properly (I couldn't do anything about it, even if it hadn't). So I guess, I will wait till it is back and see how restoring the backup works out. I deleted my user (including his home dir) on the laptop and made two backups before that: The complete partitions backup and, additionally, a tar.gz archive of the user's home dir. I hope that they won't format my drive and thus recreating my user and unpacking the home dir backup archive will be sufficient to restore the system to the original state, so the partitions won't come into play at all. If not, I will probably have many more questions. I will report back how the story went on in any case!

Last edited by PhotonX (2022-09-16 08:53:31)

Arch Linux

#1 2022-09-14 15:01:50

Mistakenly used wrong partition table format when backing up a drive

#2 2022-09-14 15:31:45

Re: Mistakenly used wrong partition table format when backing up a drive

#3 2022-09-14 16:55:58

Re: Mistakenly used wrong partition table format when backing up a drive

#4 2022-09-15 02:05:23

Re: Mistakenly used wrong partition table format when backing up a drive

#5 2022-09-15 08:14:15

Re: Mistakenly used wrong partition table format when backing up a drive

#6 2022-09-15 15:13:51

Re: Mistakenly used wrong partition table format when backing up a drive

#7 2022-09-15 21:59:16

Re: Mistakenly used wrong partition table format when backing up a drive

#8 2022-09-16 00:04:01

Re: Mistakenly used wrong partition table format when backing up a drive

#9 2022-09-16 04:34:29

Re: Mistakenly used wrong partition table format when backing up a drive

#10 2022-09-16 08:52:44

Re: Mistakenly used wrong partition table format when backing up a drive

Board footer