From Newsgroup: alt.comp.os.windows-11

Paul wrote on 11/23/2025 11:45 PM:

On Mon, 11/24/2025 12:53 AM, ...w¡ñ§±¤ñ wrote:

Paul wrote on 11/22/2025 11:54 PM:

In any case, the 600MB/sec ports are enumerated before the 300MB/sec ones. >>> The ports do not have a particular color scheme. (No particular technical >>> reason for this, just decodes on the logic blocks ended up that way.)

I use black and red cables, black go in fast ports, red go in slow ports. >>

Apparently we think alike on cable colors for SATA II and SATA III ports. >>>

If you move drives around and re-cable them... then their disk number changes.

On some mobos the disk connected to the lowest numbered highest priority sata port(enumerates as disk 0) - e.g. Z87 Sabertooth for SSD or HDD

*******

If the disk number changes, that affects

     reagentc /info

and it is quite possible the recovery OS gets disabled
when that happens. But the recovery feature is so poorly
designed, who would notice which particular case of
brokenness it had. I checked the other machine and it is
disabled again. I'm sick of fixing this.

Interesting...what are you doing that disables WinRE.
 The only time WinRe has ever been disabled on all my devices(Desktop, Laptop, Tablet[Surface 3]) is when I've purposely disabled it.

Fyi...my Surface 3 Win10 Pro 22H2 was failing to update to the last 22H2 cumulative and prior to it being enrolled in Win10 ESU(those Reward points came in handy).
 The WinRE only had 140 MB free space(total was just shy of 827 MB) on its 128 GB(~116 actual)SSD(about 50 used, 66 free). Disabled WinRE, Shrunk C by 1221 MB, then recreated a 2 GB WinRE, renabled. 22H2 last update installed, then enrolled/added the device to ESU enrollment.
Interestingly the first ESU update on the Surface was quite quick(timewise) about 2 minutes(cumulative updates in the past have taken 15-20 minutes).

I multiboot Windows.

And this feature (WinRE) just does not work right.

[Picture]

https://i.postimg.cc/yNMx6BKJ/Disk33-Multiboot-Disk-Management.gif

When the Recovery boots, it will tell you whether
it likes what you're asking it to do or not. And
the booting thing, wants to be repairing a "matching OS".
And that means, if you put recovery partitions after
each OS... you expect them to be handled that way.
The multiboot OSes SHOULD NOT hop over and abuse
the Recovery Partition of another OS.

The whole implementation is just so much crap. Sorry.

Did I not earlier read that it WinRE was disabled.
- i.e. if so, was the winre.wim file it its disabled location(folder)
C:\Windows\System32\Recovery

Iirc, there were issues with dual booting(Windows and Linux) where WEinRE
was disabled, then re-enabled but still failing to run...that required a variety of steps to resolve(corrupted/missing Reagent.xml, fixing WinRE, fixing the bootloader, copying/replacing the boot.sid file from a known
good location). Maybe that history of issues in dual booting and multiple recovery partitions has always been a problem even when Windows editions
are the only other booting os on the same disk(e.g. your 3 different os editions, each with its own recovery)

It should be labeling its materials ONLY via GUIDs,
not drive letters, harddisk0\Partition3, or using
letters from mom. It hardly ever does what it is
supposed to do, at maintenance time. It's a shambles,
and the person who "made this" should have their ass kicked.

Lol...mom probably gave up on sending letters some time ago. Likewise,
those developers were never given direction to fix WinRE where dual boot systems were in play(i.e. requests to do so, never even reached the
circular file, disposed or ignored without any further thought)

I find, if the Recovery ever runs, it tells you it is
"scanning something" or "processing something" and there
is no percentage indicator to indicate forward progress.
In virtually all cases, I fixed the problem myself,
while my blood pressure was raised just that much more
by the time wasting Recovery procedure.

We, have all wasted time on seemingly futile projects...it's like bull riding....sometimes we stay on the bull for a few seconds, sometimes the
bull flips us off.
--
...w¡ñ§±¤ñ
--- Synchronet 3.21a-Linux NewsLink 1.2