-------- 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 :-)

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.

Paul

On 2024-12-25 18:08, Paul wrote:

....

> 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 portion at the end. Could be a large
portion at the end, and then shift everything a cylinder or two.

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.

--
Cheers, Carlos.

On Wed, 12/25/2024 1:26 PM, Carlos E.R. wrote:
> On 2024-12-25 18:08, Paul wrote:
>
> ...
>
>> 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 portion at the end. Could be a large portion at the end, and then shift everything a cylinder or two.
>
> 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.
>

Partition Magic was acquired by someone else.

The Partition Magic developers were pretty careful. They enforced
all sorts of rules for which there was no reason to enforce them :-)
And doing that, reduced the number of test cases they would need
to run. It was a case of "you can't do this, and you can't do that".
Your operations then, had to align with whatever rules they
had cooked up.

Paul

Paul <nospam@needed.invalid> writes:

[...]

>>   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

That's some pretty serious stuff. :) Thanks for showing.

On 12/25/24 12:08 PM, Paul wrote:
> 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.

186282@ud0s4.net wrote this post while blinking in Morse code:

> 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.

I can develope my apps in Linux, then boot to Windows to fix any issues that
occur on that platform.

Also, you can have a useable Linux system in 64 Gb. Mine has a lot of software,
about 30 Gb for a Win 10 VM, and about 27 Gb worth of music, etc.

/dev/sda5 349G 124G 208G 38% /

The mini PC is one of the cheaper models from Trycoo. For my usage, its speed
is quite sufficient. And all for a price not much more than a standalone
Windows license.

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Address sizes: 39 bits physical, 48 bits virtual
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Vendor ID: GenuineIntel
Model name: Intel(R) N100
CPU family: 6
Model: 190
Thread(s) per core: 1
Core(s) per socket: 4

--
narcolepulacyi, n.:
The contagious action of yawning, causing everyone in sight
to also yawn.
-- "Sniglets", Rich Hall & Friends

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.

--
Cheers, Carlos.

On Thu, 12/26/2024 8:30 AM, Carlos E.R. wrote:
> 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.
>
1 2 3 4
+----+----+-----+----+------------+--------------------------+ - - - ---------+---------------+
|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.

Paul

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.

On 2024-12-26 16:48, Paul wrote:
> On Thu, 12/26/2024 8:30 AM, Carlos E.R. wrote:
>> 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.
>>
> 1 2 3 4
> +----+----+-----+----+------------+--------------------------+ - - - ---------+---------------+
> |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.

Thanks, interesting writeup :-)

--
Cheers, Carlos.

On Thu, 12/26/2024 3:49 PM, Lawrence D'Oliveiro wrote:
> 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.
>

I don't understand what Microsoft is doing about this.

This all started as a CVE and an exploit somehow involving
SafeOS emergency boot. The response then, is changing something
on the fly, to cover off the CVE issue.

Microsoft makes tiny efforts, but it's not straining itself.
Some aspects of the implementation, are highly inappropriate.

When Win10 tries to update the emergency boot OS (SafeOS),
it puts a fail message in the update history. The error number
is wrong and meaningless. Users are freaking out at the complexity
of the recipe, and the mixing up of an "IT guy" article,
for "home user" usage.

When Win11 tries the same thing, if a failure happens,
we're not seeing a notation.

I can fix it right now, except for two things.

1) There's no button to click, to kick off the update.
We don't know which Cumulative or special-case install,
the thing is inside. When the SafeOS update is successful,
the Update.wim disappears from its prep area.

2) There is no notation to tell one is pending.
You can check C:\$WinREAgent\Scratch and see
if an Update.wim is in there. That's how I noticed I
have one pending. I also know what "thing" I changed
in Windows, that stopped it. I have New Compression turned
off, to improve Linux access to C: issues :-) And the
compression phase of making the Update.wim is blocked by
my "Linux convenience" setting. But I know this, and can
temporarily modify it to un-gate the update. What I can't
know, is when the "quiet approach" will make another attempt.
It's queued. It will happen. But when ?

C:\$WinREAgent\Scratch\Update.wim Tues, ‎Dec ‎10, ‎2024, ‏‎11:29 PM (Patch Tuesday)

There are multiple failure mechanisms for one of these to fail.
I have not described all of them above. That's just a simplified
version to describe the "atmosphere" around the activity.

Paul