On 3/17/2024 11:31 AM, Philip Herlihy wrote:
> In article <ut55o8$341m1$1@dont-email.me>, Paul wrote...
>>
>> On 3/16/2024 5:53 PM, Philip Herlihy wrote:
>>> In article <MPG.40600faf8bed89c6989ab7@news.eternal-september.org>, Philip
>>> Herlihy wrote...
>>>>
>>>> In article <ut2of9$2hmc1$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...
>>>>>
>>>>> Philip Herlihy wrote on 3/15/24 11:05 AM:
>>>>>> In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...
>>>>>>>
>>>>>>> Philip Herlihy wrote on 3/13/24 4:12 PM:
>>>>>>>>
>>>>>>>> The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
>>>>>>>> 500MB EFI System partition
>>>>>>>> 225GB OS
>>>>>>>> 852MB now Unallocated after my meddling
>>>>>>>> 10GB Recovery Partition
>>>>>>>> 1GB Recovery Partition
>>>>>>>>
>>>> ...
>>>>
>>>> I've now completed all the steps in https://bit.ly/3TCu9Y8, disabling and re-
>>>> enabling Bitlocker on either side. Everything seemed to work, and all commands
>>>> gave positive status. The 'stuck' update is now safely installed. Thanks to
>>>> everyone for help with this.
>>>>
>>>>
>>>>>
>>>>> Did you disable the the WinRE partition before deleting the WinRE partition?
>>>>> - reagentc /disable
>>>>> Did you verify the harddisk# and partition# of the WinRE recovery
>>>>> partition before deleting the WinRE partition?
>>>>> - reagentc /info
>>>>
>>>> YES
>>>>
>>>>>
>>>>> If you disabled the WinRE partition before deletion, the necessaryt
>>>>> winre.wim file will be located in C:\Windows\System32\Recovery
>>>>> - you will need to configure File Explorer to see the file's presence
>>>>> in the above folder
>>>>> File Explorer/Options/View
>>>>> - Enable 'Show hidden files, folders, and drives
>>>>> - Uncheck 'Hide extensions of known file types'
>>>>> - Uncheck 'Hide protected operating system files'
>>>>>
>>>>
>>>> Well, it's not there now, though I have completed all the steps, including
>>>> reagentc /enable, so from what you say winre.wim should have been moved to the
>>>> newly re-created Recovery partition.
>>>>
>>>>> If the file is not present, it would seem to indicate you didn't disable
>>>>> the WinRE partition prior to deleting the WinRE partition or something
>>>>> else is/was in play.
>>>>> - i.e. the file is important, because once a new Recovery partition is
>>>>> created, the reagentc /enable command will look for that file in
>>>>> C:\Windows\System32\Recovery and move it back(not copy) to the newly
>>>>> created WinRE partition.
>>>>>
>>>>> Do you have a backup image of the WinRE recovery partiton, e.g. Macrium
>>>>> Reflect?
>>>>
>>>> No, but all the user data was copied off to another machine first, and I'd have
>>>> been content to reinstall the machine if needed.
>>>>>
>>>>> Please answer the questions(and advance thanks for doing so)
>>>>
>>>> Least I could do after your help.
>>>>
>>>> My knowledge on how the Recovery partition works is sketchy at best. I
>>>> recognise winre.wim (I think?) as a possible source for system files when doing
>>>> a DISM /online /RestoreHealth. Is there a concise *introductory* article you
>>>> could recommend for getting my head round all this?
>>>
>>> Reagentc /info gives the Recovery partition as partition 6, which Disk
>>> Management shows as immediately following the OS partition. After partition 6
>>> there are two other Recovery partitions, presumably redundant. Can I delete
>>> them?
>>
>> Yes, as long as your knowledge of the numbering is flawless.
>>
>> Remember that Disk Management does not show the tiny 16MB MSR, as
>> it does not have a file system. But the partition table uses up
>> a number, to define a space for it. It's still a partition, and
>> that's how the numbering does not make sense when counting from 1.
>>
>> What you typically see in Disk Management, is 1 3 4 5 6...
>> And partition 2 is the MSR. Partition 3 could be C:
>> Partition 4 could be the one used by ReagentC. If
>> you had a Partition 5 and Partition 6, they could be
>> deleted (as left-over versions of a Partition 4).
>>
>> Just make sure that anything to the right of the deletion,
>> does not rely upon a partition number for its operation.
>> For example, a Linux uses a partition number for the GRUB boot
>> sequence, even though "most of the time" Linux stuff relies on
>> UUID/blkid for identifiers, which tends to make Linux number-independent.
>> It's when GRUB is installed, that the jump from one phase of GRUB
>> to the next, happens to use a partition number. If you were dual
>> booting and screwed it up, the Linux "Boot Repair" package could fix it for you.
>>
>> When I had three of the Recovery Partitions to the right of C: , I did
>> delete two of them, but that was not on a Bitlockered PC. And I have
>> screwed up Linux booting, by removing a partition to the left of
>> Windows C: partition. In your situation, I don't think the odds
>> of damage are that high. But then, I don't understand what
>> the Bitlocker on a Home setup is doing, either :-) No idea.
>> It's supposed to be FDE, but it does not seem to be that.
>> I always thought FDE encrypted the entire drive, every byte of it.
>> It does not seem to be doing that.
>>
>> Paul
>
> Thanks, Paul,
>
> Diskpart lists the disks in this order:
>
>
> Microsoft DiskPart version 10.0.19041.3636
>
> Copyright (C) Microsoft Corporation.
> On computer: DESKTOP-4C4MNUB
>
> Disk 0 is now the selected disk.
>
> Partition ### Type Size Offset
> ------------- ---------------- ------- -------
> Partition 1 System 500 MB 1024 KB
> Partition 2 Reserved 128 MB 501 MB
> Partition 3 Primary 225 GB 629 MB
> Partition 6 Recovery 1101 MB 225 GB
> Partition 4 Recovery 10 GB 226 GB
> Partition 5 Recovery 1078 MB 237 GB
>
> (Output obtained from diskpart /s temp.txt | clip)
>
> Disk Management (graphic) shows them in the same order.

<sigh> :-) Classic partition renumbering goodness.

So does that mean the sequence is

reagentc /info
reagentc /disable

(remove partition 5, screw up partition order, 6 becomes some other partition number)

reagentc /setreimage <insert_renumbered_path_specification_here>
reagentc /enable
reagentc /info

or something.

I take it the 10GB partition is for some kind of OEM hardware-level recovery ?

Be careful.

Paul

On 3/17/2024 11:18 AM, Philip Herlihy wrote:
> In article <ut6btt$3ekrs$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...
>>
>> Philip Herlihy wrote on 3/16/24 1:22 PM:
>>> In article <ut2of9$2hmc1$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...
>>>>
>>>> Philip Herlihy wrote on 3/15/24 11:05 AM:
>>>>> In article <ustvec$1e302$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...
>>>>>>
>>>>>> Philip Herlihy wrote on 3/13/24 4:12 PM:
>>>>>>>
>>>>>>> The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
>>>>>>> 500MB EFI System partition
>>>>>>> 225GB OS
>>>>>>> 852MB now Unallocated after my meddling
>>>>>>> 10GB Recovery Partition
>>>>>>> 1GB Recovery Partition
>>>>>>>
>>> ...
>>>
>>> I've now completed all the steps in https://bit.ly/3TCu9Y8, disabling and re-
>>> enabling Bitlocker on either side. Everything seemed to work, and all commands
>>> gave positive status. The 'stuck' update is now safely installed. Thanks to
>>> everyone for help with this.
>>>
>>>
>>>>
>>>> Did you disable the the WinRE partition before deleting the WinRE partition?
>>>> - reagentc /disable
>>>> Did you verify the harddisk# and partition# of the WinRE recovery
>>>> partition before deleting the WinRE partition?
>>>> - reagentc /info
>>>
>>> YES
>>>
>>>>
>>>> If you disabled the WinRE partition before deletion, the necessaryt
>>>> winre.wim file will be located in C:\Windows\System32\Recovery
>>>> - you will need to configure File Explorer to see the file's presence
>>>> in the above folder
>>>> File Explorer/Options/View
>>>> - Enable 'Show hidden files, folders, and drives
>>>> - Uncheck 'Hide extensions of known file types'
>>>> - Uncheck 'Hide protected operating system files'
>>>>
>>>
>>> Well, it's not there now, though I have completed all the steps, including
>>> reagentc /enable, so from what you say winre.wim should have been moved to the
>>> newly re-created Recovery partition.
>>>
>>
>> Now would be a good time to verify it as present and determine the
>> current Service Pack Build number and last modified date
>>
>> Run reagentc /info and look for the harddisk# and partition#, then
>> replace the number in the following Powershell command, once done enter
>> the full now edited(with your harddisk and parition #'s) command line in
>> a Powershell admin window
>>
>> DISM /Get-ImageInfo
>> /ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
>> /index:1
>>
>> Once done, report five items from the output
>> Version, Service Pack Build, Service Pack Level, Created date, Modified
>> date.
>
> Details for image : \\?\GLOBALROOT\device\harddisk0\partition6\Recovery
> \WindowsRE\winre.wim
>
> Index : 1
> Name : Microsoft Windows Recovery Environment (x64)
> Description : Microsoft Windows Recovery Environment (x64)
> Size : 2,851,512,365 bytes
> WIM Bootable : No
> Architecture : x64
> Hal : <undefined>
> Version : 10.0.19041
> ServicePack Build : 3920
> ServicePack Level : 0
> Edition : WindowsPE
> Installation : WindowsPE
> ProductType : WinNT
> ProductSuite :
> System Root : WINDOWS
> Directories : 3789
> Files : 18630
> Created : 07/12/2019 - 07:11:48
> Modified : 15/03/2024 - 19:10:39
> Languages :
> en-US (Default)
> The operation completed successfully.
>
>

This is what I got on my Win10 one ('4441 succeeded).

File size seems a bit different.

Whereas the one for Win11 is from the year 2022.

D:\>DISM /Get-ImageInfo /ImageFile:D:\win10-winre.wim /index:1

Deployment Image Servicing and Management tool
Version: 10.0.22621.2792 <=== I'm using Win11 to check the version info

Details for image : D:\win10-winre.wim

Index : 1
Name : Microsoft Windows Recovery Environment (x64)
Description : Microsoft Windows Recovery Environment (x64)
Size : 2,419,893,284 bytes
WIM Bootable : No
Architecture : x64
Hal : <undefined>
Version : 10.0.19041 <=== It's a win10 WIM
ServicePack Build : 3920
ServicePack Level : 0
Edition : WindowsPE
Installation : WindowsPE
ProductType : WinNT
ProductSuite :
System Root : WINDOWS
Directories : 3748
Files : 17355
Created : 12/7/2019 - 3:11:48 AM
Modified : 1/14/2024 - 1:55:47 PM
Languages :
en-US (Default)
The operation completed successfully.

Paul

Philip Herlihy wrote on 3/17/24 8:31 AM:
> Diskpart lists the disks in this order:
>
> Microsoft DiskPart version 10.0.19041.3636
> Copyright (C) Microsoft Corporation.
> On computer: DESKTOP-4C4MNUB
>
> Disk 0 is now the selected disk.
>
> Partition ### Type Size Offset
> ------------- ---------------- ------- -------
> Partition 1 System 500 MB 1024 KB
> Partition 2 Reserved 128 MB 501 MB
> Partition 3 Primary 225 GB 629 MB
> Partition 6 Recovery 1101 MB 225 GB
> Partition 4 Recovery 10 GB 226 GB
> Partition 5 Recovery 1078 MB 237 GB
>
> (Output obtained from diskpart /s temp.txt | clip)
>
> Disk Management (graphic) shows them in the same order.
>
>
Previously you reported(in Disk Management)
The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition

You're Disk 0 list(from Diskpart) indicates you added 250 MB(to the
approx ~852 MB partition.)

Paul can possibly cover what would happen with partition numbering if the
old 10 GB and old 1078 MB were deleted.
- For the new WinRE to become partition #4 it might be necessary to
disable WinRE partition(reagentc /disable) before deleting the those
old(10 GB, 1078 MB), then once done, enable WinRE...but you would end up
with ~11GB unallocated at the end of the disk
=> or
Disable WinRE, delete the 3 partitions after the OS, then resize
C(larger leaving 1 or 2 GB unallocated) and recreate WinRE then enable WinRE.

Imo, wait until Paul comments further on next step.

--
....w¡ñ§±¤ñ

Philip Herlihy wrote on 3/17/24 8:18 AM:
> In article <ut6btt$3ekrs$1@dont-email.me>, ...w¡ñ§±¤ñ wrote...
>> Now would be a good time to verify it as present and determine the
>> current Service Pack Build number and last modified date
>>
>> Run reagentc /info and look for the harddisk# and partition#, then
>> replace the number in the following Powershell command, once done enter
>> the full now edited(with your harddisk and parition #'s) command line in
>> a Powershell admin window
>>
>> DISM /Get-ImageInfo
>> /ImageFile:\\?\GLOBALROOT\device\harddisk#\partition#\Recovery\WindowsRE\winre.wim
>> /index:1
>>
>> Once done, report five items from the output
>> Version, Service Pack Build, Service Pack Level, Created date, Modified
>> date.
>
> Details for image : \\?\GLOBALROOT\device\harddisk0\partition6\Recovery
> \WindowsRE\winre.wim
>
> Index : 1
> Name : Microsoft Windows Recovery Environment (x64)
> Description : Microsoft Windows Recovery Environment (x64)
> Size : 2,851,512,365 bytes
> WIM Bootable : No
> Architecture : x64
> Hal : <undefined>
> Version : 10.0.19041
> ServicePack Build : 3920
> ServicePack Level : 0
> Edition : WindowsPE
> Installation : WindowsPE
> ProductType : WinNT
> ProductSuite :
> System Root : WINDOWS
> Directories : 3789
> Files : 18630
> Created : 07/12/2019 - 07:11:48
> Modified : 15/03/2024 - 19:10:39
> Languages :
> en-US (Default)
> The operation completed successfully.
>
>
Congratulations!!!
Well done.

The numbers are exactly as they should be for Win10 22H2
Service Pack Build 3920 and the Modified date validate updating WinRE
partition and its content.

--
....w¡ñ§±¤ñ

In article <ut76q1$3kb52$1@dont-email.me>, Paul wrote...
>
> On 3/17/2024 11:31 AM, Philip Herlihy wrote:
> > In article <ut55o8$341m1$1@dont-email.me>, Paul wrote...
> >>
> >> On 3/16/2024 5:53 PM, Philip Herlihy wrote:
> >>> In article <MPG.40600faf8bed89c6989ab7@news.eternal-september.org>, Philip
> >>> Herlihy wrote...
> >>>>
....

> >
> > Diskpart lists the disks in this order:
> >
> >
> > Microsoft DiskPart version 10.0.19041.3636
> >
> > Copyright (C) Microsoft Corporation.
> > On computer: DESKTOP-4C4MNUB
> >
> > Disk 0 is now the selected disk.
> >
> > Partition ### Type Size Offset
> > ------------- ---------------- ------- -------
> > Partition 1 System 500 MB 1024 KB
> > Partition 2 Reserved 128 MB 501 MB
> > Partition 3 Primary 225 GB 629 MB
> > Partition 6 Recovery 1101 MB 225 GB
> > Partition 4 Recovery 10 GB 226 GB
> > Partition 5 Recovery 1078 MB 237 GB
> >
> > (Output obtained from diskpart /s temp.txt | clip)
> >
> > Disk Management (graphic) shows them in the same order.
>
> <sigh> :-) Classic partition renumbering goodness.
>
> So does that mean the sequence is
>
> reagentc /info
> reagentc /disable
>
> (remove partition 5, screw up partition order, 6 becomes some other partition number)
>
> reagentc /setreimage <insert_renumbered_path_specification_here>
> reagentc /enable
> reagentc /info
>
> or something.
>
> I take it the 10GB partition is for some kind of OEM hardware-level recovery ?
>
> Be careful.
>
> Paul

I think I'll leave well alone at this point!

--

Phil, London