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

Groups > alt.os.linux > #81435

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

Show all headers | View raw

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

Back to alt.os.linux | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web