Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

macOS Sonoma Boot Failures

github.com

Post reply on HN
Print view View original

171–180 of 290 posts

Re: macOS Sonoma Boot Failures

#171

Post by astrange »

cesarb wrote: post #167
astrange wrote: post #158

Earlier quoted context omitted.

Brick usually means unfixable without an EEPROM replacement or data loss. It's not possible (well, it's very difficult) to do this on an Apple Silicon Mac; once there's an update you can always apply it from another Mac, like the steps on this page do, and your data is still there. With Intel Macs it's possible.

> Brick usually means unfixable without an EEPROM replacement or data loss. The definition of "bricked" is not set in stone; a lot of what a normal person would consider "bricked" (doesn't turn on, or turns on to an unresponsive black screen, and no magic sequence of button presses can reset it to working order) could be fixed by a power user with the right equipment, software, and knowledge. In this case, it require…

> In this case, it requires fairly expensive equipment (another $2.5-10k device)

A few minutes of access to one, not ownership of it, and hardly any system requirements on it.

> It's Apple's insistence on non-removable storage which risks losing data when something else makes the device fail to boot.

That's actually not the reason. All storage is removable if you just desolder it. It's because the storage is encrypted and you can't extract the keys.

Re: macOS Sonoma Boot Failures

#172

Post by cesarb »

gpm wrote: post #165
cesarb wrote: post #152

Earlier quoted context omitted.

> I've never had hardware damaged by Linux, which I've run almost exclusively. [...] I can't say I've heard of that happening to people on Linux at all other than maybe early days of Xorg. There was that LG CD-ROM drive which treated a CD-RW command (which it should ignore or reject since it's not a CD-RW drive) as a firmware upload command. When a newer Linux kernel started using that command, these drives got brick…

More recently there was "rm -rf /" wiping efivars and bricking some motherboards with shitty uefi implementations thanks to systemd mounting efivars rw by default (and shitty motherboard firmware). The kernel "fixed" this by mounting unknown efivars as (mostly) immutable. https://www.phoronix.com/news/UEFI-rm-root-directory https://www.kernel.org/doc/html/latest/filesystems/efivarfs....

There were also some motherboards with shitty UEFI implementations which got bricked when the efivars storage did not have enough free space to do the garbage collection. The kernel "fixed" this by not allowing more than half of the efivars storage to be used (https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...).

Re: macOS Sonoma Boot Failures

#173

Post by kelnos »

mjg59 wrote: post #76
ddalex wrote: post #60

Earlier quoted context omitted.

I don't understand why modeset causes flicker - fade to black, turn off screen, change resolution, turn on screen, fade to image.

"Fade to black, turn off screen, turn on screen, fade to image" is just slower flicker.

True, but that does look nicer than normal-speed flicker?

Re: macOS Sonoma Boot Failures

#174

Post by kelnos »

coldtea wrote: post #130
fsflover wrote: post #69

Earlier quoted context omitted.

On Linux it's as rare as on MacOS, if you buy preinstalled .

As long as you don't do anything with it on your own.

So essentially, the situation you'd have if you'd bought a Mac?

If we want to compare apples to apples, then we compare:

Mac with macOS updates installed regularly, and only those provided by Apple. Non-Apple apps get dropped in /Applications like they should be. If there's an installer that asks for root access, you might get boned.

Linux preinstalled with OS updates installed regularly, and only those provided by the vendor. Apps that don't come with the OS's package manager should be installed somewhere under $HOME, and never installed systemwide as root.

Sure, if you have a Mac and disable SIP (or whatever it's called nowadays) and start mucking around with files in /System or whatever, because you want to install some mod that does something cool, you might have a bad time. Same as if you decide that screwing around in /lib on a Linux machine is a good idea.

But if we actually compare these two apples, I suspect the Linux one would have fewer problems.

Re: macOS Sonoma Boot Failures

#175

Post by kelnos »

aetherspawn wrote: post #107
mattchamb wrote: post #7

Not sure if related, but my 2020 M1 macbook air bricked a week or so after upgrading to Sonoma. I was suspicious if this was related to the update. Luckily the logic board was replaced for free under warranty laws here, though it put me off switching to iphone which I was a day away from doing.

FWIW I have been using iPhones for 10+ years and not once has an update ever failed or had any issues. But my Google Pixel phone used to brick itself all the time, I think twice in the two years I had it.

I've never had an Android phone brick itself in 13 years of owning them. I have friends whose iPhones have gotten bad updates. Not sure if they were bricked, though, or if they "only" needed a factory reset to get things going again.

Re: macOS Sonoma Boot Failures

#176

Post by NavinF »

zippergz wrote: post #67
NavinF wrote: post #38

Earlier quoted context omitted.

Interesting. I wonder why anyone would turn ProMotion off considering that 120Hz massively improves responsiveness. I've only encountered one app that doesn't work with variable refresh rate and that's Genshin on Windows. Even that's probably not an issue with newer monitors that can handle VRR down to 60Hz without my monitor's frame-doubling flicker as it keeps switching been 60Hz and 120Hz

I turn it off because I can’t tell the difference and if it doesn’t improve anything for me, I might as well not have the system wasting battery and other resources on it.

VRR displays run at 1Hz to save battery when the display is static. Reasoning like yours is why every OS's settings page gets neutered with every update.

Re: macOS Sonoma Boot Failures

#177

Post by lxgr »

TylerE wrote: post #146
lxgr wrote: post #143

Earlier quoted context omitted.

Pretty sure VRR is a mode as far as the display (controller) is concerned. There’s very likely still a scan out rate determined by the maximum refresh rate, just that the source can delay the next frame if it’s not ready yet. In other words, e.g. 120 Hz and 144 Hz of VRR aren’t the same even when displaying a 60 Hz signal at the moment – the faster signal would have more pauses and a higher signal rate.

VRR is a property, node a mode. A VRR display showing 60hz will be running at 60hz. They can typically clock down in 1hz intervals.

As far as I understand it, nothing "clocks down"; rather, frames are delayed as required to achieve the frame rate desired (or reachable, in the case of gaming) by the source, down to 1 Hz.

So, yes, fixed 120 Hz and 120 Hz with VRR and without any skipped frames might well be the same mode to a GPU, but it also might be a different one, requiring a mode switch. I don't know how Apple has implemented it.

But in any case, for the bug at hand it's irrelevant: Apple's ProMotion uses a refresh rate of 120 Hz, so switching between that and 60 Hz is definitely a mode switch.

Re: macOS Sonoma Boot Failures

#178

Post by microtherion »

phillco wrote: post #36
alsetmusic wrote: post #8

Earlier quoted context omitted.

> I also wasted far too much time trying to get the DFU restore to work before discovering that you cannot use a Thunderbolt cable — it has to be done using a plain USB-C cable, otherwise the Apple Configurator simply won't detect the other Mac. I would have expected a Thunderbolt cable to be required, if either was. This is quite surprising to me. Usually, the more capable (higher bandwidth) cable works if one isn’t…

I've used a Thunderbolt cable as well successfully, but one note is that they're very picky about which port you use. On my Mac mini, I had to use the exact port outlined here or it did not show up: https://support.apple.com/guide/apple-configurator-mac/reviv...

Yes, this is absolutely key. Only one of the USB ports per machine supports this functionality.

Re: macOS Sonoma Boot Failures

#179

Post by tpmx »

gcr wrote: post #163
FirmwareBurner wrote: post #78

Earlier quoted context omitted.

You clearly don't know Apple as a company. Last most big companies, they never EVER publicly admit any faults or mistakes with their products (unless forced to by large scale fiascos) because that would damage their perfect brand image. It's why they have comments disabled on all their social media accounts.

Google this week seems to be going through a similar bug on their flagship Android 14 release, affecting users who have multiple accounts set up. They also seem to be favoring a "minimal" strategy when it comes to PR communication surrounding this issue.

Okay?
Post reply on HN