Please followup-To alt.comp.os.windows-10. (Note this is not just a
Windows question, but I believe the Windows newsgroup is more
appropriate: perhaps there are other system's shrinking tool that could
help me here. Thanks for any ideas.)
I'm interested in installing a new operating system. Haven't decided
which yet---perhaps FreeBSD, perhaps GNU Guix. I've got 195 GiB free in
my c: drive plus 655 MiB unallocated which I was able to get from
shrinking the c: drive using the Windows 10 Disk Management tool.
Disk Management (how my storage looks right now)
https://prnt.sc/WZ1fF5S9ARJ1
Disk Management is not able to shrink more. It says it has been done
what it could with those 655 MiB.
https://prnt.sc/ez9O5JUVUVXv
I turned hibernation off, restarted and tried again. Same thing.
Looking at the defrag event in the application log, I find:
--8<-------------------------------------------------------->8---
A volume shrink analysis was initiated on volume (C:). This event log
entry details information about the last unmovable file that could limit
the maximum number of reclaimable bytes.
Diagnostic details:
- The last unmovable file appears to be: \System Volume
Information\{fba11b84-afde-11ef-adfe-48684ad40403}{3808876b-c176-4e48-b7ae-04046e6cc752}::$DATA
- The last cluster of the file is: 0x76e787e
- Shrink potential target (LCN address): 0x466119b
- The NTFS file flags are: ---AD
- Shrink phase: <analysis>
To find more details about this file please use the "fsutil volume
querycluster \\?\Volume{f5e639db-a758-4dfa-9804-d5d4d0286fb7}
0x76e787e" command. --8<-------------------------------------------------------->8---
Using the fsutil command, I get:
--8<-------------------------------------------------------->8--- C:\Windows\system32>fsutil volume querycluster \\?\Volume{f5e639db-a758-4dfa-9804-d5d4d0286fb7} 0x76e787e
Cluster 0x00000000076e787e used by ---AD \System Volume Information\{fba11b84-afde-11ef-adfe-48684ad40403}{3808876b-c176-4e48-b7ae-04046e6cc752}::$DATA
--8<-------------------------------------------------------->8---
Anything else I could try? I have not tried to use other system's
shrinking programs. Could they do a better job? Perhaps this is not
the best newsgroup to ask this question.
-------- Forwarded Message --------
From: 23 2024 <>
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys: Subject: Re: shrink drive c: to install a new operating system
Newsgroups: alt.comp.os.windows-10
References: <87r05wvnj2.fsf@example.com>
From: 186282@ud0s4.net <186283@ud0s4.net>
Organization: wokiesux
Date: Tue, 24 Dec 2024 20:11:22 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87r05wvnj2.fsf@example.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
On 12/24/24 3:22 PM, Salvador Mirzo wrote:
Please followup-To alt.comp.os.windows-10. (Note this is not just a
Windows question, but I believe the Windows newsgroup is more
appropriate: perhaps there are other system's shrinking tool that could
help me here. Thanks for any ideas.)
I'm interested in installing a new operating system. Haven't decided
which yet---perhaps FreeBSD, perhaps GNU Guix. I've got 195 GiB free in
my c: drive plus 655 MiB unallocated which I was able to get from
shrinking the c: drive using the Windows 10 Disk Management tool.
Disk Management (how my storage looks right now)
https://prnt.sc/WZ1fF5S9ARJ1
Disk Management is not able to shrink more. It says it has been done
what it could with those 655 MiB.
https://prnt.sc/ez9O5JUVUVXv
I turned hibernation off, restarted and tried again. Same thing.
Looking at the defrag event in the application log, I find:
--8<-------------------------------------------------------->8---
A volume shrink analysis was initiated on volume (C:). This event log
entry details information about the last unmovable file that could limit
the maximum number of reclaimable bytes.
Diagnostic details:
- The last unmovable file appears to be: \System Volume
Information\{fba11b84-afde-11ef-adfe-48684ad40403}{3808876b-c176-4e48-b7ae-04046e6cc752}::$DATA
- The last cluster of the file is: 0x76e787e
- Shrink potential target (LCN address): 0x466119b
- The NTFS file flags are: ---AD
- Shrink phase: <analysis>
To find more details about this file please use the "fsutil volume
querycluster \\?\Volume{f5e639db-a758-4dfa-9804-d5d4d0286fb7}
0x76e787e" command.
--8<-------------------------------------------------------->8---
Using the fsutil command, I get:
--8<-------------------------------------------------------->8---
C:\Windows\system32>fsutil volume querycluster \\?\Volume{f5e639db-a758-4dfa-9804-d5d4d0286fb7} 0x76e787e
Cluster 0x00000000076e787e used by ---AD \System Volume
Information\{fba11b84-afde-11ef-adfe-48684ad40403}{3808876b-c176-4e48-b7ae-04046e6cc752}::$DATA
--8<-------------------------------------------------------->8---
Anything else I could try? I have not tried to use other system's
shrinking programs. Could they do a better job? Perhaps this is not
the best newsgroup to ask this question.
Winders can make a kind of a mess out of "C:" with
'unmovable' files and 'recovery' stuff kinda scattered
all around.
If you are using a desktop then just install another
HDD and use that. Some laptops have a socket for another
m12 card or similar. "-ix' systems are much smaller than
Winders, so you don't need a huge second drive.
Otherwise, if even gparted or the 'Acronis' version
for your existing HDD won't straighten it out there's
little choice but to back up, manually format the
disk with gparted into two distinct partitions and
re-install Winders. Not terribly attractive ...
I've wondered if the Win scheme is a subtle form of
Bill "linux-proofing" PCs :-)
It's the same anywhere, YOU test the quality in, because
people you cannot see, may or may not care all that much.
In the previous paragraphs, are two diametrically opposed results.
Careful developers and... the other kind.
If you use a third party tool, it can take part time testing
for months, to conclude what kind of developers they were.
On 2024-12-25 18:08, Paul wrote:portion at the end. Could be a large portion at the end, and then shift everything a cylinder or two.
...
It's the same anywhere, YOU test the quality in, because
people you cannot see, may or may not care all that much.
In the previous paragraphs, are two diametrically opposed results.
Careful developers and... the other kind.
If you use a third party tool, it can take part time testing
for months, to conclude what kind of developers they were.
The first time I shrinked a partition was in 1998. Back then, you needed a small partition before the 1024 cylinder, but could be a tiny one, used for /boot. So sometimes you needed to shrink a bit the beginning of the Windows partition, then a large
The limitation came because the BIOS could not read beyond the 1024 cylinder or something like that.
I used, I think, Partition Magic in Windows. Is this tool still around?
Things are easier now.
I've wondered if the Win scheme is a subtle form of
Bill "linux-proofing" PCs :-)
You worry too much :-) Windows and Linux live in complete harmony.
I just shrank a C: partition down to the minimal size.
Nothing stands in my way. To do it, I need storage space.
Either for a Macrium backup (.mring) or space for a clone-with-shrink.
[Picture]
https://i.postimg.cc/52DsrbVW/Shrinking-With-Backup-Clone-Software.gif
On Tue, 12/24/2024 8:12 PM, 186282@ud0s4.net wrote:
-------- Forwarded Message --------
From: 23 2024 <>
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys: Subject: Re: shrink drive c: to install a new operating system
Newsgroups: alt.comp.os.windows-10
References: <87r05wvnj2.fsf@example.com>
From: 186282@ud0s4.net <186283@ud0s4.net>
Organization: wokiesux
Date: Tue, 24 Dec 2024 20:11:22 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <87r05wvnj2.fsf@example.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
On 12/24/24 3:22 PM, Salvador Mirzo wrote:
Please followup-To alt.comp.os.windows-10. (Note this is not just a
Windows question, but I believe the Windows newsgroup is more
appropriate: perhaps there are other system's shrinking tool that could
help me here. Thanks for any ideas.)
I'm interested in installing a new operating system. Haven't decided
which yet---perhaps FreeBSD, perhaps GNU Guix. I've got 195 GiB free in >>> my c: drive plus 655 MiB unallocated which I was able to get from
shrinking the c: drive using the Windows 10 Disk Management tool.
Disk Management (how my storage looks right now)
https://prnt.sc/WZ1fF5S9ARJ1
Disk Management is not able to shrink more. It says it has been done
what it could with those 655 MiB.
https://prnt.sc/ez9O5JUVUVXv
I turned hibernation off, restarted and tried again. Same thing.
Looking at the defrag event in the application log, I find:
--8<-------------------------------------------------------->8---
A volume shrink analysis was initiated on volume (C:). This event log
entry details information about the last unmovable file that could limit >>> the maximum number of reclaimable bytes.
Diagnostic details:
- The last unmovable file appears to be: \System Volume
Information\{fba11b84-afde-11ef-adfe-48684ad40403}{3808876b-c176-4e48-b7ae-04046e6cc752}::$DATA
- The last cluster of the file is: 0x76e787e
- Shrink potential target (LCN address): 0x466119b
- The NTFS file flags are: ---AD
- Shrink phase: <analysis>
To find more details about this file please use the "fsutil volume >>> querycluster \\?\Volume{f5e639db-a758-4dfa-9804-d5d4d0286fb7}
0x76e787e" command.
--8<-------------------------------------------------------->8---
Using the fsutil command, I get:
--8<-------------------------------------------------------->8---
C:\Windows\system32>fsutil volume querycluster \\?\Volume{f5e639db-a758-4dfa-9804-d5d4d0286fb7} 0x76e787e
Cluster 0x00000000076e787e used by ---AD \System Volume
Information\{fba11b84-afde-11ef-adfe-48684ad40403}{3808876b-c176-4e48-b7ae-04046e6cc752}::$DATA
--8<-------------------------------------------------------->8---
Anything else I could try? I have not tried to use other system's
shrinking programs. Could they do a better job? Perhaps this is not
the best newsgroup to ask this question.
Winders can make a kind of a mess out of "C:" with
'unmovable' files and 'recovery' stuff kinda scattered
all around.
If you are using a desktop then just install another
HDD and use that. Some laptops have a socket for another
m12 card or similar. "-ix' systems are much smaller than
Winders, so you don't need a huge second drive.
Otherwise, if even gparted or the 'Acronis' version
for your existing HDD won't straighten it out there's
little choice but to back up, manually format the
disk with gparted into two distinct partitions and
re-install Winders. Not terribly attractive ...
I've wondered if the Win scheme is a subtle form of
Bill "linux-proofing" PCs :-)
You worry too much :-) Windows and Linux live in complete harmony.
I just shrank a C: partition down to the minimal size.
Nothing stands in my way. To do it, I need storage space.
Either for a Macrium backup (.mring) or space for a clone-with-shrink.
[Picture]
https://i.postimg.cc/52DsrbVW/Shrinking-With-Backup-Clone-Software.gif
While the Disk Management has overly conservative usage of the
Defrag API that prevents perfect control, not every software
developer has a limited imagination.
And the evidence of skill and the usage of Test Benches by the
external developers, comes from their bug rate. Which for Macrium,
is damn close to zero.
When I bought Acronis Disk Doctor, the very
first test I did caused a corruption. Macrium does not do
stuff like that. Acronis though, it promised to change cluster
size on an NTFS volume. I looked at this and said "No, you
can't do that". Well, I tested, and they *almost* pulled
it off, except some of my System32 files had zero size after
it was finished. A kind of "dumpster fire". I had a backup before
testing the only "stretch" feature the tool had, and I was not
really all that surprised at the result.
It's the same anywhere, YOU test the quality in, because
people you cannot see, may or may not care all that much.
In the previous paragraphs, are two diametrically opposed results.
Careful developers and... the other kind.
If you use a third party tool, it can take part time testing
for months, to conclude what kind of developers they were.
Things like Acronis and Macrium ... I've had many successes
AND a few 'dumpster fires'. Sorry, nothing's perfect for every
possible need.
To clear space for Linux, do a FULL backup of yer Win
partition, format/partition the HDD, then use the
restore options to 'make it fit' the now-smaller
Win partition. This USUALLY works.
In any case, it's NOT as easy as in the 'old days' - and
I still suspect that's intentional.
IF possible, the secondary disk really IS the easiest
way to go. Even 250gb is usually more than enough for
most any sane -IX distro to work with unless you're
storing huge videos locally.
Hmmm, I recently bought a mini PC with Win 11. I booted to Windows, immediately used the built-in Disk Manager to shrink the Windows
partition. Then I installed Debian.
Pretty straightforward.
On 2024-12-26 13:32, Chris Ahlstrom wrote:
Hmmm, I recently bought a mini PC with Win 11. I booted to Windows,
immediately used the built-in Disk Manager to shrink the Windows
partition. Then I installed Debian.
Pretty straightforward.
This is the best method. Do the shrinking as soon as you buy the machine. Or, at Windows install time.
The Recovery Partition has SafeOS in it, a WinRE.wim file . On
Windows 10, the updates can fail on that, due to poor handling
technique by Microsoft. The Windows 11 updates are more coy about
the mess, and I can see signs for example, an update is queued to go
into the 600MB partition, but the attempt to update the item is
failing (...quietly).
On Thu, 12/26/2024 8:30 AM, Carlos E.R. wrote:
On 2024-12-26 13:32, Chris Ahlstrom wrote:1 2 3 4 +----+----+-----+----+------------+--------------------------+ - - - ---------+---------------+
Hmmm, I recently bought a mini PC with Win 11. I booted to Windows,
immediately used the built-in Disk Manager to shrink the Windows
partition. Then I installed Debian.
Pretty straightforward.
This is the best method. Do the shrinking as soon as you buy the machine. Or, at Windows install time.
|MBR |GPT | ESP |MSR | W11 C: | Recovery Partition 600MB | unallocated | secondary GPT |
+----+----+-----+----+------------+--------------------------+ - - - ---------+---------------+
^
+--------- Windows Disk Management does not show the MSR 16MB (a NoFS)
For a Linux user, one of the recommendations is to change
the EFI from 100MB FAT32 to 500MB FAT32.
But for gparted, the MSR acts as a "blocker", because gparted
expects to inspect any partition and check the partition file system integrity
and the MSR has no recognizable file system.
If you ignore that recommendation, the Linux install should still work.
It might have been someone at Ubuntu that recommended a 500MB ESP.
The Recovery Partition has SafeOS in it, a WinRE.wim file . On Windows 10, the updates can fail on that, due to poor handling technique by Microsoft. The Windows 11 updates are more coy about the mess, and I can see signs
for example, an update is queued to go into the 600MB partition, but
the attempt to update the item is failing (...quietly). If you bump the Recovery Partition up to 1500MB, that leaves room for the worst case
handling behavior of the update.
The end result then, your disk could look like this (EFI not changed).
1 2 3 4 5 +----+----+-----+----+-------+-------------------------------------------=---------------+
|MBR |GPT | ESP |MSR | W11 C:| RP 1500MB | Debian slash | secondary GPT |
+----+----+-----+----+-------+-------------------------------------------=---------------+
a machine that ships with Windows 11 on it, the ACPI MSDM table should have the license key. You would not have to buy another key. While older machines had a COA sticker, the license key in ACPI MSDM is your proof of purchase. License keys on the Internet are maybe $25. Some people have experimented with the cheap keys, and the keys "have not tipped over". That's for stuff like Home or Pro.
If you were Secure Booting (and who would be doing that!), you can do
the Windows Updates first, and have some certificate ending in 2011,
replaced with a certificate ending in 2023.
In an Administrator Powershell, you can run this and it should return True
if the necessary modification has been done. (The signed shim on a recent Debian, is more likely to align with this 2023 thing.)
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match ‘Windows UEFI CA 2023’
If you weren't secure Booting, it would not particularly matter.
If you perform activities such as "reset TPM to factory keys", then you
may end up installing another copy of Windows 11 (but only long enough
to re-install UEFI CA 2023). Then the excess Windows 11 partition could
be removed. That's what I did on the Secure Boot test machine to bring it
up to date, before pouring in the Linux.
*******
To reduce the size of Win11, you can
Admin terminal: powercfg /h off # Delete hiberfil.sys , can no longer hibernate
Admin terminal: sysdm.cpl Advanced : Performance (Settings) : Advanced : Virtual Memory (Change)
You can reduce the virtual memory using "Custom size 1024 1024"
On the next reboot, the pagefile.sys in the C: partition root area
should be 1024MB.
After this, you can shrink your C: partition down. move the Recovery Partition over,
and put Debian on the end.
On Thu, 26 Dec 2024 10:48:16 -0500, Paul wrote:
The Recovery Partition has SafeOS in it, a WinRE.wim file . On
Windows 10, the updates can fail on that, due to poor handling
technique by Microsoft. The Windows 11 updates are more coy about
the mess, and I can see signs for example, an update is queued to go
into the 600MB partition, but the attempt to update the item is
failing (...quietly).
This is why they say, Windows is a great OS ... if your time is worth nothing.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 508 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 238:44:31 |
| Calls: | 9,985 |
| Calls today: | 3 |
| Files: | 13,836 |
| Messages: | 6,358,296 |
