Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.os.linux > #81360 > unrolled thread

migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board

Back to article view | Back to alt.os.linux

Contents

  migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board bad sector <forgetski@_INVALID.net> - 2025-04-12 19:50 -0400
    Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board Paul <nospam@needed.invalid> - 2025-04-12 20:40 -0400
      Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board bad sector <forgetski@_INVALID.net> - 2025-04-13 22:42 -0400
      Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board bad sector <forgetski@_INVALID.net> - 2025-04-22 16:40 -0400
        Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board Paul <nospam@needed.invalid> - 2025-04-23 09:38 -0400
          Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board bad sector <forgetski@_INVALID.net> - 2025-04-24 00:23 -0400
          Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board Paul <nospam@needed.invalid> - 2025-04-24 03:52 -0400
          Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board bad sector <forgetski@_INVALID.net> - 2025-04-25 08:33 -0400
            Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board Paul <nospam@needed.invalid> - 2025-04-25 12:42 -0400
              Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board bad sector <forgetski@_INVALID.net> - 2025-04-25 23:01 -0400
              Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board bad sector <forgetski@_INVALID.net> - 2025-04-27 08:43 -0400
                Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board Paul <nospam@needed.invalid> - 2025-04-27 11:20 -0400
    Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 04:27 +0000
      Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board Paul <nospam@needed.invalid> - 2025-04-14 03:29 -0400
      Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board bad sector <forgetski@_INVALID.net> - 2025-04-14 06:03 -0400
        Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board Paul <nospam@needed.invalid> - 2025-04-14 08:16 -0400
          Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-04-14 23:38 +0000
          Re: migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board bad sector <forgetski@_INVALID.net> - 2025-04-14 20:44 -0400

#81360 — migrate triple-booting legacy-BIOS Linux-w7-w10 to EFI board

Recovering data from my suddenly departed son's computer was a job and a 
half, but it's mostly done. He had a huge server tower and I think he 
was amusing himself with RAID (which he didn't need) and encryption 
(which he didn't need) and so on!

Drives:

#1
500gb ssd with strange partitions for Linux and I think some created for 
future Linux OSes, could't figure out his /home partition setup, 
possibly raid.

#2
1tb ssd hosting fat and ext4 data PLUS a w7 and a w10 partition

#3
4tb data


#4,5,6 in a Linux-Raid array, all data

I copied out the #4 data set, cleared those drives, and released the 
tower to the executors for liquidation. Then I also backed up what ever 
other data I could find to other drives on hand.

Plugged the # 1,2,3 drives into my own very similar computer; couldn't 
believe it when everything just booted right up, even the two window 
installs! This gave me the idea that I can relax and take my time doing 
the rest of the recovey, filtering and disposal as time permits because 
I can now just boot my son's systems on my own computer. But it's my OLD 
computer.

_____And that's how shit hit the fan

I'm moving to a new and inevitably UEFI box, just plugging those 3 
drives in doesn't work any more, so...

I copied the #1 drive to a 1tb ssd to have more space, then did a fresh 
Linux (Tumbleweed) install to get EFI bootabilty. With that new #1 drive 
and his other drives including the #2 with windows on it also plugged-in 
I ran Yast to set up the EFI boot. I can now boot either my temporary 
facilitating Linux install OR my son's Linux (Leap-15.4) on the new 
EFI-BIOS board.

But I cannot boot his windows, for that I'd have to keep my old 
Legacy-BIOS box which I don't want to do (I can unload it for a few 
hundered bills).

Not knowing windows much I think I could do a w7 and a w10 fresh install 
after having done two 'windows backups' on the legacy box and then try a 
recovery from those windows-backup files on the new w7 and w10 installs 
on the EFI box. There's GOTTA be a simpler way   ..I hope.

[toc] | [next] | [standalone]

#81361

On Sat, 4/12/2025 7:50 PM, bad sector wrote:
> 
> Recovering data from my suddenly departed son's computer was a job and a half, but it's mostly done. He had a huge server tower and I think he was amusing himself with RAID (which he didn't need) and encryption (which he didn't need) and so on!
> 
> Drives:
> 
> #1
> 500gb ssd with strange partitions for Linux and I think some created for future Linux OSes, could't figure out his /home partition setup, possibly raid.
> 
> #2
> 1tb ssd hosting fat and ext4 data PLUS a w7 and a w10 partition
> 
> #3
> 4tb data
> 
> 
> #4,5,6 in a Linux-Raid array, all data
> 
> I copied out the #4 data set, cleared those drives, and released the tower to the executors for liquidation. Then I also backed up what ever other data I could find to other drives on hand.
> 
> Plugged the # 1,2,3 drives into my own very similar computer; couldn't believe it when everything just booted right up, even the two window installs! This gave me the idea that I can relax and take my time doing the rest of the recovey, filtering and disposal as time permits because I can now just boot my son's systems on my own computer. But it's my OLD computer.
> 
> _____And that's how shit hit the fan
> 
> I'm moving to a new and inevitably UEFI box, just plugging those 3 drives in doesn't work any more, so...
> 
> I copied the #1 drive to a 1tb ssd to have more space, then did a fresh Linux (Tumbleweed) install to get EFI bootabilty. With that new #1 drive and his other drives including the #2 with windows on it also plugged-in I ran Yast to set up the EFI boot. I can now boot either my temporary facilitating Linux install OR my son's Linux (Leap-15.4) on the new EFI-BIOS board.
> 
> But I cannot boot his windows, for that I'd have to keep my old Legacy-BIOS box which I don't want to do (I can unload it for a few hundered bills).
> 
> Not knowing windows much I think I could do a w7 and a w10 fresh install after having done two 'windows backups' on the legacy box and then try a recovery from those windows-backup files on the new w7 and w10 installs on the EFI box. There's GOTTA be a simpler way   ..I hope.
> 

With my Macrium CD, I can boot from the CD and back up any machine.

You would not use the "Windows 7 Backup" that comes with Windows, because
of the rough edges. Commercial backup materials have the rough edges filed off.

*******

Similar to your Tumbleweed facilitator install, you can install a Windows side-by-side
in a sense. Use Macrium to clone over or backup-restore over, the partition
from the other box. Then do a Macrium CD boot repair, and the boot repair (similar to
OSprober), it sees the orphan Windows partitions you added, and includes
them in the boot menu.

Similar to third-party "EasyBCD" on Windows, you can use this command

   bcdboot C:\Windows /s C:

to add an item to the boot menu (stored in the BCD file, BCD file
format is actually a registry file).

But, there is "much to and fro" involved. For example, somewhere along the
way, you will be holding an MSDOS Primary partition in your hand,
some other disk is GPT with GUID partition type declarations.

What commercial tools will agree to bodge those items together
to make a whole part ?

It's going to take trickery at some point.

Perhaps you make a "shell" of a partition (exact sizing important)
on the GPT disk, then "dd" copy the MSDOS partition into the
space set aside for the GPT partition. I have no idea whether
that works. I can tell you, that the equivalent of an rsync
between Windows C: type partitions, would never work, due to
all the fiddly details involved in such things. Microsoft have
gone out of their way, to ensure you can't Robocopy the entire
C: drive into another partition. I *used* to do that in WinXP era,
but those were simpler times and the file systems were a bit more
bend-able back then.

Windows has an MBR2GPT.exe utility, written by some hapless developer.
Any program carrying out composite file system operations (partition,
merge, shrink, done) is basically doomed to fail and fall on its face.
Developers normally stick to "primitive" "one step" commands, for safety.
Yet, somebody wrote that code... and it has enough smarts to reject
disk configurations it does not like. Leaving only one configuration
it does like. I think you can see coercing such a utility to do more
than it intended to do, is a tall ask. It will not accept any old
arbitrary configuration, and convert it.

So yes, your mission looks like, technically do-able, but just about
all the tools will tell you "I don't like broccoli", "I will sit
here in this corner with this cold broccoli until hell freezes over",
and so on :-) You've seen this before somewhere.

MBR2GTP.exe can help you cross that river, but it won't allow
you to carry a duck and a potato in the boat with you (a reference
to this problem, where the problem was modified for an AI to solve).
How the problem can involve a duck and a potato, I will never know.

https://en.wikipedia.org/wiki/Wolf,_goat_and_cabbage_problem

Summary: Do-able, but mostly a bar bet, like a steam powered rocket launch :-)

   Paul

[toc] | [prev] | [next] | [standalone]

#81366

On 4/12/25 20:40, Paul wrote:
> On Sat, 4/12/2025 7:50 PM, bad sector wrote:
>>
>> Recovering data from my suddenly departed son's computer was a job and a half, but it's mostly done. He had a huge server tower and I think he was amusing himself with RAID (which he didn't need) and encryption (which he didn't need) and so on!
>>
>> Drives:
>>
>> #1
>> 500gb ssd with strange partitions for Linux and I think some created for future Linux OSes, could't figure out his /home partition setup, possibly raid.
>>
>> #2
>> 1tb ssd hosting fat and ext4 data PLUS a w7 and a w10 partition
>>
>> #3
>> 4tb data
>>
>>
>> #4,5,6 in a Linux-Raid array, all data
>>
>> I copied out the #4 data set, cleared those drives, and released the tower to the executors for liquidation. Then I also backed up what ever other data I could find to other drives on hand.
>>
>> Plugged the # 1,2,3 drives into my own very similar computer; couldn't believe it when everything just booted right up, even the two window installs! This gave me the idea that I can relax and take my time doing the rest of the recovey, filtering and disposal as time permits because I can now just boot my son's systems on my own computer. But it's my OLD computer.
>>
>> _____And that's how shit hit the fan
>>
>> I'm moving to a new and inevitably UEFI box, just plugging those 3 drives in doesn't work any more, so...
>>
>> I copied the #1 drive to a 1tb ssd to have more space, then did a fresh Linux (Tumbleweed) install to get EFI bootabilty. With that new #1 drive and his other drives including the #2 with windows on it also plugged-in I ran Yast to set up the EFI boot. I can now boot either my temporary facilitating Linux install OR my son's Linux (Leap-15.4) on the new EFI-BIOS board.
>>
>> But I cannot boot his windows, for that I'd have to keep my old Legacy-BIOS box which I don't want to do (I can unload it for a few hundered bills).
>>
>> Not knowing windows much I think I could do a w7 and a w10 fresh install after having done two 'windows backups' on the legacy box and then try a recovery from those windows-backup files on the new w7 and w10 installs on the EFI box. There's GOTTA be a simpler way   ..I hope.
>>
> 
> With my Macrium CD, I can boot from the CD and back up any machine.
> 
> You would not use the "Windows 7 Backup" that comes with Windows, because
> of the rough edges. Commercial backup materials have the rough edges filed off.

I got as far as Ventoy making me a w10 usb installer, expecting to hear 
from Macrium during the week, I don't wanna pay for it unless I know 
it's gonna do the job. Or is that boot repair feature on the trial CD?





> 
> *******
> 
> Similar to your Tumbleweed facilitator install, you can install a Windows side-by-side
> in a sense. Use Macrium to clone over or backup-restore over, the partition
> from the other box. Then do a Macrium CD boot repair, and the boot repair (similar to
> OSprober), it sees the orphan Windows partitions you added, and includes
> them in the boot menu.
> 
> Similar to third-party "EasyBCD" on Windows, you can use this command
> 
>     bcdboot C:\Windows /s C:
> 
> to add an item to the boot menu (stored in the BCD file, BCD file
> format is actually a registry file).
> 
> But, there is "much to and fro" involved. For example, somewhere along the
> way, you will be holding an MSDOS Primary partition in your hand,
> some other disk is GPT with GUID partition type declarations.
> 
> What commercial tools will agree to bodge those items together
> to make a whole part ?
> 
> It's going to take trickery at some point.
> 
> Perhaps you make a "shell" of a partition (exact sizing important)
> on the GPT disk, then "dd" copy the MSDOS partition into the
> space set aside for the GPT partition. I have no idea whether
> that works. I can tell you, that the equivalent of an rsync
> between Windows C: type partitions, would never work, due to
> all the fiddly details involved in such things. Microsoft have
> gone out of their way, to ensure you can't Robocopy the entire
> C: drive into another partition. I *used* to do that in WinXP era,
> but those were simpler times and the file systems were a bit more
> bend-able back then.
> 
> Windows has an MBR2GPT.exe utility, written by some hapless developer.
> Any program carrying out composite file system operations (partition,
> merge, shrink, done) is basically doomed to fail and fall on its face.
> Developers normally stick to "primitive" "one step" commands, for safety.
> Yet, somebody wrote that code... and it has enough smarts to reject
> disk configurations it does not like. Leaving only one configuration
> it does like. I think you can see coercing such a utility to do more
> than it intended to do, is a tall ask. It will not accept any old
> arbitrary configuration, and convert it.
> 
> So yes, your mission looks like, technically do-able, but just about
> all the tools will tell you "I don't like broccoli", "I will sit
> here in this corner with this cold broccoli until hell freezes over",
> and so on :-) You've seen this before somewhere.
> 
> MBR2GTP.exe can help you cross that river, but it won't allow
> you to carry a duck and a potato in the boat with you (a reference
> to this problem, where the problem was modified for an AI to solve).
> How the problem can involve a duck and a potato, I will never know.
> 
> https://en.wikipedia.org/wiki/Wolf,_goat_and_cabbage_problem
> 
> Summary: Do-able, but mostly a bar bet, like a steam powered rocket launch :-)
> 
>     Paul
> 

[toc] | [prev] | [next] | [standalone]

#81434

On 4/12/25 20:40, Paul wrote:
> On Sat, 4/12/2025 7:50 PM, bad sector wrote:
>>
>> Recovering data from my suddenly departed son's computer was a job and a half, but it's mostly done. He had a huge server tower and I think he was amusing himself with RAID (which he didn't need) and encryption (which he didn't need) and so on!
>>
>> Drives:
>>
>> #1
>> 500gb ssd with strange partitions for Linux and I think some created for future Linux OSes, could't figure out his /home partition setup, possibly raid.
>>
>> #2
>> 1tb ssd hosting fat and ext4 data PLUS a w7 and a w10 partition
>>
>> #3
>> 4tb data
>>
>>
>> #4,5,6 in a Linux-Raid array, all data
>>
>> I copied out the #4 data set, cleared those drives, and released the tower to the executors for liquidation. Then I also backed up what ever other data I could find to other drives on hand.
>>
>> Plugged the # 1,2,3 drives into my own very similar computer; couldn't believe it when everything just booted right up, even the two window installs! This gave me the idea that I can relax and take my time doing the rest of the recovey, filtering and disposal as time permits because I can now just boot my son's systems on my own computer. But it's my OLD computer.
>>
>> _____And that's how shit hit the fan
>>
>> I'm moving to a new and inevitably UEFI box, just plugging those 3 drives in doesn't work any more, so...
>>
>> I copied the #1 drive to a 1tb ssd to have more space, then did a fresh Linux (Tumbleweed) install to get EFI bootabilty. With that new #1 drive and his other drives including the #2 with windows on it also plugged-in I ran Yast to set up the EFI boot. I can now boot either my temporary facilitating Linux install OR my son's Linux (Leap-15.4) on the new EFI-BIOS board.
>>
>> But I cannot boot his windows, for that I'd have to keep my old Legacy-BIOS box which I don't want to do (I can unload it for a few hundered bills).
>>
>> Not knowing windows much I think I could do a w7 and a w10 fresh install after having done two 'windows backups' on the legacy box and then try a recovery from those windows-backup files on the new w7 and w10 installs on the EFI box. There's GOTTA be a simpler way   ..I hope.
>>
> 
> With my Macrium CD, I can boot from the CD and back up any machine.
> 
> You would not use the "Windows 7 Backup" that comes with Windows, because
> of the rough edges. Commercial backup materials have the rough edges filed off.
> 
> *******
> 
> Similar to your Tumbleweed facilitator install, you can install a Windows side-by-side
> in a sense. Use Macrium to clone over or backup-restore over, the partition
> from the other box. Then do a Macrium CD boot repair, and the boot repair (similar to
> OSprober), it sees the orphan Windows partitions you added, and includes
> them in the boot menu.
> 
> Similar to third-party "EasyBCD" on Windows, you can use this command
> 
>     bcdboot C:\Windows /s C:
> 
> to add an item to the boot menu (stored in the BCD file, BCD file
> format is actually a registry file).
> 
> But, there is "much to and fro" involved. For example, somewhere along the
> way, you will be holding an MSDOS Primary partition in your hand,
> some other disk is GPT with GUID partition type declarations.
> 
> What commercial tools will agree to bodge those items together
> to make a whole part ?
> 
> It's going to take trickery at some point.
> 
> Perhaps you make a "shell" of a partition (exact sizing important)
> on the GPT disk, then "dd" copy the MSDOS partition into the
> space set aside for the GPT partition. I have no idea whether
> that works. I can tell you, that the equivalent of an rsync
> between Windows C: type partitions, would never work, due to
> all the fiddly details involved in such things. Microsoft have
> gone out of their way, to ensure you can't Robocopy the entire
> C: drive into another partition. I *used* to do that in WinXP era,
> but those were simpler times and the file systems were a bit more
> bend-able back then.
> 
> Windows has an MBR2GPT.exe utility, written by some hapless developer.
> Any program carrying out composite file system operations (partition,
> merge, shrink, done) is basically doomed to fail and fall on its face.
> Developers normally stick to "primitive" "one step" commands, for safety.
> Yet, somebody wrote that code... and it has enough smarts to reject
> disk configurations it does not like. Leaving only one configuration
> it does like. I think you can see coercing such a utility to do more
> than it intended to do, is a tall ask. It will not accept any old
> arbitrary configuration, and convert it.
> 
> So yes, your mission looks like, technically do-able, but just about
> all the tools will tell you "I don't like broccoli", "I will sit
> here in this corner with this cold broccoli until hell freezes over",
> and so on :-) You've seen this before somewhere.
> 
> MBR2GTP.exe can help you cross that river, but it won't allow
> you to carry a duck and a potato in the boat with you (a reference
> to this problem, where the problem was modified for an AI to solve).
> How the problem can involve a duck and a potato, I will never know.
> 
> https://en.wikipedia.org/wiki/Wolf,_goat_and_cabbage_problem
> 
> Summary: Do-able, but mostly a bar bet, like a steam powered rocket launch :-)
> 
>     Paul
> 

So far it's been one huge exercise in futility beginning with my own 
impatiance. I had gone to great lengths to recover what bare data I 
could onto even duplicate data disks, I even made duplicates of the 3 
ssd's that continued to perform *flawlessly* on my own older Crosshair 
legacy board. BEFORE I first tried the windows DOS disk I should have 
seen the red flag 'WHY did my son keep that one disk DOS when ALL the 
othes were GPT'?  But in my haste I didn't. I should also have dd'd 
mirror image FILES of the win-10 partition!

So when I first tried the windows (10) disk in my EFI box maybe I didn't 
even have it in compatibility mode (or maybe I did, can't remember), it 
failed to boot and THAT's when I lost the plot completely thinking 'well 
maybe something's wrong with my clone of the disk' and OTHERWISE 
unsuspectingly I just swapped it for the (only) original one. In those 
few seconds win-10 on both got trashed (I suspect by the w10 installer 
but don't really know).

If I knew what got changed I could maybe try to fix it before beginning 
all over but as it is I don't even have a working legacy BIOS departure 
point any more :-(

BTW, having made several w10 freshies, I found the USB installers made 
with the WoeUSB linux utility fairly good AND persistent. The one made 
by the MS uti (on my laptop 'for another computer' which is my only 
windows also box) never worked at all, and the ones made with Ventoy got 
invariably destroyed for each 2nd attempt (see prompt blowup in image).

https://imgur.com/59mcvHC

[toc] | [prev] | [next] | [standalone]

#81435

On Tue, 4/22/2025 4:40 PM, bad sector wrote:
> On 4/12/25 20:40, Paul wrote:
>> On Sat, 4/12/2025 7:50 PM, bad sector wrote:
>>>
>>> Recovering data from my suddenly departed son's computer was a job and a half, but it's mostly done. He had a huge server tower and I think he was amusing himself with RAID (which he didn't need) and encryption (which he didn't need) and so on!
>>>
>>> Drives:
>>>
>>> #1
>>> 500gb ssd with strange partitions for Linux and I think some created for future Linux OSes, could't figure out his /home partition setup, possibly raid.
>>>
>>> #2
>>> 1tb ssd hosting fat and ext4 data PLUS a w7 and a w10 partition
>>>
>>> #3
>>> 4tb data
>>>
>>>
>>> #4,5,6 in a Linux-Raid array, all data
>>>
>>> I copied out the #4 data set, cleared those drives, and released the tower to the executors for liquidation. Then I also backed up what ever other data I could find to other drives on hand.
>>>
>>> Plugged the # 1,2,3 drives into my own very similar computer; couldn't believe it when everything just booted right up, even the two window installs! This gave me the idea that I can relax and take my time doing the rest of the recovey, filtering and disposal as time permits because I can now just boot my son's systems on my own computer. But it's my OLD computer.
>>>
>>> _____And that's how shit hit the fan
>>>
>>> I'm moving to a new and inevitably UEFI box, just plugging those 3 drives in doesn't work any more, so...
>>>
>>> I copied the #1 drive to a 1tb ssd to have more space, then did a fresh Linux (Tumbleweed) install to get EFI bootabilty. With that new #1 drive and his other drives including the #2 with windows on it also plugged-in I ran Yast to set up the EFI boot. I can now boot either my temporary facilitating Linux install OR my son's Linux (Leap-15.4) on the new EFI-BIOS board.
>>>
>>> But I cannot boot his windows, for that I'd have to keep my old Legacy-BIOS box which I don't want to do (I can unload it for a few hundered bills).
>>>
>>> Not knowing windows much I think I could do a w7 and a w10 fresh install after having done two 'windows backups' on the legacy box and then try a recovery from those windows-backup files on the new w7 and w10 installs on the EFI box. There's GOTTA be a simpler way   ..I hope.
>>>
>>
>> With my Macrium CD, I can boot from the CD and back up any machine.
>>
>> You would not use the "Windows 7 Backup" that comes with Windows, because
>> of the rough edges. Commercial backup materials have the rough edges filed off.
>>
>> *******
>>
>> Similar to your Tumbleweed facilitator install, you can install a Windows side-by-side
>> in a sense. Use Macrium to clone over or backup-restore over, the partition
>> from the other box. Then do a Macrium CD boot repair, and the boot repair (similar to
>> OSprober), it sees the orphan Windows partitions you added, and includes
>> them in the boot menu.
>>
>> Similar to third-party "EasyBCD" on Windows, you can use this command
>>
>>     bcdboot C:\Windows /s C:
>>
>> to add an item to the boot menu (stored in the BCD file, BCD file
>> format is actually a registry file).
>>
>> But, there is "much to and fro" involved. For example, somewhere along the
>> way, you will be holding an MSDOS Primary partition in your hand,
>> some other disk is GPT with GUID partition type declarations.
>>
>> What commercial tools will agree to bodge those items together
>> to make a whole part ?
>>
>> It's going to take trickery at some point.
>>
>> Perhaps you make a "shell" of a partition (exact sizing important)
>> on the GPT disk, then "dd" copy the MSDOS partition into the
>> space set aside for the GPT partition. I have no idea whether
>> that works. I can tell you, that the equivalent of an rsync
>> between Windows C: type partitions, would never work, due to
>> all the fiddly details involved in such things. Microsoft have
>> gone out of their way, to ensure you can't Robocopy the entire
>> C: drive into another partition. I *used* to do that in WinXP era,
>> but those were simpler times and the file systems were a bit more
>> bend-able back then.
>>
>> Windows has an MBR2GPT.exe utility, written by some hapless developer.
>> Any program carrying out composite file system operations (partition,
>> merge, shrink, done) is basically doomed to fail and fall on its face.
>> Developers normally stick to "primitive" "one step" commands, for safety.
>> Yet, somebody wrote that code... and it has enough smarts to reject
>> disk configurations it does not like. Leaving only one configuration
>> it does like. I think you can see coercing such a utility to do more
>> than it intended to do, is a tall ask. It will not accept any old
>> arbitrary configuration, and convert it.
>>
>> So yes, your mission looks like, technically do-able, but just about
>> all the tools will tell you "I don't like broccoli", "I will sit
>> here in this corner with this cold broccoli until hell freezes over",
>> and so on :-) You've seen this before somewhere.
>>
>> MBR2GTP.exe can help you cross that river, but it won't allow
>> you to carry a duck and a potato in the boat with you (a reference
>> to this problem, where the problem was modified for an AI to solve).
>> How the problem can involve a duck and a potato, I will never know.
>>
>> https://en.wikipedia.org/wiki/Wolf,_goat_and_cabbage_problem
>>
>> Summary: Do-able, but mostly a bar bet, like a steam powered rocket launch :-)
>>
>>     Paul
>>
> 
> So far it's been one huge exercise in futility beginning with my own impatiance. I had gone to great lengths to recover what bare data I could onto even duplicate data disks, I even made duplicates of the 3 ssd's that continued to perform *flawlessly* on my own older Crosshair legacy board. BEFORE I first tried the windows DOS disk I should have seen the red flag 'WHY did my son keep that one disk DOS when ALL the othes were GPT'?  But in my haste I didn't. I should also have dd'd mirror image FILES of the win-10 partition!
> 
> So when I first tried the windows (10) disk in my EFI box maybe I didn't even have it in compatibility mode (or maybe I did, can't remember), it failed to boot and THAT's when I lost the plot completely thinking 'well maybe something's wrong with my clone of the disk' and OTHERWISE unsuspectingly I just swapped it for the (only) original one. In those few seconds win-10 on both got trashed (I suspect by the w10 installer but don't really know).
> 
> If I knew what got changed I could maybe try to fix it before beginning all over but as it is I don't even have a working legacy BIOS departure point any more :-(
> 
> BTW, having made several w10 freshies, I found the USB installers made with the WoeUSB linux utility fairly good AND persistent. The one made by the MS uti (on my laptop 'for another computer' which is my only windows also box) never worked at all, and the ones made with Ventoy got invariably destroyed for each 2nd attempt (see prompt blowup in image).
> 
> https://imgur.com/59mcvHC
> 
> 

The boot menu is in a file called "BCD". The internal format is "registry file"
but that never comes up when using tools to work on it. I mention that in case
your hex editor examination shows "binary" and you are wondering why it is binary
inside. They used a registry format, as a storage format for small objects.

It takes somewhere on the order of four specific commands, to make a brand new
BCD file appear before your eyes. But because there are other files that
are typically nearby, we don't usually "start from scratch" all that often.

Instead, we're looking for the directory where that is located, and
doing something to augment the file.

    bcdedit                        # Dump the BCD file that the system booted with (good when OS is working)

    bcdedit /store C:\boot\BCD     # Dump the BCD file from selected location (while using install DVD to do maintenance)

Here are two pictures showing the Legacy and UEFI boot devices I have on the other machine.
I'm showing these pictures, as the partition structure is a bit less noisy.

   [Picture]

    https://i.postimg.cc/7L4JqvX0/legacy-boot-example.gif

   [Picture]

    https://i.postimg.cc/zGZVkms6/UEFI-boot-example.gif

As an example of a "thing" you would do with bcdedit while
the OS is running, these kinds of commands set the OS description
in the on-screen boot menu, early in boot. The "identifier",
can be spotted when you use the "bcdedit" command without parameters.
and the "identifier" is context sensitive. It may appear with
a different value when you are booted using a Windows installer DVD
and the Troubleshooting Command Prompt window.

bcdedit /set {current} description "Windows 10"
bcdedit /set {default} description "Windows 10"

If I was booted from the DVD, I would do them similar to this. The boot DVD, X: is the system partition.
Leaving C: available as a letter for this sort of repair activity. Notice when I am using the DVD
like this, I have to "know my stuff" to target the correct BCD file.

bcdedit /store C:\boot\BCD   /set {current} description "Windows 10"
bcdedit /store C:\boot\BCD   /set {default} description "Windows 10"

*******

General rules of thumb (you know these already):

1) Since "usually", the dependencies of an OS are on a single disk drive,
   it makes the most sense to have boot material for it, right on that same drive.
   This allows BIOS steering to the drive, if and when needed, for emergencies.

2) You are certainly allowed to have a boot manager on disk 1, and jump over
   to disk 2, using GUIDs or UUID or identifiers of that sort. But you also
   want whatever OSes on disk 1, to be bootable from the disk 1 boot materials.

3) This means, the BIOS could point at disk 1 for "machine-wide" boot, or
   the BIOS could point to disk 2 for "disk 2 specific boot". There can be
   a boot menu on disk 1 and disk 2. The only time this gets confusing,
   is when you do "sudo update-grub", and there could be the odd surprise
   depending on the configuration.

If I was in the room, the Windows disk with the boot problem, first
we'd have to figure out whether the recommended rules were followed
("only have the disk receiving an install, connected during the install").
If that was the case, then repairing the boot-ability, could again
be performed on the single disk.

You will notice in my picture, I used "diskmgmt.msc" to display the
disk setup in Windows. And the labels hint where key materials have gone.
If "System", "Boot", and optionally "Active" are smeared over the two
disks, this presents some challenges, and you have to decide what
you want to do as a Wizard. You can move some of the materials around.
I've done that a couple times, when something was in an awful mess.
The purpose of moving the items, would be to try to get all those
key identifiers lit up on the one disk.

I can't go much further than that, as with a non-booting system, even if
we cable up the two forensic project disks to a third Windows system disk.
the booted Windows will only show its own identifiers and not where
everything is smeared on the other two disks. It's going to be
a challenge to figure this out. By dumping the BCD file, there could
be hints where the BCD is pointing. But again, no guarantees. It's all
a bit of a puzzle at times, that's for sure.

*******

Preparing Macrium Reflect "Rescue CD", starts with the installer.
I need some odds and ends to do a demo, so I'll try to post later.
If your maintenance OS was 64-bit, you could use the 64-bit one.
The reason for using the 32-bit one, is when booted from that,
a small number of GUI-oriented win32 programs will run under that
environment, which can be useful at forensics time.

   https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x64.exe

   Name: reflect_setup_free_x64.exe
   Size: 115,719,576 bytes (110 MiB)
   SHA1: B6724C7B6F5AF146406FAAA78F845A6C281D67D8

   There is also a 32-bit one. For 32-bit setups.

   https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x86.exe

   Paul

[toc] | [prev] | [next] | [standalone]

#81436

On 4/23/25 09:38, Paul wrote:
> On Tue, 4/22/2025 4:40 PM, bad sector wrote:
>> On 4/12/25 20:40, Paul wrote:
>>> On Sat, 4/12/2025 7:50 PM, bad sector wrote:
>>>>
>>>> Recovering data from my suddenly departed son's computer was a job and a half, but it's mostly done. He had a huge server tower and I think he was amusing himself with RAID (which he didn't need) and encryption (which he didn't need) and so on!
>>>>
>>>> Drives:
>>>>
>>>> #1
>>>> 500gb ssd with strange partitions for Linux and I think some created for future Linux OSes, could't figure out his /home partition setup, possibly raid.
>>>>
>>>> #2
>>>> 1tb ssd hosting fat and ext4 data PLUS a w7 and a w10 partition
>>>>
>>>> #3
>>>> 4tb data
>>>>
>>>>
>>>> #4,5,6 in a Linux-Raid array, all data
>>>>
>>>> I copied out the #4 data set, cleared those drives, and released the tower to the executors for liquidation. Then I also backed up what ever other data I could find to other drives on hand.
>>>>
>>>> Plugged the # 1,2,3 drives into my own very similar computer; couldn't believe it when everything just booted right up, even the two window installs! This gave me the idea that I can relax and take my time doing the rest of the recovey, filtering and disposal as time permits because I can now just boot my son's systems on my own computer. But it's my OLD computer.
>>>>
>>>> _____And that's how shit hit the fan
>>>>
>>>> I'm moving to a new and inevitably UEFI box, just plugging those 3 drives in doesn't work any more, so...
>>>>
>>>> I copied the #1 drive to a 1tb ssd to have more space, then did a fresh Linux (Tumbleweed) install to get EFI bootabilty. With that new #1 drive and his other drives including the #2 with windows on it also plugged-in I ran Yast to set up the EFI boot. I can now boot either my temporary facilitating Linux install OR my son's Linux (Leap-15.4) on the new EFI-BIOS board.
>>>>
>>>> But I cannot boot his windows, for that I'd have to keep my old Legacy-BIOS box which I don't want to do (I can unload it for a few hundered bills).
>>>>
>>>> Not knowing windows much I think I could do a w7 and a w10 fresh install after having done two 'windows backups' on the legacy box and then try a recovery from those windows-backup files on the new w7 and w10 installs on the EFI box. There's GOTTA be a simpler way   ..I hope.
>>>>
>>>
>>> With my Macrium CD, I can boot from the CD and back up any machine.
>>>
>>> You would not use the "Windows 7 Backup" that comes with Windows, because
>>> of the rough edges. Commercial backup materials have the rough edges filed off.
>>>
>>> *******
>>>
>>> Similar to your Tumbleweed facilitator install, you can install a Windows side-by-side
>>> in a sense. Use Macrium to clone over or backup-restore over, the partition
>>> from the other box. Then do a Macrium CD boot repair, and the boot repair (similar to
>>> OSprober), it sees the orphan Windows partitions you added, and includes
>>> them in the boot menu.
>>>
>>> Similar to third-party "EasyBCD" on Windows, you can use this command
>>>
>>>      bcdboot C:\Windows /s C:
>>>
>>> to add an item to the boot menu (stored in the BCD file, BCD file
>>> format is actually a registry file).
>>>
>>> But, there is "much to and fro" involved. For example, somewhere along the
>>> way, you will be holding an MSDOS Primary partition in your hand,
>>> some other disk is GPT with GUID partition type declarations.
>>>
>>> What commercial tools will agree to bodge those items together
>>> to make a whole part ?
>>>
>>> It's going to take trickery at some point.
>>>
>>> Perhaps you make a "shell" of a partition (exact sizing important)
>>> on the GPT disk, then "dd" copy the MSDOS partition into the
>>> space set aside for the GPT partition. I have no idea whether
>>> that works. I can tell you, that the equivalent of an rsync
>>> between Windows C: type partitions, would never work, due to
>>> all the fiddly details involved in such things. Microsoft have
>>> gone out of their way, to ensure you can't Robocopy the entire
>>> C: drive into another partition. I *used* to do that in WinXP era,
>>> but those were simpler times and the file systems were a bit more
>>> bend-able back then.
>>>
>>> Windows has an MBR2GPT.exe utility, written by some hapless developer.
>>> Any program carrying out composite file system operations (partition,
>>> merge, shrink, done) is basically doomed to fail and fall on its face.
>>> Developers normally stick to "primitive" "one step" commands, for safety.
>>> Yet, somebody wrote that code... and it has enough smarts to reject
>>> disk configurations it does not like. Leaving only one configuration
>>> it does like. I think you can see coercing such a utility to do more
>>> than it intended to do, is a tall ask. It will not accept any old
>>> arbitrary configuration, and convert it.
>>>
>>> So yes, your mission looks like, technically do-able, but just about
>>> all the tools will tell you "I don't like broccoli", "I will sit
>>> here in this corner with this cold broccoli until hell freezes over",
>>> and so on :-) You've seen this before somewhere.
>>>
>>> MBR2GTP.exe can help you cross that river, but it won't allow
>>> you to carry a duck and a potato in the boat with you (a reference
>>> to this problem, where the problem was modified for an AI to solve).
>>> How the problem can involve a duck and a potato, I will never know.
>>>
>>> https://en.wikipedia.org/wiki/Wolf,_goat_and_cabbage_problem
>>>
>>> Summary: Do-able, but mostly a bar bet, like a steam powered rocket launch :-)
>>>
>>>      Paul
>>>
>>
>> So far it's been one huge exercise in futility beginning with my own impatiance. I had gone to great lengths to recover what bare data I could onto even duplicate data disks, I even made duplicates of the 3 ssd's that continued to perform *flawlessly* on my own older Crosshair legacy board. BEFORE I first tried the windows DOS disk I should have seen the red flag 'WHY did my son keep that one disk DOS when ALL the othes were GPT'?  But in my haste I didn't. I should also have dd'd mirror image FILES of the win-10 partition!
>>
>> So when I first tried the windows (10) disk in my EFI box maybe I didn't even have it in compatibility mode (or maybe I did, can't remember), it failed to boot and THAT's when I lost the plot completely thinking 'well maybe something's wrong with my clone of the disk' and OTHERWISE unsuspectingly I just swapped it for the (only) original one. In those few seconds win-10 on both got trashed (I suspect by the w10 installer but don't really know).
>>
>> If I knew what got changed I could maybe try to fix it before beginning all over but as it is I don't even have a working legacy BIOS departure point any more :-(
>>
>> BTW, having made several w10 freshies, I found the USB installers made with the WoeUSB linux utility fairly good AND persistent. The one made by the MS uti (on my laptop 'for another computer' which is my only windows also box) never worked at all, and the ones made with Ventoy got invariably destroyed for each 2nd attempt (see prompt blowup in image).
>>
>> https://imgur.com/59mcvHC
>>
>>
> 
> The boot menu is in a file called "BCD". The internal format is "registry file"
> but that never comes up when using tools to work on it. I mention that in case
> your hex editor examination shows "binary" and you are wondering why it is binary
> inside. They used a registry format, as a storage format for small objects.
> 
> It takes somewhere on the order of four specific commands, to make a brand new
> BCD file appear before your eyes. But because there are other files that
> are typically nearby, we don't usually "start from scratch" all that often.
> 
> Instead, we're looking for the directory where that is located, and
> doing something to augment the file.
> 
>      bcdedit                        # Dump the BCD file that the system booted with (good when OS is working)
> 
>      bcdedit /store C:\boot\BCD     # Dump the BCD file from selected location (while using install DVD to do maintenance)
> 
> Here are two pictures showing the Legacy and UEFI boot devices I have on the other machine.
> I'm showing these pictures, as the partition structure is a bit less noisy.
> 
>     [Picture]
> 
>      https://i.postimg.cc/7L4JqvX0/legacy-boot-example.gif
> 
>     [Picture]
> 
>      https://i.postimg.cc/zGZVkms6/UEFI-boot-example.gif
> 
> As an example of a "thing" you would do with bcdedit while
> the OS is running, these kinds of commands set the OS description
> in the on-screen boot menu, early in boot. The "identifier",
> can be spotted when you use the "bcdedit" command without parameters.
> and the "identifier" is context sensitive. It may appear with
> a different value when you are booted using a Windows installer DVD
> and the Troubleshooting Command Prompt window.
> 
> bcdedit /set {current} description "Windows 10"
> bcdedit /set {default} description "Windows 10"
> 
> If I was booted from the DVD, I would do them similar to this. The boot DVD, X: is the system partition.
> Leaving C: available as a letter for this sort of repair activity. Notice when I am using the DVD
> like this, I have to "know my stuff" to target the correct BCD file.
> 
> bcdedit /store C:\boot\BCD   /set {current} description "Windows 10"
> bcdedit /store C:\boot\BCD   /set {default} description "Windows 10"
> 
> *******
> 
> General rules of thumb (you know these already):
> 
> 1) Since "usually", the dependencies of an OS are on a single disk drive,
>     it makes the most sense to have boot material for it, right on that same drive.
>     This allows BIOS steering to the drive, if and when needed, for emergencies.
> 
> 2) You are certainly allowed to have a boot manager on disk 1, and jump over
>     to disk 2, using GUIDs or UUID or identifiers of that sort. But you also
>     want whatever OSes on disk 1, to be bootable from the disk 1 boot materials.
> 
> 3) This means, the BIOS could point at disk 1 for "machine-wide" boot, or
>     the BIOS could point to disk 2 for "disk 2 specific boot". There can be
>     a boot menu on disk 1 and disk 2. The only time this gets confusing,
>     is when you do "sudo update-grub", and there could be the odd surprise
>     depending on the configuration.
> 
> If I was in the room, the Windows disk with the boot problem, first
> we'd have to figure out whether the recommended rules were followed
> ("only have the disk receiving an install, connected during the install").
> If that was the case, then repairing the boot-ability, could again
> be performed on the single disk.
> 
> You will notice in my picture, I used "diskmgmt.msc" to display the
> disk setup in Windows. And the labels hint where key materials have gone.
> If "System", "Boot", and optionally "Active" are smeared over the two
> disks, this presents some challenges, and you have to decide what
> you want to do as a Wizard. You can move some of the materials around.
> I've done that a couple times, when something was in an awful mess.
> The purpose of moving the items, would be to try to get all those
> key identifiers lit up on the one disk.
> 
> I can't go much further than that, as with a non-booting system, even if
> we cable up the two forensic project disks to a third Windows system disk.
> the booted Windows will only show its own identifiers and not where
> everything is smeared on the other two disks. It's going to be
> a challenge to figure this out. By dumping the BCD file, there could
> be hints where the BCD is pointing. But again, no guarantees. It's all
> a bit of a puzzle at times, that's for sure.
> 
> *******
> 
> Preparing Macrium Reflect "Rescue CD", starts with the installer.
> I need some odds and ends to do a demo, so I'll try to post later.
> If your maintenance OS was 64-bit, you could use the 64-bit one.
> The reason for using the 32-bit one, is when booted from that,
> a small number of GUI-oriented win32 programs will run under that
> environment, which can be useful at forensics time.
> 
>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x64.exe
> 
>     Name: reflect_setup_free_x64.exe
>     Size: 115,719,576 bytes (110 MiB)
>     SHA1: B6724C7B6F5AF146406FAAA78F845A6C281D67D8
> 
>     There is also a 32-bit one. For 32-bit setups.
> 
>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x86.exe
> 
>     Paul
Thanks a meg as usual! It's late here and I'm totaled, will reread all 
this tomorrow evening. Meanwhile I thought I should just mention that I 
have deleted all the changes made, both the Linux and w10 'facilitating' 
installations, from the new copy of disk-1. I'm back with two copies 
each of the 3 disks with the only difference that w10 don't boot any 
more. I can and will if useful augment the copy of the (normally) 
booting disk-1 WITH the Linux and w10 freshies as I did before.

[toc] | [prev] | [next] | [standalone]

#81439

On Wed, 4/23/2025 9:38 AM, Paul wrote:
> On Tue, 4/22/2025 4:40 PM, bad sector wrote:
>> On 4/12/25 20:40, Paul wrote:
>>> On Sat, 4/12/2025 7:50 PM, bad sector wrote:
>>>>
>>>> Recovering data from my suddenly departed son's computer was a job and a half, but it's mostly done. He had a huge server tower and I think he was amusing himself with RAID (which he didn't need) and encryption (which he didn't need) and so on!
>>>>
>>>> Drives:
>>>>
>>>> #1
>>>> 500gb ssd with strange partitions for Linux and I think some created for future Linux OSes, could't figure out his /home partition setup, possibly raid.
>>>>
>>>> #2
>>>> 1tb ssd hosting fat and ext4 data PLUS a w7 and a w10 partition
>>>>
>>>> #3
>>>> 4tb data
>>>>
>>>>
>>>> #4,5,6 in a Linux-Raid array, all data
>>>>
>>>> I copied out the #4 data set, cleared those drives, and released the tower to the executors for liquidation. Then I also backed up what ever other data I could find to other drives on hand.
>>>>
>>>> Plugged the # 1,2,3 drives into my own very similar computer; couldn't believe it when everything just booted right up, even the two window installs! This gave me the idea that I can relax and take my time doing the rest of the recovey, filtering and disposal as time permits because I can now just boot my son's systems on my own computer. But it's my OLD computer.
>>>>
>>>> _____And that's how shit hit the fan
>>>>
>>>> I'm moving to a new and inevitably UEFI box, just plugging those 3 drives in doesn't work any more, so...
>>>>
>>>> I copied the #1 drive to a 1tb ssd to have more space, then did a fresh Linux (Tumbleweed) install to get EFI bootabilty. With that new #1 drive and his other drives including the #2 with windows on it also plugged-in I ran Yast to set up the EFI boot. I can now boot either my temporary facilitating Linux install OR my son's Linux (Leap-15.4) on the new EFI-BIOS board.
>>>>
>>>> But I cannot boot his windows, for that I'd have to keep my old Legacy-BIOS box which I don't want to do (I can unload it for a few hundered bills).
>>>>
>>>> Not knowing windows much I think I could do a w7 and a w10 fresh install after having done two 'windows backups' on the legacy box and then try a recovery from those windows-backup files on the new w7 and w10 installs on the EFI box. There's GOTTA be a simpler way   ..I hope.
>>>>
>>>
>>> With my Macrium CD, I can boot from the CD and back up any machine.
>>>
>>> You would not use the "Windows 7 Backup" that comes with Windows, because
>>> of the rough edges. Commercial backup materials have the rough edges filed off.
>>>
>>> *******
>>>
>>> Similar to your Tumbleweed facilitator install, you can install a Windows side-by-side
>>> in a sense. Use Macrium to clone over or backup-restore over, the partition
>>> from the other box. Then do a Macrium CD boot repair, and the boot repair (similar to
>>> OSprober), it sees the orphan Windows partitions you added, and includes
>>> them in the boot menu.
>>>
>>> Similar to third-party "EasyBCD" on Windows, you can use this command
>>>
>>>     bcdboot C:\Windows /s C:
>>>
>>> to add an item to the boot menu (stored in the BCD file, BCD file
>>> format is actually a registry file).
>>>
>>> But, there is "much to and fro" involved. For example, somewhere along the
>>> way, you will be holding an MSDOS Primary partition in your hand,
>>> some other disk is GPT with GUID partition type declarations.
>>>
>>> What commercial tools will agree to bodge those items together
>>> to make a whole part ?
>>>
>>> It's going to take trickery at some point.
>>>
>>> Perhaps you make a "shell" of a partition (exact sizing important)
>>> on the GPT disk, then "dd" copy the MSDOS partition into the
>>> space set aside for the GPT partition. I have no idea whether
>>> that works. I can tell you, that the equivalent of an rsync
>>> between Windows C: type partitions, would never work, due to
>>> all the fiddly details involved in such things. Microsoft have
>>> gone out of their way, to ensure you can't Robocopy the entire
>>> C: drive into another partition. I *used* to do that in WinXP era,
>>> but those were simpler times and the file systems were a bit more
>>> bend-able back then.
>>>
>>> Windows has an MBR2GPT.exe utility, written by some hapless developer.
>>> Any program carrying out composite file system operations (partition,
>>> merge, shrink, done) is basically doomed to fail and fall on its face.
>>> Developers normally stick to "primitive" "one step" commands, for safety.
>>> Yet, somebody wrote that code... and it has enough smarts to reject
>>> disk configurations it does not like. Leaving only one configuration
>>> it does like. I think you can see coercing such a utility to do more
>>> than it intended to do, is a tall ask. It will not accept any old
>>> arbitrary configuration, and convert it.
>>>
>>> So yes, your mission looks like, technically do-able, but just about
>>> all the tools will tell you "I don't like broccoli", "I will sit
>>> here in this corner with this cold broccoli until hell freezes over",
>>> and so on :-) You've seen this before somewhere.
>>>
>>> MBR2GTP.exe can help you cross that river, but it won't allow
>>> you to carry a duck and a potato in the boat with you (a reference
>>> to this problem, where the problem was modified for an AI to solve).
>>> How the problem can involve a duck and a potato, I will never know.
>>>
>>> https://en.wikipedia.org/wiki/Wolf,_goat_and_cabbage_problem
>>>
>>> Summary: Do-able, but mostly a bar bet, like a steam powered rocket launch :-)
>>>
>>>     Paul
>>>
>>
>> So far it's been one huge exercise in futility beginning with my own impatiance. I had gone to great lengths to recover what bare data I could onto even duplicate data disks, I even made duplicates of the 3 ssd's that continued to perform *flawlessly* on my own older Crosshair legacy board. BEFORE I first tried the windows DOS disk I should have seen the red flag 'WHY did my son keep that one disk DOS when ALL the othes were GPT'?  But in my haste I didn't. I should also have dd'd mirror image FILES of the win-10 partition!
>>
>> So when I first tried the windows (10) disk in my EFI box maybe I didn't even have it in compatibility mode (or maybe I did, can't remember), it failed to boot and THAT's when I lost the plot completely thinking 'well maybe something's wrong with my clone of the disk' and OTHERWISE unsuspectingly I just swapped it for the (only) original one. In those few seconds win-10 on both got trashed (I suspect by the w10 installer but don't really know).
>>
>> If I knew what got changed I could maybe try to fix it before beginning all over but as it is I don't even have a working legacy BIOS departure point any more :-(
>>
>> BTW, having made several w10 freshies, I found the USB installers made with the WoeUSB linux utility fairly good AND persistent. The one made by the MS uti (on my laptop 'for another computer' which is my only windows also box) never worked at all, and the ones made with Ventoy got invariably destroyed for each 2nd attempt (see prompt blowup in image).
>>
>> https://imgur.com/59mcvHC
>>
>>
> 
> The boot menu is in a file called "BCD". The internal format is "registry file"
> but that never comes up when using tools to work on it. I mention that in case
> your hex editor examination shows "binary" and you are wondering why it is binary
> inside. They used a registry format, as a storage format for small objects.
> 
> It takes somewhere on the order of four specific commands, to make a brand new
> BCD file appear before your eyes. But because there are other files that
> are typically nearby, we don't usually "start from scratch" all that often.
> 
> Instead, we're looking for the directory where that is located, and
> doing something to augment the file.
> 
>     bcdedit                        # Dump the BCD file that the system booted with (good when OS is working)
> 
>     bcdedit /store C:\boot\BCD     # Dump the BCD file from selected location (while using install DVD to do maintenance)
> 
> Here are two pictures showing the Legacy and UEFI boot devices I have on the other machine.
> I'm showing these pictures, as the partition structure is a bit less noisy.
> 
>    [Picture]
> 
>     https://i.postimg.cc/7L4JqvX0/legacy-boot-example.gif
> 
>    [Picture]
> 
>     https://i.postimg.cc/zGZVkms6/UEFI-boot-example.gif
> 
> As an example of a "thing" you would do with bcdedit while
> the OS is running, these kinds of commands set the OS description
> in the on-screen boot menu, early in boot. The "identifier",
> can be spotted when you use the "bcdedit" command without parameters.
> and the "identifier" is context sensitive. It may appear with
> a different value when you are booted using a Windows installer DVD
> and the Troubleshooting Command Prompt window.
> 
> bcdedit /set {current} description "Windows 10"
> bcdedit /set {default} description "Windows 10"
> 
> If I was booted from the DVD, I would do them similar to this. The boot DVD, X: is the system partition.
> Leaving C: available as a letter for this sort of repair activity. Notice when I am using the DVD
> like this, I have to "know my stuff" to target the correct BCD file.
> 
> bcdedit /store C:\boot\BCD   /set {current} description "Windows 10"
> bcdedit /store C:\boot\BCD   /set {default} description "Windows 10"
> 
> *******
> 
> General rules of thumb (you know these already):
> 
> 1) Since "usually", the dependencies of an OS are on a single disk drive,
>    it makes the most sense to have boot material for it, right on that same drive.
>    This allows BIOS steering to the drive, if and when needed, for emergencies.
> 
> 2) You are certainly allowed to have a boot manager on disk 1, and jump over
>    to disk 2, using GUIDs or UUID or identifiers of that sort. But you also
>    want whatever OSes on disk 1, to be bootable from the disk 1 boot materials.
> 
> 3) This means, the BIOS could point at disk 1 for "machine-wide" boot, or
>    the BIOS could point to disk 2 for "disk 2 specific boot". There can be
>    a boot menu on disk 1 and disk 2. The only time this gets confusing,
>    is when you do "sudo update-grub", and there could be the odd surprise
>    depending on the configuration.
> 
> If I was in the room, the Windows disk with the boot problem, first
> we'd have to figure out whether the recommended rules were followed
> ("only have the disk receiving an install, connected during the install").
> If that was the case, then repairing the boot-ability, could again
> be performed on the single disk.
> 
> You will notice in my picture, I used "diskmgmt.msc" to display the
> disk setup in Windows. And the labels hint where key materials have gone.
> If "System", "Boot", and optionally "Active" are smeared over the two
> disks, this presents some challenges, and you have to decide what
> you want to do as a Wizard. You can move some of the materials around.
> I've done that a couple times, when something was in an awful mess.
> The purpose of moving the items, would be to try to get all those
> key identifiers lit up on the one disk.
> 
> I can't go much further than that, as with a non-booting system, even if
> we cable up the two forensic project disks to a third Windows system disk.
> the booted Windows will only show its own identifiers and not where
> everything is smeared on the other two disks. It's going to be
> a challenge to figure this out. By dumping the BCD file, there could
> be hints where the BCD is pointing. But again, no guarantees. It's all
> a bit of a puzzle at times, that's for sure.
> 
> *******
> 
> Preparing Macrium Reflect "Rescue CD", starts with the installer.
> I need some odds and ends to do a demo, so I'll try to post later.
> If your maintenance OS was 64-bit, you could use the 64-bit one.
> The reason for using the 32-bit one, is when booted from that,
> a small number of GUI-oriented win32 programs will run under that
> environment, which can be useful at forensics time.
> 
>    https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x64.exe
> 
>    Name: reflect_setup_free_x64.exe
>    Size: 115,719,576 bytes (110 MiB)
>    SHA1: B6724C7B6F5AF146406FAAA78F845A6C281D67D8
> 
>    There is also a 32-bit one. For 32-bit setups.
> 
>    https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x86.exe
> 

OK, here is the artwork to go with preparing Macrium Rescue
so you can use the Boot Repair in the menu. This is one of
the "longer trips to fetch a pail of water". Since the Rescue CD
is an ISO, you can make a CD/DVD or you can make a USB stick,
depending on what fits your setup best. Not everyone has sufficient
sticks sitting around to put everything on a stick.

   [Pictures]

   https://i.postimg.cc/3RRxzNwf/Reflect7-Install.gif

   https://i.postimg.cc/63mpKK2W/Macrium-Media-Builder.gif

   https://i.postimg.cc/fLtJJkht/rufus-boot-stick.gif

You would try that with the Windows disk drive by itself,
then afterwards if things go well from the Rescue session,
try booting Windows.

It's generally always best to work with a clone, when
doing forensic quality work. I've ruined a good many
disks over the years doing this sequence, and clones
are best for it (live and learn).

In terms of boot repair, you try Macrium first, then
any Windows automation for repair comes second.

   Paul

[toc] | [prev] | [next] | [standalone]

#81445

On 4/23/25 09:38, Paul wrote:
> On Tue, 4/22/2025 4:40 PM, bad sector wrote:
>> On 4/12/25 20:40, Paul wrote:
>>> On Sat, 4/12/2025 7:50 PM, bad sector wrote:
>>>>
>>>> Recovering data from my suddenly departed son's computer was a job and a half, but it's mostly done. He had a huge server tower and I think he was amusing himself with RAID (which he didn't need) and encryption (which he didn't need) and so on!
>>>>
>>>> Drives:
>>>>
>>>> #1
>>>> 500gb ssd with strange partitions for Linux and I think some created for future Linux OSes, could't figure out his /home partition setup, possibly raid.
>>>>
>>>> #2
>>>> 1tb ssd hosting fat and ext4 data PLUS a w7 and a w10 partition
>>>>
>>>> #3
>>>> 4tb data
>>>>
>>>>
>>>> #4,5,6 in a Linux-Raid array, all data
>>>>
>>>> I copied out the #4 data set, cleared those drives, and released the tower to the executors for liquidation. Then I also backed up what ever other data I could find to other drives on hand.
>>>>
>>>> Plugged the # 1,2,3 drives into my own very similar computer; couldn't believe it when everything just booted right up, even the two window installs! This gave me the idea that I can relax and take my time doing the rest of the recovey, filtering and disposal as time permits because I can now just boot my son's systems on my own computer. But it's my OLD computer.
>>>>
>>>> _____And that's how shit hit the fan
>>>>
>>>> I'm moving to a new and inevitably UEFI box, just plugging those 3 drives in doesn't work any more, so...
>>>>
>>>> I copied the #1 drive to a 1tb ssd to have more space, then did a fresh Linux (Tumbleweed) install to get EFI bootabilty. With that new #1 drive and his other drives including the #2 with windows on it also plugged-in I ran Yast to set up the EFI boot. I can now boot either my temporary facilitating Linux install OR my son's Linux (Leap-15.4) on the new EFI-BIOS board.
>>>>
>>>> But I cannot boot his windows, for that I'd have to keep my old Legacy-BIOS box which I don't want to do (I can unload it for a few hundered bills).
>>>>
>>>> Not knowing windows much I think I could do a w7 and a w10 fresh install after having done two 'windows backups' on the legacy box and then try a recovery from those windows-backup files on the new w7 and w10 installs on the EFI box. There's GOTTA be a simpler way   ..I hope.
>>>>
>>>
>>> With my Macrium CD, I can boot from the CD and back up any machine.
>>>
>>> You would not use the "Windows 7 Backup" that comes with Windows, because
>>> of the rough edges. Commercial backup materials have the rough edges filed off.
>>>
>>> *******
>>>
>>> Similar to your Tumbleweed facilitator install, you can install a Windows side-by-side
>>> in a sense. Use Macrium to clone over or backup-restore over, the partition
>>> from the other box. Then do a Macrium CD boot repair, and the boot repair (similar to
>>> OSprober), it sees the orphan Windows partitions you added, and includes
>>> them in the boot menu.
>>>
>>> Similar to third-party "EasyBCD" on Windows, you can use this command
>>>
>>>      bcdboot C:\Windows /s C:
>>>
>>> to add an item to the boot menu (stored in the BCD file, BCD file
>>> format is actually a registry file).
>>>
>>> But, there is "much to and fro" involved. For example, somewhere along the
>>> way, you will be holding an MSDOS Primary partition in your hand,
>>> some other disk is GPT with GUID partition type declarations.
>>>
>>> What commercial tools will agree to bodge those items together
>>> to make a whole part ?
>>>
>>> It's going to take trickery at some point.
>>>
>>> Perhaps you make a "shell" of a partition (exact sizing important)
>>> on the GPT disk, then "dd" copy the MSDOS partition into the
>>> space set aside for the GPT partition. I have no idea whether
>>> that works. I can tell you, that the equivalent of an rsync
>>> between Windows C: type partitions, would never work, due to
>>> all the fiddly details involved in such things. Microsoft have
>>> gone out of their way, to ensure you can't Robocopy the entire
>>> C: drive into another partition. I *used* to do that in WinXP era,
>>> but those were simpler times and the file systems were a bit more
>>> bend-able back then.
>>>
>>> Windows has an MBR2GPT.exe utility, written by some hapless developer.
>>> Any program carrying out composite file system operations (partition,
>>> merge, shrink, done) is basically doomed to fail and fall on its face.
>>> Developers normally stick to "primitive" "one step" commands, for safety.
>>> Yet, somebody wrote that code... and it has enough smarts to reject
>>> disk configurations it does not like. Leaving only one configuration
>>> it does like. I think you can see coercing such a utility to do more
>>> than it intended to do, is a tall ask. It will not accept any old
>>> arbitrary configuration, and convert it.
>>>
>>> So yes, your mission looks like, technically do-able, but just about
>>> all the tools will tell you "I don't like broccoli", "I will sit
>>> here in this corner with this cold broccoli until hell freezes over",
>>> and so on :-) You've seen this before somewhere.
>>>
>>> MBR2GTP.exe can help you cross that river, but it won't allow
>>> you to carry a duck and a potato in the boat with you (a reference
>>> to this problem, where the problem was modified for an AI to solve).
>>> How the problem can involve a duck and a potato, I will never know.
>>>
>>> https://en.wikipedia.org/wiki/Wolf,_goat_and_cabbage_problem
>>>
>>> Summary: Do-able, but mostly a bar bet, like a steam powered rocket launch :-)
>>>
>>>      Paul
>>>
>>
>> So far it's been one huge exercise in futility beginning with my own impatiance. I had gone to great lengths to recover what bare data I could onto even duplicate data disks, I even made duplicates of the 3 ssd's that continued to perform *flawlessly* on my own older Crosshair legacy board. BEFORE I first tried the windows DOS disk I should have seen the red flag 'WHY did my son keep that one disk DOS when ALL the othes were GPT'?  But in my haste I didn't. I should also have dd'd mirror image FILES of the win-10 partition!
>>
>> So when I first tried the windows (10) disk in my EFI box maybe I didn't even have it in compatibility mode (or maybe I did, can't remember), it failed to boot and THAT's when I lost the plot completely thinking 'well maybe something's wrong with my clone of the disk' and OTHERWISE unsuspectingly I just swapped it for the (only) original one. In those few seconds win-10 on both got trashed (I suspect by the w10 installer but don't really know).
>>
>> If I knew what got changed I could maybe try to fix it before beginning all over but as it is I don't even have a working legacy BIOS departure point any more :-(
>>
>> BTW, having made several w10 freshies, I found the USB installers made with the WoeUSB linux utility fairly good AND persistent. The one made by the MS uti (on my laptop 'for another computer' which is my only windows also box) never worked at all, and the ones made with Ventoy got invariably destroyed for each 2nd attempt (see prompt blowup in image).
>>
>> https://imgur.com/59mcvHC
>>
>>
> 
> The boot menu is in a file called "BCD". The internal format is "registry file"
> but that never comes up when using tools to work on it. I mention that in case
> your hex editor examination shows "binary" and you are wondering why it is binary
> inside. They used a registry format, as a storage format for small objects.
> 
> It takes somewhere on the order of four specific commands, to make a brand new
> BCD file appear before your eyes. But because there are other files that
> are typically nearby, we don't usually "start from scratch" all that often.
> 
> Instead, we're looking for the directory where that is located, and
> doing something to augment the file.
> 
>      bcdedit                        # Dump the BCD file that the system booted with (good when OS is working)
> 
>      bcdedit /store C:\boot\BCD     # Dump the BCD file from selected location (while using install DVD to do maintenance)
> 
> Here are two pictures showing the Legacy and UEFI boot devices I have on the other machine.
> I'm showing these pictures, as the partition structure is a bit less noisy.
> 
>     [Picture]
> 
>      https://i.postimg.cc/7L4JqvX0/legacy-boot-example.gif
> 
>     [Picture]
> 
>      https://i.postimg.cc/zGZVkms6/UEFI-boot-example.gif
> 
> As an example of a "thing" you would do with bcdedit while
> the OS is running, these kinds of commands set the OS description
> in the on-screen boot menu, early in boot. The "identifier",
> can be spotted when you use the "bcdedit" command without parameters.
> and the "identifier" is context sensitive. It may appear with
> a different value when you are booted using a Windows installer DVD
> and the Troubleshooting Command Prompt window.
> 
> bcdedit /set {current} description "Windows 10"
> bcdedit /set {default} description "Windows 10"
> 
> If I was booted from the DVD, I would do them similar to this. The boot DVD, X: is the system partition.
> Leaving C: available as a letter for this sort of repair activity. Notice when I am using the DVD
> like this, I have to "know my stuff" to target the correct BCD file.
> 
> bcdedit /store C:\boot\BCD   /set {current} description "Windows 10"
> bcdedit /store C:\boot\BCD   /set {default} description "Windows 10"
> 
> *******
> 
> General rules of thumb (you know these already):
> 
> 1) Since "usually", the dependencies of an OS are on a single disk drive,
>     it makes the most sense to have boot material for it, right on that same drive.
>     This allows BIOS steering to the drive, if and when needed, for emergencies.
> 
> 2) You are certainly allowed to have a boot manager on disk 1, and jump over
>     to disk 2, using GUIDs or UUID or identifiers of that sort. But you also
>     want whatever OSes on disk 1, to be bootable from the disk 1 boot materials.
> 
> 3) This means, the BIOS could point at disk 1 for "machine-wide" boot, or
>     the BIOS could point to disk 2 for "disk 2 specific boot". There can be
>     a boot menu on disk 1 and disk 2. The only time this gets confusing,
>     is when you do "sudo update-grub", and there could be the odd surprise
>     depending on the configuration.
> 
> If I was in the room, the Windows disk with the boot problem, first
> we'd have to figure out whether the recommended rules were followed
> ("only have the disk receiving an install, connected during the install").
> If that was the case, then repairing the boot-ability, could again
> be performed on the single disk.
> 
> You will notice in my picture, I used "diskmgmt.msc" to display the
> disk setup in Windows. And the labels hint where key materials have gone.
> If "System", "Boot", and optionally "Active" are smeared over the two
> disks, this presents some challenges, and you have to decide what
> you want to do as a Wizard. You can move some of the materials around.
> I've done that a couple times, when something was in an awful mess.
> The purpose of moving the items, would be to try to get all those
> key identifiers lit up on the one disk.
> 
> I can't go much further than that, as with a non-booting system, even if
> we cable up the two forensic project disks to a third Windows system disk.
> the booted Windows will only show its own identifiers and not where
> everything is smeared on the other two disks. It's going to be
> a challenge to figure this out. By dumping the BCD file, there could
> be hints where the BCD is pointing. But again, no guarantees. It's all
> a bit of a puzzle at times, that's for sure.
> 
> *******
> 
> Preparing Macrium Reflect "Rescue CD", starts with the installer.
> I need some odds and ends to do a demo, so I'll try to post later.
> If your maintenance OS was 64-bit, you could use the 64-bit one.
> The reason for using the 32-bit one, is when booted from that,
> a small number of GUI-oriented win32 programs will run under that
> environment, which can be useful at forensics time.
> 
>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x64.exe
> 
>     Name: reflect_setup_free_x64.exe
>     Size: 115,719,576 bytes (110 MiB)
>     SHA1: B6724C7B6F5AF146406FAAA78F845A6C281D67D8
> 
>     There is also a 32-bit one. For 32-bit setups.
> 
>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x86.exe
> 
>     Paul

That thick brown morass just keeps getting deeper and deeper...

Were it not that the circumstances make this chore important to me I 
would long ago have tossed the whole thing out into the dump bin; that, 
alas, is not the case.

So I caved in and bought Macrium (all-in-all close to $100cad) ......but 
can't even install it because the only window that boots is w7 but it 
doesn't have sha-2 and w10 is the one I want to salvage because it 
doesn't boot. Anyway, to get sha-2 I had to do another update but then 
the sha-2 update bombed on reboot and keeps reverting to 'uninstalled'. 
Still I managed to INITIATE a Macrium install before rebooting but could 
never complete it. It never ends for crissssake!

Things have changed. This rentalware gets licensed to ONE computer so I 
think I will re-install a w-10 freshie this evening on my Ryzen box and 
take it from there beginning with making a rescue-CD.

[toc] | [prev] | [next] | [standalone]

#81447

On Fri, 4/25/2025 8:33 AM, bad sector wrote:

> That thick brown morass just keeps getting deeper and deeper...
> 
> Were it not that the circumstances make this chore important to me I would long ago have tossed the whole thing out into the dump bin; that, alas, is not the case.
> 
> So I caved in and bought Macrium (all-in-all close to $100cad) ......but can't even install it because the only window that boots is w7 but it doesn't have sha-2 and w10 is the one I want to salvage because it doesn't boot. Anyway, to get sha-2 I had to do another update but then the sha-2 update bombed on reboot and keeps reverting to 'uninstalled'. Still I managed to INITIATE a Macrium install before rebooting but could never complete it. It never ends for crissssake!
> 
> Things have changed. This rentalware gets licensed to ONE computer so I think I will re-install a w-10 freshie this evening on my Ryzen box and take it from there beginning with making a rescue-CD.
> 

Unless they removed it, the link I gave you was for a free version
of Macrium. You didn't have to buy it. For example, if you had
a Win7 32-bit as your daily driver OS, you could install the
second link here if you wanted. The filename is reflect-setup-FREE...

The three artwork links, correspond to the usage of this software.

   https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x64.exe

   Name: reflect_setup_free_x64.exe
   Size: 115,719,576 bytes (110 MiB)
   SHA1: B6724C7B6F5AF146406FAAA78F845A6C281D67D8

   There is also a 32-bit one. For 32-bit setups.

   https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x86.exe

Use the three artwork links, for details as to how to fill out the dialogs.

The 64-bit one, and Rufus, should be able to make a UEFI boot
stick. The 32-bit one looks a bit more of an issue that way.

   Paul

[toc] | [prev] | [next] | [standalone]

#81448

On 4/25/25 12:42, Paul wrote:
> On Fri, 4/25/2025 8:33 AM, bad sector wrote:
> 
>> That thick brown morass just keeps getting deeper and deeper...
>>
>> Were it not that the circumstances make this chore important to me I would long ago have tossed the whole thing out into the dump bin; that, alas, is not the case.
>>
>> So I caved in and bought Macrium (all-in-all close to $100cad) ......but can't even install it because the only window that boots is w7 but it doesn't have sha-2 and w10 is the one I want to salvage because it doesn't boot. Anyway, to get sha-2 I had to do another update but then the sha-2 update bombed on reboot and keeps reverting to 'uninstalled'. Still I managed to INITIATE a Macrium install before rebooting but could never complete it. It never ends for crissssake!
>>
>> Things have changed. This rentalware gets licensed to ONE computer so I think I will re-install a w-10 freshie this evening on my Ryzen box and take it from there beginning with making a rescue-CD.
>>
> 
> Unless they removed it, the link I gave you was for a free version
> of Macrium. You didn't have to buy it. For example, if you had
> a Win7 32-bit as your daily driver OS, you could install the
> second link here if you wanted. The filename is reflect-setup-FREE...
> 
> The three artwork links, correspond to the usage of this software.
> 
>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x64.exe
> 
>     Name: reflect_setup_free_x64.exe
>     Size: 115,719,576 bytes (110 MiB)
>     SHA1: B6724C7B6F5AF146406FAAA78F845A6C281D67D8
> 
>     There is also a 32-bit one. For 32-bit setups.
> 
>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x86.exe
> 
> Use the three artwork links, for details as to how to fill out the dialogs.
> 
> The 64-bit one, and Rufus, should be able to make a UEFI boot
> stick. The 32-bit one looks a bit more of an issue that way.
> 
>     PaulZAeiMD@kL47#QThMu4TBN8&3e?@kNkNiMD.o4f635G4z


I was in way over my head, throughout this entire task actually because 
I knew next to nothing about windows and absolutely nothing about EFI. 
This weekend I'm staging for the next attack. Got the facilitating 
version of disk-1 done, it has a freshie linux Tumbleweed and a w10 on 
it also in addition to the original Linux which boots and works fine. 
Got the Reflect installation done too (which BTW has to be done on-line 
if using the home edition). Made the Rescue CD too. Don't know much 
about their ReDeployment feature yet.

This evening I moved most of my own rags over to the new machine, 
that'll get finished before Monday. Lots of reading to do, I may not 
need to use the old legacy box at all. For example I read that w7 
'should' boot without issues on the EFI box, in EFI mode, IF the w7 
partition on the DOS disk is changed to GPT (apparently gdisk can do 
this without data loss), etc. etc.

[toc] | [prev] | [next] | [standalone]

#81453

On 4/25/25 12:42 PM, Paul wrote:
> On Fri, 4/25/2025 8:33 AM, bad sector wrote:
> 
>> That thick brown morass just keeps getting deeper and deeper...
>>
>> Were it not that the circumstances make this chore important to me I would long ago have tossed the whole thing out into the dump bin; that, alas, is not the case.
>>
>> So I caved in and bought Macrium (all-in-all close to $100cad) ......but can't even install it because the only window that boots is w7 but it doesn't have sha-2 and w10 is the one I want to salvage because it doesn't boot. Anyway, to get sha-2 I had to do another update but then the sha-2 update bombed on reboot and keeps reverting to 'uninstalled'. Still I managed to INITIATE a Macrium install before rebooting but could never complete it. It never ends for crissssake!
>>
>> Things have changed. This rentalware gets licensed to ONE computer so I think I will re-install a w-10 freshie this evening on my Ryzen box and take it from there beginning with making a rescue-CD.
>>
> 
> Unless they removed it, the link I gave you was for a free version
> of Macrium. You didn't have to buy it. For example, if you had
> a Win7 32-bit as your daily driver OS, you could install the
> second link here if you wanted. The filename is reflect-setup-FREE...
> 
> The three artwork links, correspond to the usage of this software.
> 
>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x64.exe
> 
>     Name: reflect_setup_free_x64.exe
>     Size: 115,719,576 bytes (110 MiB)
>     SHA1: B6724C7B6F5AF146406FAAA78F845A6C281D67D8
> 
>     There is also a 32-bit one. For 32-bit setups.
> 
>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x86.exe
> 
> Use the three artwork links, for details as to how to fill out the dialogs.
> 
> The 64-bit one, and Rufus, should be able to make a UEFI boot
> stick. The 32-bit one looks a bit more of an issue that way.
> 
>     Paul

It may have seemed like I was ignoring your advice but I was just 
staging for a 1st attempt with macrium. Ran into all manner of problems 
like my w7 legacy box not even knowing what wifi is in an environment 
that offers only 3 possibilities

1 wifi hotspot off my phone
2 usb tether off my phone
3 radio link past my ethernet connected router

ALL of them useless in bad weather but after updating to the Crosshair 
board's ethernet driver #3 worked for a short while before packing up 
due to heavy rain. Enough complaining :-)

I had all your posts and images printed and laid out in front of me as I 
set out to test my luck. Session-1 running on the legacy-BIOS box was 
*not exactly a waste of time*. After having figured out that the w7 was 
a 64bit job, I ran the 64bit RESCUE against both w7 and w10 on a copy of 
disk-2 (the one with the 2 windows on it).

After clearing a few chickenshit items on w7 the run against w10 ended 
up failing but with some comments. It seems that some OS version 
mismatch is at fault (see wallpaper on my 1st EFI desktop).

https://imgur.com/WbDgBFZ.png

There's more over-my-head in this than if I were in the Titan but just a 
wild guess: the legacy-BIOS w10 locked up like a paranoid clam when I 
tried to boot it on an EFI machine, subsequent repair attempts failed 
because the installer was another 'version'? And what will MS do if I 
send them the dump, send my dead son an email in three months to attempt 
a repair with the builder dvd (no idea where "I" would find either that 
email with a failed w10 or the dvd)?

[toc] | [prev] | [next] | [standalone]

#81454

On Sun, 4/27/2025 8:43 AM, bad sector wrote:
> On 4/25/25 12:42 PM, Paul wrote:
>> On Fri, 4/25/2025 8:33 AM, bad sector wrote:
>>
>>> That thick brown morass just keeps getting deeper and deeper...
>>>
>>> Were it not that the circumstances make this chore important to me I would long ago have tossed the whole thing out into the dump bin; that, alas, is not the case.
>>>
>>> So I caved in and bought Macrium (all-in-all close to $100cad) ......but can't even install it because the only window that boots is w7 but it doesn't have sha-2 and w10 is the one I want to salvage because it doesn't boot. Anyway, to get sha-2 I had to do another update but then the sha-2 update bombed on reboot and keeps reverting to 'uninstalled'. Still I managed to INITIATE a Macrium install before rebooting but could never complete it. It never ends for crissssake!
>>>
>>> Things have changed. This rentalware gets licensed to ONE computer so I think I will re-install a w-10 freshie this evening on my Ryzen box and take it from there beginning with making a rescue-CD.
>>>
>>
>> Unless they removed it, the link I gave you was for a free version
>> of Macrium. You didn't have to buy it. For example, if you had
>> a Win7 32-bit as your daily driver OS, you could install the
>> second link here if you wanted. The filename is reflect-setup-FREE...
>>
>> The three artwork links, correspond to the usage of this software.
>>
>>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x64.exe
>>
>>     Name: reflect_setup_free_x64.exe
>>     Size: 115,719,576 bytes (110 MiB)
>>     SHA1: B6724C7B6F5AF146406FAAA78F845A6C281D67D8
>>
>>     There is also a 32-bit one. For 32-bit setups.
>>
>>     https://download.macrium.com/reflect/v7/v7.3.6284/reflect_setup_free_x86.exe
>>
>> Use the three artwork links, for details as to how to fill out the dialogs.
>>
>> The 64-bit one, and Rufus, should be able to make a UEFI boot
>> stick. The 32-bit one looks a bit more of an issue that way.
>>
>>     Paul
> 
> It may have seemed like I was ignoring your advice but I was just staging for a 1st attempt with macrium. Ran into all manner of problems like my w7 legacy box not even knowing what wifi is in an environment that offers only 3 possibilities
> 
> 1 wifi hotspot off my phone
> 2 usb tether off my phone
> 3 radio link past my ethernet connected router
> 
> ALL of them useless in bad weather but after updating to the Crosshair board's ethernet driver #3 worked for a short while before packing up due to heavy rain. Enough complaining :-)
> 
> I had all your posts and images printed and laid out in front of me as I set out to test my luck. Session-1 running on the legacy-BIOS box was *not exactly a waste of time*. After having figured out that the w7 was a 64bit job, I ran the 64bit RESCUE against both w7 and w10 on a copy of disk-2 (the one with the 2 windows on it).
> 
> After clearing a few chickenshit items on w7 the run against w10 ended up failing but with some comments. It seems that some OS version mismatch is at fault (see wallpaper on my 1st EFI desktop).
> 
> https://imgur.com/WbDgBFZ.png
> 
> There's more over-my-head in this than if I were in the Titan but just a wild guess: the legacy-BIOS w10 locked up like a paranoid clam when I tried to boot it on an EFI machine, subsequent repair attempts failed because the installer was another 'version'? And what will MS do if I send them the dump, send my dead son an email in three months to attempt a repair with the builder dvd (no idea where "I" would find either that email with a failed w10 or the dvd)?
> 
> 
I'm seeing some Win7 and Win10 numbers there.
The Win10 era thing is doing the repair ? It really
should be able to detect legacy and UEFI boot. The
only thing I can think of, is maybe the Win7 was 32 bit
and the UEFI EFI contents are 64 bit, and the repair
isn't happen about trying to circle the squares on
mixing Win10 and Win7 at the same time ?

I probably don't test enough 32-bit combos, to know about
an issue like that.

Normally, when doing forensics, if the original machine
was 4GB or less, that gives the user an incentive to
install 32-bit. If the machine was, say, 16GB, they would
want to use all the RAM, so they would go with the 64-bit OS.

From the Macrium rescue CD booted, it would look like this. This is
an older reference, but still captures the essentials.

   https://reflect.macrium.com/help/v5/rescue_cds/fix_boot_problems.htm

You can see another example of the things you can attempt with
the Rescue CD, here. Putting the boot menu back at the end, is
pretty cheeky. I suppose it saves on doing some touchup with
bcdedit, to put Descriptions back and so on.

   https://www.tenforums.com/tutorials/85198-use-macrium-reflect-rescue-media-fix-windows-boot-issues.html

You could take a picture of the disk being repaired, with "gnome-disks",
so there's at least a hint what is in the mix.

Only when a disk like that boots, do you get decent labeling of
the partitions. But using "diskpart.exe" and assigning letters
to hidden partitions, you can "CD" to a hidden partition and
list the files in there.

  Paul

[toc] | [prev] | [next] | [standalone]

#81368

On Sat, 12 Apr 2025 19:50:13 -0400, bad sector wrote:

> But I cannot boot his windows, for that I'd have to keep my old
> Legacy-BIOS box which I don't want to do ...

Would it boot in a VM?

[toc] | [prev] | [next] | [standalone]

#81370

On Mon, 4/14/2025 12:27 AM, Lawrence D'Oliveiro wrote:
> On Sat, 12 Apr 2025 19:50:13 -0400, bad sector wrote:
> 
>> But I cannot boot his windows, for that I'd have to keep my old
>> Legacy-BIOS box which I don't want to do ...
> 
> Would it boot in a VM?
> 

W10 and W11, boot on "stranger systems" now, just like Linux does.
Not exactly the same way, but it works. That means a system packaged
into a container, and run in something like VirtualBox, should work.
You should attempt to match boot type, when adjusting the controls
on the Guest setup.

If there is any sort of encryption involved, and there isn't a
recovery media stick laying around in the vicinity, you might
need to log into the MSA account on the microsoft site, and
fetch the recovery key from there. but best practice is to
make recovery media. I would use a floppy for that, as the size
required is not large, I have a USB to floppy and the odd garbage
floppy diskette in some box, suited for the storage.

Even on Home, you can check for some kind of encryption. One of the
status types presumably available, would be FDE for this (encryption
hosted by the hard xrive controller itself) rather than software Bitlocker
protection. In an Administrator terminal...

PS> manage-bde -status
BitLocker Drive Encryption: Configuration Tool version 10.0.22621
Copyright (C) 2013 Microsoft Corporation. All rights reserved.

Disk volumes that can be protected with
BitLocker Drive Encryption:
Volume C: [W11HOME]
[OS Volume]

    Size:                 118.73 GB
    BitLocker Version:    None
    Conversion Status:    Fully Decrypted
    Percentage Encrypted: 0.0%
    Encryption Method:    None
    Protection Status:    Protection Off
    Lock Status:          Unlocked
    Identification Field: None
    Key Protectors:       None Found

That command accepts "-h" for help.

   Paul

[toc] | [prev] | [next] | [standalone]

#81371

On 4/14/25 00:27, Lawrence D'Oliveiro wrote:
> On Sat, 12 Apr 2025 19:50:13 -0400, bad sector wrote:
> 
>> But I cannot boot his windows, for that I'd have to keep my old
>> Legacy-BIOS box which I don't want to do ...
> 
> Would it boot in a VM?

No experience with VM beyond running w10 under virtualbox installed for 
the single purpose of the bundleware for my GX100 guitar effects board. 
And even at that, I load it only about once a year so I pretty well 
fotget EVERYTHING about it in between sessions.

I wanted to use SuperGrub to maybe boot the two windows but had trouble 
getting this freakin AMI efi-bios to accept the DVD as boot medium, I'll 
have to try that again while waiting for word from Macrium. Assuming 
that if SuperGrub did manage tp boot w10 or 7 then I could get windows 
to lay boot code inthe MBR of disk 1 which (I forgot to mention) is a 
DOS disk and does the boots. After that I could get grub to rule the 
underworld again :-)

The 3 ssd's that boot and work fine on my old Crosshair-IV board are

1 - 500gb: boot and mostly Linux
2 - 1tb: the 2 windows 'c' drives (partitions 2 & 3 for w7 & w10) + data
3 - 4tb: just data

I have ssd-1 cloned onto a 1tb ssd which now also has linux Tumbleweed, 
and an also 1tb ssd which is an exact clone of ssd-2. Ssd-2 & 3 are very 
strait forward but linux RAID was distributed on ssd-1 and 3 other data 
drives. Those other drives have been wiped and are gone with the server 
tower, I had to issue some cLi command to clear all RAID references from 
them even after wiping. I do not dare touch the RAID remnants on ssd-1 
for fear of regretting it. Another clone would be good for that but this 
ssd-1 hosts only linux which boots fine on both machines so why muck 
with it? However it also had the MBR legacy boot including for the 
windows on ssd-2 and those are what don't boot on my new smoke and 
snake-oil EFI board.

[toc] | [prev] | [next] | [standalone]

#81373

On Mon, 4/14/2025 6:03 AM, bad sector wrote:
> On 4/14/25 00:27, Lawrence D'Oliveiro wrote:
>> On Sat, 12 Apr 2025 19:50:13 -0400, bad sector wrote:
>>
>>> But I cannot boot his windows, for that I'd have to keep my old
>>> Legacy-BIOS box which I don't want to do ...
>>
>> Would it boot in a VM?
> 
> No experience with VM beyond running w10 under virtualbox installed for the single purpose of the bundleware for my GX100 guitar effects board. And even at that, I load it only about once a year so I pretty well fotget EVERYTHING about it in between sessions.
> 
> I wanted to use SuperGrub to maybe boot the two windows but had trouble getting this freakin AMI efi-bios to accept the DVD as boot medium, I'll have to try that again while waiting for word from Macrium. Assuming that if SuperGrub did manage tp boot w10 or 7 then I could get windows to lay boot code inthe MBR of disk 1 which (I forgot to mention) is a DOS disk and does the boots. After that I could get grub to rule the underworld again :-)
> 
> The 3 ssd's that boot and work fine on my old Crosshair-IV board are
> 
> 1 - 500gb: boot and mostly Linux
> 2 - 1tb: the 2 windows 'c' drives (partitions 2 & 3 for w7 & w10) + data
> 3 - 4tb: just data
> 
> I have ssd-1 cloned onto a 1tb ssd which now also has linux Tumbleweed, and an also 1tb ssd which is an exact clone of ssd-2. Ssd-2 & 3 are very strait forward but linux RAID was distributed on ssd-1 and 3 other data drives. Those other drives have been wiped and are gone with the server tower, I had to issue some cLi command to clear all RAID references from them even after wiping. I do not dare touch the RAID remnants on ssd-1 for fear of regretting it. Another clone would be good for that but this ssd-1 hosts only linux which boots fine on both machines so why muck with it? However it also had the MBR legacy boot including for the windows on ssd-2 and those are what don't boot on my new smoke and snake-oil EFI board.
> 

This drawing isn't exactly right, but I want to illustrate a
setup where two boot paths are possible, and the disks have
a measure of "independence". For example, if Disk1 was disconnected,
a good BIOS design might automatically locate Disk2 and do what
comes naturally.

      +-----+-----------+--- - - - - - - -
disk1 | MBR | GRUB 1.5  |  Linux slash                                # When the BIOS is set to boot from
      +-----+-----------+--- - - - - - - -                            # Disk1, the GRUB menu is offered
                         |
                         | (Chainload?)
                         v
      +-----+--------+--------+------+-------+------+--- - - - - -    # If the BIOS is set to boot from
disk2 | MBR | Active |  Win7  | ???  | Win10 | ???                    # Disk2, the Windows Boot manager is offered
      +-----+--------+--------+------+-------+------+--- - - - - -    # and you can also get to Windows 7
         |     ^  v      ^
         +-----+  +------+

The disk2 should have a life of its own. It should boot
on an MBR system, but hardware differences between boxes
would screw up Windows 7, so you might hold off on booting
Windows 7 until you have backed up disk2.

Whereas Windows 10 could boot on a "stranger" system
and be a functional OS. I don't know what happens to the
license when you do that. It does not seem to harm
moving the disk back to the original computer (as I have
accidentally booted W10/W11 on the wrong computer here
before).

The older OSes are less pleased about booting on a
"stranger" system, as it looks like an attempt at
"license theft" or something. The symptoms vary.
Instant session termination (freeze). 72 hours grace period.
30 days grace period. That's why you back up things
like that, so the license does not come to an untimely end.

If you use the MBR2GPT.exe utility (system util available W10/W11),
then you can convert the simplest disk2 configurations
to GPT. Then, the "independent" disk2, could become
a UEFI candidate for the new computer. But the licensing on
Windows 7 is the unknown/tricky part. And there aren't
a lot of Win7 Retail SKU installations floating around,
so "moving" the installation in an official way, it's
more likely the install disk used was a Win7 System Builder DVD.
That's half the price of a Retail DVD.

      +-----+--------+--------+------+-------+------+--- - - - - -    # If the BIOS is set to boot from
disk2 | MBR |   ESP  |  Win7  | ???  | Win10 | ???                    # Disk2, the Windows Boot manager is offered
(GPT) +-----+--------+--------+------+-------+------+--- - - - - -    # and you can also get to Windows 7
         |     ^  v      ^
         +-----+  +------+                                            # When MBR2GPT.exe messes about,
                                                                      # the partition order can change

It's possible Win7 x64 could boot UEFI as a GPT partition,
but maybe the 32 bit version of Windows 7 would not work.
That should be mentioned here.

   https://en.wikipedia.org/wiki/GUID_Partition_Table

      "Windows 7 and earlier do not support UEFI on 32-bit platforms,
       and therefore do not allow booting from GPT partitions."

With the Win7 C: partition mounted, you look at the top level.
You cannot "Repair Install" the OS and change it from 32 bit to 64 bit
or vice versa. OS installations "on top", must match on version.
A 64 bit Repair on top, or a 64 bit Upgrade on top of a 64 bit existing OS work.

   Program Files        <=== 32 bit OS has only one folder

   Program Files        \___ This is a 64 bit system, running 64 bit or 32 bit apps.
   Program Files (x86)  /

The road is strewn with landmines, which is why backups or clones
are a necessary evil while doing this sort of work.

You can remove a license, with "slmgr". But a System Builder license is
not transferable to a second machine, whereas a Retail license
could be moved. The licenses don't say what they are. Only holding
the COA card in hand, from when it was purchased, might give a hint.

   Paul

[toc] | [prev] | [next] | [standalone]

#81378

On Mon, 14 Apr 2025 08:16:09 -0400, Paul wrote:

> But a System Builder license is not transferable to a second
> machine, whereas a Retail license could be moved. The licenses don't
> say what they are. Only holding the COA card in hand, from when it
> was purchased, might give a hint.

Note that, when they do piracy audits, they don’t go by COAs or such. They 
want to see actual invoices.

[toc] | [prev] | [next] | [standalone]

#81380

On 4/14/25 08:16, Paul wrote:
> On Mon, 4/14/2025 6:03 AM, bad sector wrote:
>> On 4/14/25 00:27, Lawrence D'Oliveiro wrote:
>>> On Sat, 12 Apr 2025 19:50:13 -0400, bad sector wrote:
>>>
>>>> But I cannot boot his windows, for that I'd have to keep my old
>>>> Legacy-BIOS box which I don't want to do ...
>>>
>>> Would it boot in a VM?
>>
>> No experience with VM beyond running w10 under virtualbox installed for the single purpose of the bundleware for my GX100 guitar effects board. And even at that, I load it only about once a year so I pretty well fotget EVERYTHING about it in between sessions.
>>
>> I wanted to use SuperGrub to maybe boot the two windows but had trouble getting this freakin AMI efi-bios to accept the DVD as boot medium, I'll have to try that again while waiting for word from Macrium. Assuming that if SuperGrub did manage tp boot w10 or 7 then I could get windows to lay boot code inthe MBR of disk 1 which (I forgot to mention) is a DOS disk and does the boots. After that I could get grub to rule the underworld again :-)
>>
>> The 3 ssd's that boot and work fine on my old Crosshair-IV board are
>>
>> 1 - 500gb: boot and mostly Linux
>> 2 - 1tb: the 2 windows 'c' drives (partitions 2 & 3 for w7 & w10) + data
>> 3 - 4tb: just data
>>
>> I have ssd-1 cloned onto a 1tb ssd which now also has linux Tumbleweed, and an also 1tb ssd which is an exact clone of ssd-2. Ssd-2 & 3 are very strait forward but linux RAID was distributed on ssd-1 and 3 other data drives. Those other drives have been wiped and are gone with the server tower, I had to issue some cLi command to clear all RAID references from them even after wiping. I do not dare touch the RAID remnants on ssd-1 for fear of regretting it. Another clone would be good for that but this ssd-1 hosts only linux which boots fine on both machines so why muck with it? However it also had the MBR legacy boot including for the windows on ssd-2 and those are what don't boot on my new smoke and snake-oil EFI board.
>>
> 
> This drawing isn't exactly right, but I want to illustrate a
> setup where two boot paths are possible, and the disks have
> a measure of "independence". For example, if Disk1 was disconnected,
> a good BIOS design might automatically locate Disk2 and do what
> comes naturally.
> 
>        +-----+-----------+--- - - - - - - -
> disk1 | MBR | GRUB 1.5  |  Linux slash                                # When the BIOS is set to boot from
>        +-----+-----------+--- - - - - - - -                            # Disk1, the GRUB menu is offered
>                           |
>                           | (Chainload?)
>                           v
>        +-----+--------+--------+------+-------+------+--- - - - - -    # If the BIOS is set to boot from
> disk2 | MBR | Active |  Win7  | ???  | Win10 | ???                    # Disk2, the Windows Boot manager is offered
>        +-----+--------+--------+------+-------+------+--- - - - - -    # and you can also get to Windows 7
>           |     ^  v      ^
>           +-----+  +------+
> 
> The disk2 should have a life of its own. It should boot
> on an MBR system, but hardware differences between boxes
> would screw up Windows 7, so you might hold off on booting
> Windows 7 until you have backed up disk2.

I'll look around to see if I can find a couple of months to digest this :-)

The timing is good however because after having liberated the remaining 
3-4 small linux partitions from the raid array it now boots with many 
fewer partitions, equivalents of those but now on their own. I could 
even pile all these into a single one but I don't wanna push my luck 
just yet.

This now simplified leftover of the disk-1 clone could also be legacy 
MBR, my new board might even be able to boot it with the legacy 
compatibility whatyoumacallit (I'll have to see). Meanwhile just trying 
for the disk-2 as booter approach is more handy to give me what to do 
tonight. The advantage here is that the clone-surviving disk-1 could 
remain EFI and even host a facilitating w10 freshie, just in case.





> Whereas Windows 10 could boot on a "stranger" system
> and be a functional OS. I don't know what happens to the
> license when you do that. It does not seem to harm
> moving the disk back to the original computer (as I have
> accidentally booted W10/W11 on the wrong computer here
> before).
> 
> The older OSes are less pleased about booting on a
> "stranger" system, as it looks like an attempt at
> "license theft" or something. The symptoms vary.
> Instant session termination (freeze). 72 hours grace period.
> 30 days grace period. That's why you back up things
> like that, so the license does not come to an untimely end.
> 
> If you use the MBR2GPT.exe utility (system util available W10/W11),
> then you can convert the simplest disk2 configurations
> to GPT. Then, the "independent" disk2, could become
> a UEFI candidate for the new computer. But the licensing on
> Windows 7 is the unknown/tricky part. And there aren't
> a lot of Win7 Retail SKU installations floating around,
> so "moving" the installation in an official way, it's
> more likely the install disk used was a Win7 System Builder DVD.
> That's half the price of a Retail DVD.
> 
>        +-----+--------+--------+------+-------+------+--- - - - - -    # If the BIOS is set to boot from
> disk2 | MBR |   ESP  |  Win7  | ???  | Win10 | ???                    # Disk2, the Windows Boot manager is offered
> (GPT) +-----+--------+--------+------+-------+------+--- - - - - -    # and you can also get to Windows 7
>           |     ^  v      ^
>           +-----+  +------+                                            # When MBR2GPT.exe messes about,
>                                                                        # the partition order can change
> 
> It's possible Win7 x64 could boot UEFI as a GPT partition,
> but maybe the 32 bit version of Windows 7 would not work.
> That should be mentioned here.
> 
>     https://en.wikipedia.org/wiki/GUID_Partition_Table
> 
>        "Windows 7 and earlier do not support UEFI on 32-bit platforms,
>         and therefore do not allow booting from GPT partitions."
> 
> With the Win7 C: partition mounted, you look at the top level.
> You cannot "Repair Install" the OS and change it from 32 bit to 64 bit
> or vice versa. OS installations "on top", must match on version.
> A 64 bit Repair on top, or a 64 bit Upgrade on top of a 64 bit existing OS work.
> 
>     Program Files        <=== 32 bit OS has only one folder
> 
>     Program Files        \___ This is a 64 bit system, running 64 bit or 32 bit apps.
>     Program Files (x86)  /
> 
> The road is strewn with landmines, which is why backups or clones
> are a necessary evil while doing this sort of work.
> 
> You can remove a license, with "slmgr". But a System Builder license is
> not transferable to a second machine, whereas a Retail license
> could be moved. The licenses don't say what they are. Only holding
> the COA card in hand, from when it was purchased, might give a hint.

[toc] | [prev] | [standalone]

Back to top | Article view | alt.os.linux

csiph-web