https://www.techpowerup.com/ssd-specs/samsung-870-evo-1-tb.d3
Overprovisioning: 92.7 GB / 10.0 %
https://www.techpowerup.com/ssd-specs/samsung-870-evo-4-tb.d5
Overprovisioning: 370.7 GB / 10.0 %
Paul <nospam@needed.invalid> wrote:
https://www.techpowerup.com/ssd-specs/samsung-870-evo-1-tb.d3
Overprovisioning: 92.7 GB / 10.0 %
https://www.techpowerup.com/ssd-specs/samsung-870-evo-4-tb.d5
Overprovisioning: 370.7 GB / 10.0 %
I'd like to know where they got the OP spec. Can't find it mentioned at Samsung's site:
https://semiconductor.samsung.com/us/consumer-storage/internal-ssd/870evo/
Nor in the linked docs (datasheet, brochure). Samsung has their data
center SSD doc at:
http://semiconductor.samsung.com/resources/white-paper/S190311-SAMSUNG-Memory-Over-Provisioning-White-paper.pdf
What is OP (over-provisioning)?
Typically, Samsung DC SSDs are set to provide 6.7% of capacity for OP
by default, but the user can manually adjust the size of the space if
he or she requires additional OP depending on the user environment.
I guess you could figure out the factory OP space by computing the
difference between rated capacity and actual usable capacity (without
any partitioning, just what you could define in the usable space), as mentioned in the "How do I calculate the OP ratio?" section.
The article also mentions how having more OP space will provide a
performance boost to SSDs to allow for faster garbage collection, and
show a graph under the "What are the advantages of increasing OP?"
section, along with increased longevity with more OP space.
The article is for data center (DC) SSDs. I thought the drive makers allocated more factory OP for those, like 20% OP space (and 6.7% to 10%
for consumer SSDs) to accomodate the expectation by their enterprise customers of longer longevity and longer performance maintenance, but
not per Samsung's article. The folks I know as sysadmins increase OP
space to reduce failure rate, and try to maintain new-disk performance.
The SSDs are far more than big enough to afford losing a bit of space in
the OS/boot partition to accomodate for more OP space (as unallocated
space on the disk).
I suspect the TechPowerUp articles are just assuming what is the typical factory/inherent OP space instead of actually somehow measuring it. You
can always find out how much unallocated space there is on an SSD just
by using Disk Management (diskmgmt.msc), a 3rd-party partition manager,
or maybe even with diskpart, but those won't show the factory OP space
of which you will never have access. If they have a means of
interrogating the SSD's firmware to get at how big is the factory OP
space, I'd sure love to know what tool to use to find that out.
I'm trying to fix a 'stuck' Windows Update on a friend's (otherwise fully updated) Windows 10 laptop. It's the KB5034441. On my own machine I found I
could fix this by manually resizing the WinRE partition (something I know little about!) as described in KB5028997.
On my friend's laptop, it allowed me to delete the WinRE partition but wouldn't
allow me to recreate it. I understand that's because Bitlocker is running, and
that the operation should (!) succeed if it's suspended.
But the instructions I've found suggested to use a GUI Bitlocker console, and
that doesn't seem to offer the "suspend" option. I'm getting nervous, so I tried to back up the key. However, the printed output of that process invites
me to compare the "following identifier" with the one displayed on my PC. (Er,
where?) So I tracked down a Device ID for the computer (different) and I can't
find any property for the disk (including using Disk Management) which matches.
I'm astonished that in this day and age MS makes us chase down these rabbit- holes. For now, I'm left with anallocated space where the WinRE partion was and the update still won't install. Should i just wait for the next major update version? Any advice welcome!
Sorry about the lack of acknowledgement for these valuable responses. I've been really quite unwell. I'll get back to this when I'm recovered, which might be a good few days yet.
On 3/8/2024 1:10 PM, Philip Herlihy wrote:
Sorry about the lack of acknowledgement for these valuable responses. I've been really quite unwell. I'll get back to this when I'm recovered, which might be a good few days yet.
I'm sure everybody understands and hopes you get better soon!
Philip Herlihy <PhillipHerlihy@SlashDevNull.invalid> wrote:
I'm trying to fix a 'stuck' Windows Update on a friend's (otherwise fully updated) Windows 10 laptop. It's the KB5034441. On my own machine I found I
could fix this by manually resizing the WinRE partition (something I know little about!) as described in KB5028997.
On my friend's laptop, it allowed me to delete the WinRE partition but wouldn't
allow me to recreate it. I understand that's because Bitlocker is running, and
that the operation should (!) succeed if it's suspended.
But the instructions I've found suggested to use a GUI Bitlocker console, and
that doesn't seem to offer the "suspend" option. I'm getting nervous, so I
tried to back up the key. However, the printed output of that process invites
me to compare the "following identifier" with the one displayed on my PC. (Er,
where?) So I tracked down a Device ID for the computer (different) and I can't
find any property for the disk (including using Disk Management) which matches.
I'm astonished that in this day and age MS makes us chase down these rabbit-
holes. For now, I'm left with anallocated space where the WinRE partion was
and the update still won't install. Should i just wait for the next major update version? Any advice welcome!
Read the article for the "Instructions to manually resize your partition
to install the WinRE update" which points to:
https://support.microsoft.com/en-us/topic/kb5028997-instructions-to-manually-resize-your-partition-to-install-the-winre-update-400faa27-9343-461c-ada9-24c8229763bf
Yeah, like common users are expected to do all that techy shit. Does....
that look easy to you?
For now, decide if you really need the update.....
https://4sysops.com/wp-content/uploads/2023/06/Check-the-BitLocker-status-in-the-Control-Panel-applet.png
You don't see the "Suspend protection" option there?
Philip Herlihy wrote:
the instructions I've found suggested to use a GUI Bitlocker console, and that doesn't seem to offer the "suspend" option.
Try a command line method? In a cmd.exe window, started using the "as administrator" option, see if you can display the recovery key using
manage-bde -protectors -get C:
or suspend with
manage-bde -protectors -disable C:
Is this Home or Pro? (contrary to what is said, Home *can* use BitLocker
if it's an OEM factory install, if you were to totally disable it, you probably couldn't re-enable it again)
On 3/2/2024 10:59 AM, Philip Herlihy wrote:
I'm trying to fix a 'stuck' Windows Update on a friend's (otherwise fully updated) Windows 10 laptop. It's the KB5034441. On my own machine I found I
could fix this by manually resizing the WinRE partition (something I know little about!) as described in KB5028997.
On my friend's laptop, it allowed me to delete the WinRE partition but wouldn't
allow me to recreate it. I understand that's because Bitlocker is running, and
that the operation should (!) succeed if it's suspended.
But the instructions I've found suggested to use a GUI Bitlocker console, and
that doesn't seem to offer the "suspend" option. I'm getting nervous, so I
tried to back up the key. However, the printed output of that process invites
me to compare the "following identifier" with the one displayed on my PC. (Er,
where?) So I tracked down a Device ID for the computer (different) and I can't
find any property for the disk (including using Disk Management) which matches.
I'm astonished that in this day and age MS makes us chase down these rabbit-
holes. For now, I'm left with anallocated space where the WinRE partion was
and the update still won't install. Should i just wait for the next major update version? Any advice welcome!
If you're still having trouble, provide:
Make and model of hardware, and whether drive is an original image
Picture of Disk Management partitions
Version of OS (winver.exe is a start, but not very thorough as an identifier)
You can hand-draw ascii-art disk management info if you want.
If doesn't have to be a screenshot with snippingtool.exe .
Paul
In article <us19va$2d26r$1@dont-email.me>, Paul wrote...
On 3/2/2024 10:59 AM, Philip Herlihy wrote:
I'm trying to fix a 'stuck' Windows Update on a friend's (otherwise fully >>> updated) Windows 10 laptop. It's the KB5034441. On my own machine I found I
could fix this by manually resizing the WinRE partition (something I know >>> little about!) as described in KB5028997.
On my friend's laptop, it allowed me to delete the WinRE partition but wouldn't
allow me to recreate it. I understand that's because Bitlocker is running, and
that the operation should (!) succeed if it's suspended.
But the instructions I've found suggested to use a GUI Bitlocker console, and
that doesn't seem to offer the "suspend" option. I'm getting nervous, so I
tried to back up the key. However, the printed output of that process invites
me to compare the "following identifier" with the one displayed on my PC. (Er,
where?) So I tracked down a Device ID for the computer (different) and I can't
find any property for the disk (including using Disk Management) which matches.
I'm astonished that in this day and age MS makes us chase down these rabbit-
holes. For now, I'm left with anallocated space where the WinRE partion was
and the update still won't install. Should i just wait for the next major >>> update version? Any advice welcome!
If you're still having trouble, provide:
Make and model of hardware, and whether drive is an original image
Picture of Disk Management partitions
Version of OS (winver.exe is a start, but not very thorough as an identifier)
You can hand-draw ascii-art disk management info if you want.
If doesn't have to be a screenshot with snippingtool.exe .
Paul
Thanks Paul - and everyone who's contributed.
Notwithstanding the excursions about WinRE (95% of which went over my head) I
think I've got the gist of this now.
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 used manage-bde to list the Bitlocker Key (and ID) and I have a copy on another machine. There are two accounts on the laptop, both Local, and the Key/ID come out the same in both (just a sanity check!). A TPM ID is also listed, but that presumably is a constant for this machine.
I need to resize the partitions and re-create the WinRE partition in the Unallocated space. To do this, I can suspend (not disable) Bitlocker using the
manage-bde command with -disable and -enable arguments, I understand.
Any gotchas in that? And should I delete the other two Recovery Partitions before recreating the WinRE partition (same things, right?).
Phew! I'm getting to old for this s***, especially after a couple of weeks of
fever...
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 need to resize the partitions and re-create the WinRE partition in the Unallocated space. To do this, I can suspend (not disable) Bitlocker using the
manage-bde command with -disable and -enable arguments, I understand.
Any gotchas in that? And should I delete the other two Recovery Partitions before recreating the WinRE partition (same things, right?).
Phew! I'm getting to old for this s***, especially after a couple of weeks of
fever...
In article <us19va$2d26r$1@dont-email.me>, Paul wrote...
On 3/2/2024 10:59 AM, Philip Herlihy wrote:
I'm trying to fix a 'stuck' Windows Update on a friend's (otherwise fully >>> updated) Windows 10 laptop. It's the KB5034441. On my own machine I found I
could fix this by manually resizing the WinRE partition (something I know >>> little about!) as described in KB5028997.
On my friend's laptop, it allowed me to delete the WinRE partition but wouldn't
allow me to recreate it. I understand that's because Bitlocker is running, and
that the operation should (!) succeed if it's suspended.
But the instructions I've found suggested to use a GUI Bitlocker console, and
that doesn't seem to offer the "suspend" option. I'm getting nervous, so I
tried to back up the key. However, the printed output of that process invites
me to compare the "following identifier" with the one displayed on my PC. (Er,
where?) So I tracked down a Device ID for the computer (different) and I can't
find any property for the disk (including using Disk Management) which matches.
I'm astonished that in this day and age MS makes us chase down these rabbit-
holes. For now, I'm left with anallocated space where the WinRE partion was
and the update still won't install. Should i just wait for the next major >>> update version? Any advice welcome!
If you're still having trouble, provide:
Make and model of hardware, and whether drive is an original image
Picture of Disk Management partitions
Version of OS (winver.exe is a start, but not very thorough as an identifier)
You can hand-draw ascii-art disk management info if you want.
If doesn't have to be a screenshot with snippingtool.exe .
Paul
Thanks Paul - and everyone who's contributed.
Notwithstanding the excursions about WinRE (95% of which went over my head) I
think I've got the gist of this now.
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 used manage-bde to list the Bitlocker Key (and ID) and I have a copy on another machine. There are two accounts on the laptop, both Local, and the Key/ID come out the same in both (just a sanity check!). A TPM ID is also listed, but that presumably is a constant for this machine.
I need to resize the partitions and re-create the WinRE partition in the Unallocated space. To do this, I can suspend (not disable) Bitlocker using the
manage-bde command with -disable and -enable arguments, I understand.
Any gotchas in that? And should I delete the other two Recovery Partitions before recreating the WinRE partition (same things, right?).
Phew! I'm getting to old for this s***, especially after a couple of weeks of
fever...
On 3/13/2024 7:12 PM, Philip Herlihy wrote:
The machine is a Dell XPS 13. Partitions (in Disk Management) are (rounded):holes. For now, I'm left with anallocated space where the WinRE partion was
500MB EFI System partition
225GB OS
852MB now Unallocated after my meddling
10GB Recovery Partition
1GB Recovery Partition
I need to resize the partitions and re-create the WinRE partition in the
Unallocated space.
You should be doing these things in "priority order" :-)
1) Suspend bitlocker.
2) Try the WinRE creation script.
It's perhaps the request to generate a partition with
a certain partition ID type, that causes diskpart to
think "this should really be placed to the right of C: "
and that's how it managed to auto-magically get the
partition number correct during this sequence. Otherwise,
deleting a partition, a newly created partition
would end up somewhere on the right.
Another way to do this, would be with
Macrium, a restore of the missing partition.
Assuming a backup is/was available.
The former information only to ensure the location(disk and partitionnumbers of the o/s and WinRE partition) are known in advance to ensure
The latter, especially important since the 'disable' ensures Winre.wimis moved to C:\Windows\Recovery.
Remember that you have two objectives:
1) Achieve WinRE enabled again (a kind of proof that
maybe it might work when called upon).
The latter, especially important since the 'disable' ensures Winre.wimis moved to **C:\Windows\Recovery**
ÿWhy: If not disabled and **Winre.wim moved**, then Winre.wim must be obtained from some other place(ISO, backup)
ÿ - reagentc /enable needs to move winre.wim to the created partition
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 need to resize the partitions and re-create the WinRE partition in the Unallocated space. To do this, I can suspend (not disable) Bitlocker using the
manage-bde command with -disable and -enable arguments, I understand.
Any gotchas in that? And should I delete the other two Recovery Partitions before recreating the WinRE partition (same things, right?).
Phew! I'm getting to old for this s***, especially after a couple of weeks of
fever...
Without knowing which Recovery partition you changed..let's back up
Did you use an admin Command or Powershell console to run/execute:
1. reagentc /info
- to determine the active WinRE partition
2. reagentc /disable
- to disable the active recovery partition
3. Is the unallocated space after the o/s partition previously the active then later disabled before deleting the recovery partition?
If the unallocated space was the old, no longer present active recovery partition, the shrink C by 172 MB then create WinRE as a 1024 MB partition.
- use Diskpart for the above
- in advance, ensure you know the o/s harddisk # because you need to select the correct disk to shrink c and create the new WinRE partition on the same disk in that unallocated space(after the o/s partition)
If you need the steps to do so reply for more detailed help.
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 need to resize the partitions and re-create the WinRE partition in the >>> Unallocated space. To do this, I can suspend (not disable) Bitlocker using the
manage-bde command with -disable and -enable arguments, I understand.
Any gotchas in that? And should I delete the other two Recovery Partitions >>> before recreating the WinRE partition (same things, right?).
Phew! I'm getting to old for this s***, especially after a couple of weeks of
fever...
Without knowing which Recovery partition you changed..let's back up
Did you use an admin Command or Powershell console to run/execute:
1. reagentc /info
- to determine the active WinRE partition
2. reagentc /disable
- to disable the active recovery partition
3. Is the unallocated space after the o/s partition previously the active
then later disabled before deleting the recovery partition?
If the unallocated space was the old, no longer present active recovery
partition, the shrink C by 172 MB then create WinRE as a 1024 MB partition. >> - use Diskpart for the above
- in advance, ensure you know the o/s harddisk # because you need to
select the correct disk to shrink c and create the new WinRE partition on
the same disk in that unallocated space(after the o/s partition)
If you need the steps to do so reply for more detailed help.
I'm ready to tackle this now, using the steps listed here: https://bit.ly/3TCu9Y8
I've successfully backed-up all the data on the machine, and copied it to a new
machine (the present machine had been regarded as "broken" until I fixed it!).
If anything goes wrong, I should be able to reset or even reload it, and I won't hesitate to do that if needed.
Previously I'd tried the 'shrink' command but that didn't succeed (presumably because of Bitlocker). I did go on to delete the WinRE partition, which is the
one immediately following the OS partition, but didn't get any further. Now I'm confident I have the correct Bitlocker key (saved elsewhere!) and a copy of
all the data, so I think the worst that can happen is that I have to reload Windows from scratch.
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
In article <MPG.405e9e5633ff3813989ab5@news.eternal-september.org>, Philip Herlihy wrote...
...
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
There's another glitch with this machine. The user (not content with transporting the machine with the power plug inserted and banging hell out of
the power socket - repaird) has evidently left it plugged in 24/7 (when not bouncing it off door-frames). So the battery has about 90s life in it from an
indicated 100% charge.
I've realised that unless it's left "on charge" for many minutes then when it's
logged-in the "Critical Power" event kicks in (at 2%) and hibernates the thing.
I turned that off, but then decided it was safer to leave that mechanism in place to avoid possible corruption. But I'd like to increase the 'Critical' level from 2% to (maybe?) 7%. I find the Control Panel applet simply ignores
attempted changes, and I have to use powercfg with some GUID weirdness to achieve this. As I said, I'm getting too old for this s***...
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
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
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'
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?
Please answer the questions(and advance thanks for doing so)
On 3/16/2024 6:24 AM, Philip Herlihy wrote:
In article <MPG.405e9e5633ff3813989ab5@news.eternal-september.org>, Philip Herlihy wrote...
...
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
There's another glitch with this machine. The user (not content with transporting the machine with the power plug inserted and banging hell out of
the power socket - repaird) has evidently left it plugged in 24/7 (when not
bouncing it off door-frames). So the battery has about 90s life in it from an
indicated 100% charge.
I've realised that unless it's left "on charge" for many minutes then when it's
logged-in the "Critical Power" event kicks in (at 2%) and hibernates the thing.
I turned that off, but then decided it was safer to leave that mechanism in
place to avoid possible corruption. But I'd like to increase the 'Critical'
level from 2% to (maybe?) 7%. I find the Control Panel applet simply ignores
attempted changes, and I have to use powercfg with some GUID weirdness to achieve this. As I said, I'm getting too old for this s***...
There is mention here, that the schema can be reset, and maybe
after that you could try again to set it.
https://superuser.com/questions/1341383/how-to-stop-computer-from-entering-sleep-under-critical-battery-trigger-met-mi
There is also a picture of the settings section, in the article.
Since the field can be set to weird values, it almost implies
somehow that this is adaptive ? And adjusts itself ? Otherwise,
how would one individual report his was set to 86%.
https://i.stack.imgur.com/I93RH.png
There is a chip inside the battery pack, which at a minimum
contains a tiny flash memory. And the charge history of the
pack is recorded in there. The OS reads the chip when the
OS boots, and it keeps the table in RAM, and writes it back
out at some point. And since the chip has a "serial number",
this allows the battery pack itself, to carry a summary
of its life history. One of the parameters, is how many
charge cycles it has gone through.
Some laptops, have a charge controller (chip on laptop mobo)
that can be set to "only charge to 80%" and this significantly
reduces the impact on the battery from the "user plugs in
24/7" case. That hasn't always been there, so not all laptops
have that. The setting may be in a separate application,
added to the C: drive.
What it's doing, is removing Phase 2 from the
battery charge process. The charger only does CC to get
to 80%, instead of the CC-CV to get to 100%. The CV or
Constant Voltage phase is known as "topping up" and squeezes
the last bit of charge into the battery, from 80% to 100%.
The time spent at 100% charge (or 4.2V per cell), is what
damages the pack. Once at 100% and the charger has switched
off, the battery starts to relax at that point, and drops
back to 3.7V on its own. Car batteries behave a bit like
that too. In terms of relaxing. One difference is, you
can "float" a car battery at 13.5V instead of allowing it
to relax to 12.6V or so, whereas you cannot float a Lithium
cell. When a lithium cell is full, it's full.
The lithium cell would have to drop significantly, before
another charge cycle starts. The charger cannot start at
3.7V, because the pack is still full at that point. It
would need a bit of hysteresis and maybe start charging
again at 3.5V or so. Even if sleeping, it should not
be "on-charge" constantly, and it should be taking
a break once in a while. But the number of charge cycles,
if left plugged in, it still probably quite high.
Paul
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?
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?
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.
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.
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
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.
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.
DISM /Get-ImageInfo /ImageFile:D:\win10-winre.wim /index:1
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.
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.
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
| Sysop: | Tetrazocine |
|---|---|
| Location: | Melbourne, VIC, Australia |
| Users: | 7 |
| Nodes: | 8 (0 / 8) |
| Uptime: | 145:52:39 |
| Calls: | 46 |
| Files: | 21,492 |
| Messages: | 65,323 |
