24 replies to this topic

[stepdown]

I replaced the internal CD drive of my 2008 laptop with a hard disk caddy featuring an IDE to SATA interface. This is the product link[1]. Then I moved the internal HDD to the caddy and added an SSD in the HDD slot. I can boot just fine from the SSD - it's basically just a disk from a boot perspective.  However, I can't boot from the HDD at all. Can it be done, and how? I'm planning to replace the SSD with a larger one, and move the current SSD to the caddy. I would like to be able to boot several OSes (Win7 and Linux) on the current SSD, where GRUB4DOS is the boot manager.

Thanks in advance for any help.

 

 

 

[1] https://www.aliexpre.../829743981.html

[steve6375]

Since you replaced the CD drive, the BIOS code would be expecting to boot from a 'CD'.

If the 'boot from CD' option does not work (or is not present) then the BIOS probably does not support it.

It might be possible to install a boot loader onto hd0 and use the boot menu from that to boot from the 'fake CD' drive.

 

You could test this by booting from a USB flash drive to say grub4dos, and then seeing if it can 'see' a valid formatted disk in the 'fake CD' slot?

[stepdown]

Thank you, Steve. The BIOS boot menu has CD/DVD as top priority, but booting goes straight to the grub4dos menu that's installed in the current SDD. I guess the BIOS CD boot code doesn't understand how to boot a HDD as a CD ?

[steve6375]

If you can get to the grub4dos console, type

find

geometry (hd0)

geometry (hd1)

 

does it list hd0 AND hd1 ? Assumes that both disks are partitioned...

 

If so, you should be able to boot from the hard disk to grub4dos and then boot to the 'fake CD' hard disk.

Edited by steve6375, 27 November 2017 - 10:01 PM.

[stepdown]

You're right!

[stepdown]

I was able to boot from hd1,1 from grub4dos. I got the Windows logo spinning for a while, then the computer went into lala land, blank screen or so. But I think Window was running in the background, because I could put my PC into and out of sleep mode by pressing the Power On key.

[steve6375]

Did you swap over disks? e.g. 

map (hd0) (hd1)
map (hd1) (hd0)
map --hook
root (hd0,1)
chainloader /bootmgr || chainloader ()+1
boot

[stepdown]

I think I don't need to swap over disks because the spinning Windows logo is an indication that it's booting Windows from hd1,1 - as I expected. What I didn't expect, and don't understand, is that the Windows logo goes away and the Windows desktop doesn't replace it. It's like Windows is only half booted. That last sentence is my interpretation of what I see.

Why did you ask if I swapped over disk, what did you have in mind?

[steve6375]

The 'fake CD' HDD may be classed as a Removable device? This would cause the symptoms if you are using a pre-1607 version of Windows 10.

Later versions Win 10 would be OK.

You can check this by booting to Windows on your internal disk and using DISKPART to look at the 2nd HDD

 

DISKPART

list disk

select disk 1

detail disk

 

any mention of 'removable' ??

[stepdown]

Interesting. Diskpart lists disks in opposite order vs. grub4dos. In other words

 

diskpart  type      grub4dos

disk 0     ATA       hd1

disk 1     SATA     hd0

 

Still, when I was booting hd1,1 with grub4dos I really did mean that partition.

Steve, diskpart doesn't mention "removable" for any disk.

However, I found out that the NTFS file system in hd1,1 is corrupted, so that's likely the cause for Windows not to start correctly. I will need to re-install.

[Wonko the Sane]

 

Interesting. Diskpart lists disks in opposite order vs. grub4dos. In other words

 

diskpart  type      grub4dos

disk 0     ATA       hd1

disk 1     SATA     hd0

 

Still, when I was booting hd1,1 with grub4dos I really did mean that partition.

Steve, diskpart doesn't mention "removable" for any disk.

However, I found out that the NTFS file system in hd1,1 is corrupted, so that's likely the cause for Windows not to start correctly. I will need to re-install.

 

Wait a minute.

 

It happens (not often but it happens) that *somehow* Windows drivers (when they rescan the hardware when switching to protected mode from real mode) get a different drive order from what BIOS (and thus grub4dos and similar) can see.

 

In your specific case, you have first boot device the "once CD" but *somehow* the BIOS rejects it from being first hard disk (because it expects a CD, because the converter inside the caddy is too slow for the BIOS, at bootup, *whatever*).

 

Grub4dos the "inherits" this mapping from BIOS.

 

When you chainload NTLDR or BOOTMGR, they have initially the same "inherited" device id, but when the Windows drivers interrogate the BIOS, they "see" that first device (boot device in BIOS) is actually a hard disk and then they set it as hd0, putting second device as hd1.

 

Since a number of "paths" in the early part f the Windows NT booting are relative to disk number (besides drive letter assignment) it is entirely possible that your windows failing to load comes from this.

 

Before any other attempt, check what happens in the Diskpart of the windows on the internal SSD, if you change the BIOS boot order, i.e.:

1) First device CD (hard disk in tray), second device hard disk (SSD)

vs.

2) First device hard disk (SSD), second device CD (hard disk in tray)

 

Does the ATA disk (hard disk in tray) remain "disk 0"?

 

Wonko 

[stepdown]

Thanks Wonko. Just tested, the ATA disk remains disk 0 regardless of its BIOS boot order being first or last.

[Wonko the Sane]

Thanks Wonko. Just tested, the ATA disk remains disk 0 regardless of its BIOS boot order being first or last.

Good, then most probably it is just a "scanning order" of the Windows drivers, first ATA, later SATA (or something like that)

now try (since you have grub4dos available) to exchange the disks in it before booting Windows.

i.e.:

map (hd0) (hd1)

map (hd1) (hd0)

map --hook

...

as Steve6375 suggested before, but then continue instead tried booting to the Windows on the SSD:

 

root (hd1,1)
chainloader /bootmgr
boot

 

If the diskpart disk order remains the same (and provided that the Windows on the SSD booted with the BIOS disks exhanged ), then the disk exchange could be put as "first thing" in the grub4dos menu.lst, before any boot choices, and you would have *always* the same disk order.

 

Wonko

[karyonix]

I don't understand. You are we troubleshooting Windows booting without specifying which Windows version.

BIOS boot option
In many computer, harddisk has only a single entry in main boot order list (among CD-ROM,Floppy,Removable).
Harddisk boot order is in another option item which allow user to set order among all harddisks (and SSD).
The first disk in the list become (hd0) when boot to GRUB4DOS.
Laptop BIOS may omit harddisk boot order option, but you should look for it to know whether this option exist.

BIOS also have boot menu that allow user to select which harddisk to boot.
The harddisk selected from boot menu become (hd0) when boot to GRUB4DOS.

I think I don't need to swap over disks because the spinning Windows logo is an indication that it's booting Windows from hd1,1 - as I expected. What I didn't expect, and don't understand, is that the Windows logo goes away and the Windows desktop doesn't replace it. It's like Windows is only half booted. That last sentence is my interpretation of what I see.
Why did you ask if I swapped over disk, what did you have in mind?

Your Windows does not boot from (hd1) successfully.
Don't think you don't have to swap them.
Try swap them. Make the drive you want to boot NTLDR/BOOTMGR (hd0).

Windows XP.
Make sure NTLDR and boot.ini is in active partition in (hd0).
Make sure (hd<number>) in GRUB4DOS match rdisk(<number>) in boot option ARC path in boot.ini.

Windows Vista-7-8-10.
Make sure BOOTMGR and boot\BCD is in active partition in (hd0).

Drive number in Windows does not matter.

[Wonko the Sane]

@Karyionix

 

This seems one of those "edge cases", the laptop BIOS was probably made with the assumption that devices were:

1) A (SATA) internal hard disk (now replaced by SSD)

2) A (IDE) CD/DDV drive in the caddy (now replaced by the hard disk + IDE to SATA converter).

 

since grub4dos can see both just fine, the IDE to SATA doesn't seem to be an issue.

 

But the BIOS may well be limited to believe that that the device attached to the caddy has to be optical media and as such it chains not the MBR but rather attempts to load sector 16 (possibly on a 2048 byte per sector device) when set as "boot device".

 

It would be - maybe - the case for some "reverse iso-hybrid" approach

 

As you say we have no data on the specific Windows version, and given the issue with the NTFS corruption, it is also possible that what the OP reported is caused - even if through grub4dos the hard disk in the caddy is chainloaded - by *something* that confuses disk order or drive letter assignment, after all the booting windows gets up to the logo and then seemingly fails to load logon/desktop, this is "after" any NTLDR or BOOTMGR possible problem, this usually happens when there is a mixup with drive letters.  

 

Wonko

[stepdown]

@Karyionix

thank you for your reply. But Wonko has the facts right; I'm on an "edge case".

 

@Wonko

I swapped over the disk with grub4dos and the diskpart order remains the same. You wrote: 

If the diskpart disk order remains the same (and provided that the Windows on the SSD booted with the BIOS disks exhanged  ), then the disk exchange could be put as "first thing" in the grub4dos menu.lst, before any boot choices, and you would have *always* the same disk order

 

If the diskpart order remains the same, as it is, doesn't Window already *always* have the same disk order? What' the benefit of adding the disk exchange to grub4dos menu?

[Wonko the Sane]

I swapped over the disk with grub4dos and the diskpart order remains the same. You wrote: 

If the diskpart order remains the same, as it is, doesn't Window already *always* have the same disk order? What' the benefit of adding the disk exchange to grub4dos menu?

As often happens, there is some difference between theory and practice.

In theory swapping the disks bears no consequence (as well as not swapping them).

In practice, if the disks in grub4dos do not appear the same as in Windows, before or later, you will issue a "destructive" command in grub4dos using the disk nomenclature you find in Windows (or viceversa).

 

It is only a (personal and) generic SMAP (Stupid Mistake Avoidance Policy) similar to the one along which (in my perverted mind) when you have a multi-os (Dos/Windows) booting system the same partition volume must always get the same drive letter (other people like to have different Windows installs on different partitions where the system drive letter is always "C:\" even if it is applied to different volumes depending on which install you boot to).

 

And yes, I have seen some of these people cry.

 

Now, back to the issue, if (and only if) you have the time and will to play with the thingy, the next attempt to make the disk drive in the caddy be bootable would be IMHO to try a Iso-Hybrid approach (of course with no guarantee whatever that it will ever work).

 

And possibly a "plain" iso-hybrid won't work and we will need to modify it to take into account the possible different sector size between 512 and 2048.

 

So, all in all, if once you will have reviewed the NTFS filesystem and/or corrected the Windows install on the hard disk you are OK with first booting from the internal SSD (to grub4dos or othe bootmanager) and from it boot the OS('s) installed on the caddy device, it would be only a (nice BTW) experiment.

 

Out of curiosity, are the devices both the exact same size?

The grub4dos screenshot you posted shows for both 14594/255/63 and 234452610 sectors, i.e. 120,039,736,320, around 120 GB.

 

Wonko

[stepdown]

 Hi Wonko,

 

Thanks for your continued support. We need to set aside SMAP and Iso-Hybrid approach for a moment because now we have a real non-booting case. Recall that the partition in the HDD caddy was corrupted, and that my ultimate goal was to replace the SSD with a larger one. So I did, and moved the smaller SSD to the HDD caddy. Now I have two cloned Windows partitions to boot from, the larger one in the main HDD slot, and the smaller one in the HDD caddy. Unfortunately, BSOD.

 

This is the larger SSD that replaced the smaller one:

/dev/sda1: UUID="2496E29E96E2702A" TYPE="ntfs" PARTUUID="051396f8-01"
/dev/sda2: LABEL="System Reserved" UUID="8E500369500356FD" TYPE="ntfs" PARTUUID="051396f8-02"
/dev/sda4: LABEL="WIN-P" UUID="000352A9000F2D09" TYPE="ntfs" PARTUUID="051396f8-04"
/dev/sda5: LABEL="BOOT" UUID="1676-EF88" TYPE="vfat" PARTUUID="051396f8-05"
/dev/sda6: LABEL="OS" UUID="b109ad1f-eef8-4623-a1f2-e86da390b290" TYPE="ext4" PARTUUID="051396f8-06"

unallocated space follows.

 

This is the smaller SSD that got replaced and moved to the HDD caddy located in the CD-drive slot, see my first post for physical interface info:

/dev/sdb1: UUID="3496E29E96E2702A" TYPE="ntfs" PARTUUID="051396f8-01"
/dev/sdb2: LABEL="System Reserved" UUID="9E500369500356FD" TYPE="ntfs" PARTUUID="051396f8-02"
/dev/sdb4: LABEL="WIN-P" UUID="100352A9000F2D09" TYPE="ntfs" PARTUUID="051396f8-04"
/dev/sdb5: LABEL="BOOTX" UUID="2676-EF88" TYPE="vfat" PARTUUID="051396f8-05"
/dev/sdb6: LABEL="OSx" UUID="c109ad1f-eef8-4623-a1f2-e86da390b290" TYPE="ext4" PARTUUID="051396f8-06"

I cloned the smaller SDD to the larger one using clonezilla with default parameters. Then I used methods [1] and [2] to change the UUIDs of all partitions on the smaller disk. Notice that each UUID in /dev/sdb is the same as the corresponding UUID of /dev/sda with the first hex digit augmented by 1. I also used gparted to change the labels of sdb5 and sdb6. This concerns my Linux bootloader entries, and I think it shouldn't matter for Windows.

 

[1] https://ubuntuforums...d.php?t=1240146

[2] http://schlemmersoft.de/en/node/180946

 

A glitch is that PARTUUIDs are the same between the two disks. I don't know how to change them, and I don't know if it matters, because I've never seen PARTUUIDs referenced in grub4dos. But maybe Windows and other bootloaders use them?

 

sda3 is the extended partition that holds sda5 and sda6. Similarly for sdb3.

sda2 and sdb2 are bootable. sda5 and sdb5 are hidden.

 

Windows grub4dos boot entry sda1:menu.lst (and sdb1:menu.lst). This entry used to work just fine when the smaller SSD (sdb) was in sda's place, and a Toshiba HDD was in the caddy (without booting it):

title Windows 7 (sda2:PBS)
  uuid 8E500369500356FD
  chainloader +1

Now that entry works to boot Win7 to a blue screen:

STOP 0x0000007B  0xFFFFF880009A9928
                 0xFFFFFFFFC0000034
                 0x0 0x0

My intention is to boot off the larger SSD entirely, but I think that the boot process follows the smaller SSD, because file BOOT/BCD.LOG1 in sdb2 is newer than the corresponding file in the larger SSD.

 

I didn't change BCD - not sure how to do it. I booted Hirens and opened sda2/Boot/BCD with BootICE in edit mode but I  don't see any partition UUID or PARTUUID to guide me. One thing I noticed is that the OS Title entry was changed from "Windows" to "Windows (recovered)". Possibly Windows attempted a repair on the first boot?  The OS Title entry of sdb3/Boot/BCD is still "Windows".

 

So, I'm stuck.

 

Out of curiosity, are the devices both the exact same size?

The grub4dos screenshot you posted shows for both 14594/255/63 and 234452610 sectors, i.e. 120,039,736,320, around 120 GB.

 

 

Yes, they are. I noticed the coincidence too, a Samsung SSD and a much older TOSHIBA HDD exactly the same. But the TOSHIBA is gone now.

Edited by stepdown, 11 December 2017 - 09:09 AM.

[Wonko the Sane]

Well, if you cloned the SSD you most probably duplicated also the Disk Signature (which should - I believe - be also the "base" for that PARTUUID).

 

The UUID is the actual volume serial.

 

Few things can make a mess on Windows systems like having a duplicate Disk Signature

Basically partitions/volumes (please read as drive letters) are identified/assigned by Windows by using the Disk Signature and the offset to the beginning of the partition, see:

https://web.archive....showtopic=19663

(only seemingly unrelated)

 

You can boot the one (or the other) SSD with grub4dos (or boot grub4dos from a USB stick) right?

 

For each hard disk/SSD run the command:

cat --hex --skip=440 --length=4 (hd0)+1

and (hd1), etc.

 

or anyway, check with a hex editor the MBR (first absolute sector of disk), you want to check the Disk Signature, at offset 440.

 

It is likely that both SSD will have "051396f8" (possibly inverted)

 

Change the Disk Signature of the SSD in the caddy (from grub4dos or Linux) to a *random* one or to "00000000".

Remove the caddy.

Boot the PC with only the internal SSD and (if needed) repair the Windows 7 install.

Shut it down, add the caddy and try again booting from the internal SSD.

 

If the above works (it should) we'll talk about the second (on the caddy SSD) Windows 7 install.

 

Wonko

[stepdown]

Well, if you cloned the SSD you most probably duplicated also the Disk Signature (which should - I believe - be also the "base" for that PARTUUID).

I don't know if clonezilla duplicated the disk signatures. Too late to tell now because the disk signatures aren't the same, and I didn't do anything to change them. So either clonezilla or Windows set a different disk signature for the cloned SSD. I used DISKPART UNIQUEID to confirm that the old SDD is still signed 051396F8 while the new SDD is signed 11481147.

The UUID is the actual volume serial.
...
Basically partitions/volumes (please read as drive letters) are identified/assigned by Windows by using the Disk Signature and the offset to the beginning of the partition, see:
https://web.archive....showtopic=19663
(only seemingly unrelated)
... 
check with a hex editor the MBR (first absolute sector of disk), you want to check the Disk Signature, at offset 440.
It is likely that both SSD will have "051396f8" (possibly inverted)
Change the Disk Signature of the SSD in the caddy (from grub4dos or Linux) to a *random* one or to "00000000".
Remove the caddy.
Boot the PC with only the internal SSD and (if needed) repair the Windows 7 install.
Shut it down, add the caddy and try again booting from the internal SSD.

I haven't done anything yet. I need to ask; given that trying to boot Win7 updates BCD.LOG1 on the old SSD, which is uniquely signed 051396F8, does it make sense to change the new SSD to 051396F8, with DISKPART or whatever, then remove the caddy SSD and try to boot Win7?

By the way, I ran DISKPART on WinXP and on Win7. The disk order is swapped between the two OS.

[Wonko the Sane]

When a Windows disk "realizes" that a hard disk signature is duplicated, it changes one of the two duplicates.

But there is no real way to know WHICH one is changed (and as such made practically unbootable).

 

I thought that the collision detection (and "silent" Disk Signature change) would have happened later in the boot process, but since the two disk signatures are now different whilst they were the same when you examined them in Linux before attempting the boot it means that the duplicate one is changed in the early part of booting.

 

Since the device in the caddy became first disk or (hd0) it would be logical that that disk signature was kept (as it was the first one read) and that the one changed was the (hd1), i.e. the internal SSD that you were trying to boot from, and since this happened in the midst of booting the whole thing crashed.

 

Yes , it makes sense to have ONLY the internal SSD connected and have that one with the 051396F8 for next attempt.

 

Alternatively you can clear the relevant DosDevices keys in the Registry (and possibly in the BCD), but simply having the original value Disk Signature on the "new" disk seems simpler to me.

 

AND then change the disk signature on the SSD in the caddy to *something else* BEFORE re-attempying booting with both SSD connected.

 

Wonko

[stepdown]

That did it  I changed the new SSD to the correct signature, then changed the old SSD signature to something else, disconneced the caddy and booted Win7 with no sweat. It looks intact, as far as I can tell. The new SSD is disk 1. Then I connected the caddy, and rebooted into Win7 on the new SSD again with no sweat. Next I need to figure out how to boot Win7 on the old SSD. My first attempt would be to add a grub4dos entry like:

title Windows 7 (sdb2:PBS)
  uuid 9E500369500356FD
  chainloader +1

The UUID corresponds to the old SSD in the caddy. That should do it. Any thoughts?

[Wonko the Sane]

That did it  I changed the new SSD to the correct signature, then changed the old SSD signature to something else, disconneced the caddy and booted Win7 with no sweat. It looks intact, as far as I can tell. The new SSD is disk 1. Then I connected the caddy, and rebooted into Win7 on the new SSD again with no sweat. Next I need to figure out how to boot Win7 on the old SSD. My first attempt would be to add a grub4dos entry like:

title Windows 7 (sdb2:PBS)
  uuid 9E500369500356FD
  chainloader +1

The UUID corresponds to the old SSD in the caddy. That should do it. Any thoughts?

 

Should do nicely, but check if grub4dos generated UUID is the same, just in case.

And -personally - I see no reason to chainload the bootsector (that will chainload the BOOTMGR) when you can directly chainload the BOOTMGR.

And still it probably remains the issue of disk numbering.

Under Linux you see that as sdb2 (2nd partition on 2nd disk) whilst in grub4dos (and Windows) you should be seeing it as 2nd partition on 1st disk.

 

So - still personally - I would have at the the beginning of menu.lst (common part):

map (hd0) (hd1)

map (hd1) (hd0)

map --hook 

....

and then:

 

title Windows 7 (sdb2:PBS)
root (hd1,1)
chainloader /bootmgr

 

but both should make no difference and should work.

 

Wonko

[karyonix]

The old drive which has new disk signature needs the new disk signature in BCD and also needs drive letter assignment in its registry.
You can use bcdedit to update the BCD.
Assume you boot from new SSD which is now C:, the old SSD system partition is now S: and old SSD Windows partition is now W:.
If the offline system partition does not currently have drive letter, assign a drive letter to it (S:).
S: and W: can be the same drive use that drive letter in place of S: and W:.
Open command prompt run as administrator.
Read BCD in S:.

bcdedit /store S:\Boot\BCD

Copy the "Windows Boot Manager"'s "default" {id} value. you will use it in following commands.

bcdedit /store S:\Boot\BCD /set {bootmgr} device partition=S:
bcdedit /store S:\Boot\BCD /set {id} device partition=W:
bcdedit /store S:\Boot\BCD /set {id} osdevice partition=W:

The next is drive letter registry.
Backup the file W:\Windows\system32\config\SYSTEM before you edit it.
The following commands will edit W:\Windows\system32\config\SYSTEM.
Read the value for drive W: and C: in currently running system

reg query HKLM\SYSTEM\MountedDevices /v \DosDevices\W:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
\DosDevices\W: REG_BINARY BBBBBBBB0000100000000000

reg query HKLM\SYSTEM\MountedDevices /v \DosDevices\C:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices
\DosDevices\C: REG_BINARY AAAAAAAA0000100000000000

Load the registry hive.

reg load HKLM\TTTTTT W:\Windows\system32\config\SYSTEM

Set value from currenly running W: to offline Windows' C:.

reg set HKLM\TTTTTT\MountedDevices /v \DosDevices\C: /t REG_BINARY /d BBBBBBBB0000100000000000

Set value from currenly running C: to offline Windows' X:.

reg set HKLM\TTTTTT\MountedDevices /v \DosDevices\X: /t REG_BINARY /d AAAAAAAA0000100000000000

Save and close the registry hive.

reg unload HKLM\TTTTTT

[Wonko the Sane]

Ooops. 

I thought that it was going to be a new install on the SSD in the caddy.

 

If course Karyionix is right-on-spot  if you are going to re-use the "old" install of 7, you need to fix the \boot\BCD and drive letter assignments.

 

Personally I would use the Offline Registry instead:

http://reboot.pro/to...fline-registry/

but that is just the preferred tool.

 

Back to the SMAP possible issue, however, the end result will be two different Windows 7 installs residing on two different disks that when booted will have C:\ assigned to "self", unless you have a very evident way to distinguish them (like - say - a green background on one and a red background on the other) before or later you will risk doing the "right" thing on the "wrong" C:\ ...

 

Wonko