3

I have an issue where brand new installations, both minutes old and weeks old of Big Sur and Monterey (not tried other major releases) are writing exactly 32GB of data to the SSD boot drive during boot, on every single boot.

I boot the machine (2017 5K iMac 64GB RAM (4x16GB)) and there's a delay during the boot progress bar for around 40 seconds. When booted I check Activity Monitor and it shows what appears to be 32GB+the usual 0.2GB to 0.3GB of typical boot writes and a couple of GB of reads.

I've had it once during a verbose boot (Cmd+V) behaves normally, takes seconds to boot, and shows .2 to .3GB of writes and the usual ~2GB reads to get to the desktop, but I've been unable to replicate this.

I've looked through the console logs trying to find a pause of 40~ seconds between log entries but can't find it.

It seems odd it's writing 32GB of data, it seems to be written to /dev/null because there's no trace of any space being used and no files of 1GB+ on the boot volume.

What could this be and what can I try next to troubleshoot this issue?

This happens with or without FileVault enabled and doesn't affect the performance of the machine in any way once booted.

Storage is the internal PCI 3.0 X4 128GB blade SSD.

The first screenshot shows that powerd is writing the data. The second screenshot shows a safe boot screenshot and the third is a normal boot after a safe boot.

Screenshot of Activity Monitor showing 'powerd' process is writing data

Screenshot of Activity Monitor showing 'powerd' process after a safe boot

Screenshot of Activity Monitor showing 'powerd' process after a normal boot

Screenshot of NCDU output

Another screenshot of NCDU output

Screenshot of a Terminal window showing 'pmset -g' output

6
  • Check whether it does it in Safe Boot mode.
    – benwiggy
    Dec 1, 2022 at 17:08
  • @benwiggy Thanks, I'd already tried that but tested again to get screenshots, see edited question with screenshots. It's the powerd process that's writing the 32GB, but I can't figure out why, or to where.
    – i-CONICA
    Dec 1, 2022 at 17:28
  • How big is the VM file? Or sleep image?
    – benwiggy
    Dec 1, 2022 at 17:51
  • @benwiggy /var/vm/sleepimage is 2GB. /System/Volumes/VM/kernelcore is 1MB. Not sure I've answered your first question correctly?
    – i-CONICA
    Dec 1, 2022 at 18:04
  • @benwiggy Added additional screenshots from NCDU and pmset -g if it helps. Thanks.
    – i-CONICA
    Dec 1, 2022 at 18:10

1 Answer 1

1

After much investigation, I've found the solution.

I still don't know what exactly powerd process was doing, or why or where it was writing the 32GB of data.

At some point I've obviously tweaked the power management settings, and on new installs restoring my data (which I assumed was independent from settings such as that) has restored my tweak to pmset.

I ran sudo pmset restoredefaults and this has fixed the issue. The system now boots normally, reading around 1.5GB and writing 280~MB.

It still doesn't make sense that this is the hibernate file being written, because the system has 64GB of ram, not 32GB. So I still don't know which pmset option I changed to cause this issue, but if anyone else encounters it, at least now we know the fix.

2
  • Well this got more interesting... If I make any changes to power management settings, simply via the GUI "Energy Saver" System Preferences panel, just changing the 15 minute "turn display off after" setting, it causes the problem again. Running pmset restore defaults fixes it again, but I'm now in even more of a dilemma. Can anyone help?
    – i-CONICA
    Dec 3, 2022 at 14:22
  • This is almost certainly a bug in powerd. While there is a way to trace early boot tasks, it's very technical and will be hampered by having no access to source code or symbolicated build products. Before doing anything of that sort, you should try the most recent major OS release (Ventura) to see if this bug has been fixed.
    – pion
    Dec 13, 2022 at 10:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .