[SOLVED] (U)EFI dualboot Win7 Arch Linux - partitions gone - recovery?

Question

Hi everybody,
I have a slight problem with my (U)EFI dualboot system (Windows 7 and Arch Linux) which used to be configured using rEFInd like it is described in my previous post:
https://bbs.archlinux.org/viewtopic.php … 6#p1300356
<EFI PARTITION> is /dev/sda1 and I used to boot via <EFI PARTITION>\EFI\Boot\Bootx64.efi which then successfully either loaded Windows or Linux kernel.
Thanks to my own stupidity and a recent update of refind I decided to copy the new driver, font and icon folders to the <EFI PARTITION> in order to be up-to-date.
After doing so, the rEFInd boot menu had a third icon which said "Boot via \EFI\Boot\Bootx64.efi" and if I clicked on it a second rEFInd boot menu appeared with only the two icons for Windows 7 and Arch.
So I figured I could delete Bootx64.efi and ultimately did so, unfortunately. Afterwards I couldn't boot neither Windows nor Linux anymore.
Following this I went through my noumerous USB boot sticks in order to be able to recover the Bootx64.efi. Unfortunately the first USB stick was a Windows XP one which has the plop bootloader alongside:
http://www.plop.at/en/bootmanager/thebootmanager.html
Out of couriousity I entered this bootloader and found HDA and HDB (I assume resembling my SSD and my USB stick).
To my knowledge I didn't change anything but after entering the bootloader again I just found HDA left, HDB seemed to be gone. But I didn't think of anything bad happening yet.
Then I found a working Archiso which I booted and using blkid I couldn't find the partitions of my earlier system anymore, only its device and the USB stick:
/dev/sda: PTUUID="..." PTTYPE="gpt"
/dev/sdb1: UUID="..." LABEL="ARCH_201312" TYPE="..." and so on
/dev/sdb2: SEC_TYPE="msdos" and so on
Even within the EFI shell I could not detect any internal drive anymore (only fs0: which is the USB stick)
Using Archiso onboard tool testdisk I could find the old partitions. The correct result of the GPT from testdisk is:
Fri Jul 4 08:45:25 2014
Command line: TestDisk
TestDisk 6.14, Data Recovery Utility, July 2013
Christophe GRENIER <[email protected]>
http://www.cgsecurity.org
OS: Linux, kernel 3.12.1-3-ARCH (#1 SMP PREEMPT Tue Nov 26 11:17:02 CET 2013) x86_64
Compiler: GCC 4.8
Compilation date: 2013-08-06T08:42:31
ext2fs lib: 1.42.8, ntfs lib: libntfs-3g, reiserfs lib: 0.3.0.5, ewf lib: none
/dev/sda: LBA, HPA, LBA48, DCO support
/dev/sda: size 500118192 sectors
/dev/sda: user_max 500118192 sectors
/dev/sda: native_max 500118192 sectors
/dev/sda: dco 500118192 sectors
Warning: can't get size for Disk /dev/mapper/control - 0 B - 1 sectors, sector size=512
Hard disk list
Disk /dev/sda - 256 GB / 238 GiB - CHS 31130 255 63, sector size=512 - Samsung SSD 840 PRO Series, S/N:S12RNEAD322171L, FW:DXM04B0Q
Disk /dev/sdb - 2013 MB / 1920 MiB - CHS 1022 62 62, sector size=512 - SMI USB DISK, FW:1100
Disk /dev/sdc - 4210 MB / 4015 MiB - CHS 1020 130 62, sector size=512 - Generic Flash Disk, FW:8.07
Disk /dev/mapper/arch_root-image - 1478 MB / 1410 MiB - 2887680 sectors, sector size=512
Disk /dev/dm-0 - 1478 MB / 1410 MiB - 2887680 sectors, sector size=512
Partition table type (auto): Intel
Disk /dev/sda - 256 GB / 238 GiB - Samsung SSD 840 PRO Series
Partition table type: EFI GPT
New options :
Dump : No
Align partition: Yes
Expert mode : Yes
Analyse Disk /dev/sda - 256 GB / 238 GiB - CHS 31130 255 63
hdr_size=92
hdr_lba_self=1
hdr_lba_alt=500118191 (expected 500118191)
hdr_lba_start=34
hdr_lba_end=500118158
hdr_lba_table=2
hdr_entries=128
hdr_entsz=128
hdr_size=92
hdr_lba_self=500118191
hdr_lba_alt=1 (expected 1)
hdr_lba_start=34
hdr_lba_end=500118158
hdr_lba_table=500118159
hdr_entries=128
hdr_entsz=128
Trying alternate GPT
Current partition structure:
Trying alternate GPT
search_part()
Disk /dev/sda - 256 GB / 238 GiB - CHS 31130 255 63
FAT32 at 0/32/33
FAT1 : 4110-6150
FAT2 : 6151-8191
start_rootdir : 8192 root cluster : 2
Data : 8192-2097151
sectors : 2097152
cluster_size : 8
no_of_cluster : 261120 (2 - 261121)
fat_length 2041 calculated 2041
set_FAT_info: name from BS used
FAT32 at 0/32/33
MS Data 2048 2099199 2097152 [NO NAME]
FAT32, blocksize=4096, 1073 MB / 1024 MiB
NTFS at 146/251/42
filesystem size 249593856
sectors_per_cluster 8
mft_lcn 786432
mftmirr_lcn 2
clusters_per_mft_record -10
clusters_per_index_record 1
NTFS part_offset=1209008128, part_size=127792054272, sector_size=512
NTFS partition cannot be added (part_offset<part_size).
NTFS at 146/251/42
filesystem size 249593856
sectors_per_cluster 8
mft_lcn 786432
mftmirr_lcn 2
clusters_per_mft_record -10
clusters_per_index_record 1
MS Data 2361344 251955199 249593856
NTFS, blocksize=4096, 127 GB / 119 GiB
recover_EXT2: s_block_group_nr=0/160, s_mnt_count=1318/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 5242880
recover_EXT2: part_size 41943040
MS Data 251955200 293898239 41943040
ext4 blocksize=4096 Large file Sparse superblock, 21 GB / 20 GiB
recover_EXT2: s_block_group_nr=0/80, s_mnt_count=1317/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 2621440
recover_EXT2: part_size 20971520
MS Data 293898240 314869759 20971520
ext4 blocksize=4096 Large file Sparse superblock, 10 GB / 10 GiB
recover_EXT2: s_block_group_nr=0/706, s_mnt_count=1317/4294967295, s_blocks_per_group=32768, s_inodes_per_group=8192
recover_EXT2: s_blocksize=4096
recover_EXT2: s_blocks_count 23156049
recover_EXT2: part_size 185248392
MS Data 314869760 500118151 185248392
ext4 blocksize=4096 Large file Sparse superblock, 94 GB / 88 GiB
Results
P MS Data 2048 2099199 2097152 [NO NAME]
FAT32, blocksize=4096, 1073 MB / 1024 MiB
P MS Data 2361344 251955199 249593856
NTFS, blocksize=4096, 127 GB / 119 GiB
P MS Data 251955200 293898239 41943040
ext4 blocksize=4096 Large file Sparse superblock, 21 GB / 20 GiB
P MS Data 293898240 314869759 20971520
ext4 blocksize=4096 Large file Sparse superblock, 10 GB / 10 GiB
P MS Data 314869760 500118151 185248392
ext4 blocksize=4096 Large file Sparse superblock, 94 GB / 88 GiB
interface_write()
1 P MS Data 2048 2099199 2097152 [NO NAME]
2 P MS Data 2361344 251955199 249593856
3 P MS Data 251955200 293898239 41943040
4 P MS Data 293898240 314869759 20971520
5 P MS Data 314869760 500118151 185248392
simulate write!
TestDisk exited normally.
ext4 blocksize=4096 Large file Sparse superblock, 94 GB / 88 GiB
Now the question is: Can I - using testdisk or any other tool - recover those partitions successfully so I will be able to boot again afterwards? I tested and I could mark them as:
P Primary
Any help will be greately appreciated.
Best regards
Last edited by blablubb1234 (2014-07-08 09:20:08)

Answer 1

Issue resolved If you care to know how, read on:
Looking at the disk using gdisk was doing no good. Neither of the recovery options in gdisk did the trick.
I then returned to testdisk and restored the partitions (successfully). However, afterwards I was greeted by shell telling me the root device was not found (seems like UUIDs get changed when one restores them using testdisk). Adjusting the PARTUUID for root in <EFI SYSTEM PARTIITION>/boot/refind_linux.conf did the trick and I could boot up Archlinux again.
Windows 7 still didn't boot telling me the required device was inaccessible (probably wrong UUID, too). I could however not restore/edit Windows' BCD using bcdedit, see my post Status: 0xc0000225 boot selection failed; required device inaccessible:
To make a long story short: Removing bcd and running autorecovery from withing Windows RE successfully created a new bcd. Unfortunately, Windows writes its backup bootloader at <EFI SYSTEM PARTITION>/boot/EFI/Boot/bootx64.efi. This file originally was a copy of refind_x64.efi which I need to put at that location to be able to dualboot. After chrooting to my Arch system I could restore bootx64.efi, create a new fstab and everything is running fine now again.
Best regards and thanks for the help.