Can't boot after disk restore. EFI mapping issue?

[Robert Yung]

On a rx2620 running Windows, I took a Symantec Ghost image of the local disk array. This was accomplished by booting the server from a SAN drive with another copy of Windows.

Things happened to the OS on the local array and I needed to re-apply the Ghost image to the local array to start over. I do that, detach the SAN drive, and try to boot off the local array, but it complains that the requested boot item is not found.

I jump into the built-in EFI shell, run 'map', and see that the only filesystem (fs0) mounted is the cd-rom, which has a Smart Setup CD. Scanning the BLKx entries, I do see the local array drive and the two partitions in it (efi + windows).

Running 'map -r' didn't make a difference.

The GUIDs for the partitions have changed so I figured I need update the boot menu entry by mapping the efi partitions to fsX, find the wiindows boot options file, and use nvrboot.efi to add a boot menu entry to it.

Using 'dh -p diskio' and 'map', I map fs0 to the first partition and fs1 to the second partition.

But when I go to the new fs0 and do a 'ls', it says:
ls: cannot open current directory - No mapping

'map' shows:
blk0 : acpi(hwp0002,0)/pci/(2|0)/ata(primary,master)
blk1 : acpi(hwp0002,0)pci(2|0)/ata(primary,master)/cdrom(entry0)
blk2 : acpi(hwp0002,200)/pci(1|0)/pci(4|0)
/scsi(pnu0,lun0)
blk3 : acpi(hwp0002,200)/pci(1|0)/pci(4|0)
/scsi(pnu0,lun0)/hd(part1,sig18ac467c-da38-4fbe-8cab-e7e6cc186d38)
blk4 : acpi(hwp0002,200)/pci(1|0)/pci(4|0)
/scsi(pnu0,lun0)/hd(part1,sig64880c47-abad-42d6-af93-203647842c76)

fs1 : acpi(hwp0002,200)/pci(1|0)/pci(4|0)
/scsi(pnu0,lun0)/hd(part1,sig64880c47-abad-42d6-af93-203647842c76)

fs0 : acpi(hwp0002,200)/pci(1|0)/pci(4|0)
/scsi(pnu0,lun0)/hd(part1,sig18ac467c-da38-4fbe-8cab-e7e6cc186d38)

If I boot to the SAN drive Windows again, I can see the efi partition on the local drive. I can even mount it and look at the contents, which looks to still be intact.

If I boot off the Smart Setup CD and go to Create Partition option, it does show that it detects an EFI partition on the local disk.

So any idea how I can fix this? Is there some sort of fix-efi tool?

Thanks!

[kris rombauts]

Hi Robert,

some questions:

- You mentioned some issues with the array, so was the local array config erased and re-created i.e. ? or did you only restored the Windows partition from the GHOST image ?

- can you post the exact error message that
you see when you try to boot and a map-r
output as it appears on the screen with
and without the SAN disk connected ?

- this is Windows 2003 , right ?
- can you boot from the SAN drive when the
local disks are removed ? I guess not.
What most likely occured is that, when you
installed Windows OS on the SAN disk,
the bootfile was updated with the new
partition GUID's and as such it is normal
that, when you disconnect the SAN disk
now, that the bootentry does not find
those partition GUID's (since they are the
ones from the SAN disk and not the ones
anymore from the local disk.
To avoid this in the future, disconnect
the local disks and do the installation on
the SAN disk, then a EFI partition will
also reside there.

Can you post the binary bootfile here in
the forum ?, it is located in
fsx:\efi\Windows\Winnt50\
If you don't see it type 'attrib' since it
can be hidden.


regards, Kris

[Robert Yung]

There is nothing wrong with the array... someone just messed up the OS. The array was not re-created. I should have just restored the Windows partition, but I wanted to test a full restore so I restored the entire disk, including the EFI partition.

My Windows 2003 boot menu item is named:
"Win2003ent, Local"

If I try to load it, it'll say:
"Loading: Win2003ent, Local
Load of Win2003ent, Local failed: Not Found
Press any key to continue"

Perhaps my mentioning of the SAN is complicating things. The point of the SAN drive is so I can boot off a drive that is different from the local drive so I can run Ghost to image it. I can't use a normal Ghost boot disk since that disk is based on WinPE and WinPE can't support a 32bit application such as Ghost.

When I first installed Windows to the local drive, I did not have the SAN drive connected. And when I installed Windows to the SAN drive, I did not have the local drives connected. This was done to ensure that both SAN and local drives have their own independent EFI partitions. My plan was to use the SAN drive like a boot disk to help me image backup or restore the local drives of servers.

Yes, the GUID had changed after the restore but I don't think that is the main problem. The problem is that I can't access the fsx that contains \efi\Windows\Winnt50\. Map shows that partition there but it just won't let me access it.

map -r:

fs0 : acpi(hwp0002,0)pci(2|0)/ata(primary,master)/cdrom(entry0)

blk0 : acpi(hwp0002,0)/pci/(2|0)/ata(primary,master)

blk1 : acpi(hwp0002,0)pci(2|0)/ata(primary,master)/cdrom(entry0)

blk2 : acpi(hwp0002,200)/pci(1|0)/pci(4|0)
/scsi(pnu0,lun0)

blk3 : acpi(hwp0002,200)/pci(1|0)/pci(4|0)
/scsi(pnu0,lun0)/hd(part1,sig18ac467c-da38-4fbe-8cab-e7e6cc186d38)

blk4 : acpi(hwp0002,200)/pci(1|0)/pci(4|0)
/scsi(pnu0,lun0)/hd(part1,sig64880c47-abad-42d6-af93-203647842c76)


It's picking up the filesystem on the Smart Setup CD but not the efi partition on blk3. If I cd to blk3 and type ls, I get:
"ls: cannot open current directory - No mapping
exit status code: no mapping"

It could be that Ghost doesn't support EFI partitions and somehow restored it wrong. But if I boot off the SAN, I can mount that efi partition in Windows and see its contents and Smart Setup does say an efi partition is present, though it may only be doing a superficial check. I wonder if there is something like fixmbr for efi: fixefi.

[kris rombauts · Accepted solution]

OK, thanks for clarifying, the way you installed it is indeed the correct way to make sure each disk has it's EFI partition and this allows you to boot from each disk independently without the presence of the other disk.

When you mount the EFI partition (when booting from SAN), how are you sure you mounted the EFI partition on the local disk and not the one on the SAN boot disk ?

Can you provide the map output and binary boot file from that mounted EFI partition(efi\Microsoft\Winnt50\...) when booted from the SAN disk ?


Another restore scenario you could do is to re-create the EFI/MS-RES and HPSP(optional) partitions on the local disks using the SmartSetup cd and then stop there before the Windows CD is needed. Then restart, boot from SAN disk and do your restore procedure and only restore the Windows partition.

It seems that at this time, you are missing at least one partition in the map output because the normal partition layout is EFS/MS-RES/MSDATA or EFS/MS-RES/HPSP/MSDATA so 3 or 4 partitions, it depends if you also created the HP Services Partition or not (optional). If we don't look at the cd-rom fs: and blk: devices in the map output then we only see two, not three partitions (3 is the minimum for a Windows system).


When booted from the SAN disk, and running the commands diskpart, list disk , select disk x, list partitions you can see the layout of the different disks (local and SAN boot disk) i.e.

A normal, working disk layout would look like this:

DISKPART> list partition

Partition ### Type Size Offset
------------- ---------------- ------- -------
Partition 1 System 100 MB 17 KB
Partition 2 OEM 400 MB 100 MB
Partition 3 Reserved 128 MB 500 MB
Partition 4 Primary 68 GB 628 MB

(assuming you only have one NTFS partition on the boot disk and also have a HPSP).

Pls note the 128 Mbyte partition is not visible in Windows disk managers GUI.



Kris

[Robert Yung]

You're right in that not all the original partitions made it through the restore. Checking my notes on the original config, there were four partition visible from EFI (efi + hpsp + msr + windows). After the restore, I only see efi + windows. I used the Smart Setup CD to create the efi + hpsp + msr partitions, but the efi partition is empty. I'm guessing it's up to the windows installation to fill that as well as to add a boot entry to nvram.

I do have a copy of the file contents of the original EFI partition, so I booted back to my san drive, mounted the new EFI partition, and copied the original files there. Now I need to add a boot entry. I run the \msutil\nvrboot.efi and import \efi\microsoft\winnt50\boot0006. But if I use nvrboot.efi to view the contents of the new boot entry, fields EfiOsLoaderFilePath and OsLoaderFilePath point to GUIDs that don't match my current partition GUIDs. I try to edit those fields but the tool tells me those fields are not modifiable. Do I need to use cryptic bootcfg tool to make the necessary changes?

I also tried to use the EFI Boot Manager gui to add a boot entry, which allows to add \efi\microsoft\winnt50\ia64ldr.efi. But if I try to boot it, I get this error:

"Windows could not start because there was an error reading the boot settings from NVRAM.
Please check your firmware settings. You may need to restore your NVRAM settings from a backup."

Running ia64ldr.efi directly from the efi shell gets the same error.

Attached is \EFI\Microsoft\WINNT50\boot006.

Does it look like I'm making progress or do I really need to travel to the data center, pop in the Windows cd, and re-install?

Thanks!
Robert

[Michael Steele_2]

Hi

Can't read your attach. Please save as .txt file.

Thanks!

[Robert Yung]

Michael,

Boot0006 is a binary file. When I download the attachment from my post, it comes out as 346427.null, which you can rename to 346427.txt if you like.

Attached is a screen capture of the file in hex.

If I import the file into nvrboot.efi, it creates this boot entry:

LoadIdentifier = Windows Server 2003, Enterprise

OsLoadOptions = /noexecute=optout /redirect

EfiOsLoaderFilePath = 13814000-1dd2-1000-9e76-0017087c09c8 :: \\EFI\Microsoft\WINNT50\ia64ldr.efi

OsLoaderFilePath = 6ace2c80-63a9-01ca-alf4-04622fd5ec6d :: \WINDOWS

The GUID's referenced by EfiOsLoaderFilePath and OsLoaderFilePath no longer match the GUIDs of the actual partitions. If the GUIDs are encoded into the boot0006 file, then I need to figure out a way to edit that file.

Robert

[kris rombauts]

Robert,

what you need to do is:

1)re-create the 3 partitions using the
SmartSetup CD
2)restore the Windows OS
3)collect the map output to show the disk
partitions GUID's


Then the binary boot file can be re-created based on the original boot file by replacing the GUID's and i'll send you a boot file that you need to import using nvrboot.
nnvrboot itself does not allow to edit those fields, you need a hex editor or hexedit from the build in efi commands (less user friendly).


With the map output you showed now i can't fix it since the disk partition GUID's will be different again when you did step 1) and 2) above.
No need to re-attach the boot file again as that file is static now.


Kris

[Robert Yung]

Success! I had thought about hex editing the boot file but at first glance couldn't find the GUIDs. When you suggested the same idea, I took another look and this time searched from right-to-left. Turns out, the first half of the GUIDs are reversed for some reason.

See below:
[original]
efi partition guid:
on screen: 13 81 40 00 - 1D D2 - 10 00 - 9E 76 00 17 08 7C 09 C8
on file: 00 40 81 13 - D2 1D - 00 10 - 9E 76 00 17 08 7C 09 C8

win partition guid:
on screen: 6A CE 2C 80 - 63 A9 - 01 CA - AL F4 04 62 2F D5 EC 6D
on file: 80 2C CE 6A - A9 63 - CA 01 - AL F4 04 62 2F D5 EC 6D

[new]
efi partition guid:
on screen: 2D 22 87 80 - 1D D2 - 10 00 - A4 A8 00 17 08 7C 09 C8
on file: 80 87 22 2D - D2 1D - 00 10 - A4 A8 00 17 08 7C 09 C8

win partition guid:
on screen: 4E A5 FD 0B - 24 45 - 47 D9 - A0 7E D8 63 C0 71 E7 A5
on file: 0B FD A5 4E - 45 24 - D9 47 - A0 7E D8 63 C0 71 E7 A5

See the attached png to see what I mean. Red means those set of hex are reversed while green means it's normal.

If microsoft kept the boot backup file in text format, like boot.ini, then this would have been much easier.

I updated the boot file, imported it, and now I can boot. Woohoo! Now I at least have a way, be it convoluted, to restore a system and hopefully find a faster way to image backup and restore the drive.

Thanks!
Robert

[kris rombauts]

Glad you figured it out yourself, yes part of the disk GUID is written in little endian format.

In windows 2008 we don't face this issue anymore because the information needed to boot is managed differently.


Kris