Live data from Hacker News

macOS Sonoma Boot Failures

github.com

141–150 of 290 posts

Re: macOS Sonoma Boot Failures

#141

Earlier quoted context omitted.

And this is why there will never be a Year of the Linux Desktop -- no-one wants to have to depend on forum posts to fix these kind of issues. /troll

This issue in GP is unrelated to Linux, it happens on single-boot macOS.

That's the point, I think - Linux gets derided because people say it just breaks at random and you have to wade through forums to find arcane incantations to fix it, either implying or outright stating that their favorite proprietary OS would never just blow up in your face and force you to resort to exotic troubleshooting steps. So when macos, the poster child for "user friendly", proceeds to brick the machine and require elaborate rituals to fix, it invites a certain level of snark from users pointing out that the high and mighty proprietary OSs might be just as bad as Linux after all.

Of course, whether that's valid is at minimum a question of actual frequency of problems and relative impact and effort to fix, but from a perspective of optics and emotions I understand the reaction.

Re: macOS Sonoma Boot Failures

#143
post #136

Earlier quoted context omitted.

Except it doesn't... because during use the dynamic refresh rate changes between 1Hz and 120Hz...

That's not a modeset though, that's just the display working as intended. Basically a VSYNC that runs at a variable clock rather than a fixed refresh.

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.

Re: macOS Sonoma Boot Failures

#144
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 wonder why anyone would turn ProMotion off considering that 120Hz massively improves responsiveness. ...and I bet that's exactly the attitude Apple had when implementing things, which lead to this mess.

Well then don't allow turning it off in the first place.

Re: macOS Sonoma Boot Failures

#145

Earlier quoted context omitted.

> Text-only BIOS setup was the norm for a long time Long-time Thinkpad users scoff at that ... while the figure of a duck suddenly enters their minds.. (Yes: I clearly remember my pre-USB thinkpad having a graphical BIOS with windows, icons, and a duck-shaped mouse cursor).

For those who haven't seen it: https://www.youtube.com/watch?v=XTaNi6uL41s BIOSes of the time were all written in highly-optimised Asm, and I suspect those little "easter eggs" they added were because the programmers knew they had enough space left over to put some more fun stuff in. There was also AMI WinBIOS that provided a GUI, but I remember it being much less featureful than other BIOSes of the time with a TUI a…

A 90's TUI that will forever be more productive than Windows 11.

Re: macOS Sonoma Boot Failures

#146
post #143
post #136

Earlier quoted context omitted.

That's not a modeset though, that's just the display working as intended. Basically a VSYNC that runs at a variable clock rather than a fixed refresh.

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.

Re: macOS Sonoma Boot Failures

#147
post #103

Earlier quoted context omitted.

The messiness of resolutions during boot always annoyed me on PCs. It was understandable back in the days of BIOS, but ith the advent of UEFI it seems like it should be possible to run EFI config screens and the like at monitor native rez (or at minimum, native aspect ratio) but I’ve never seen this… it’s always 1024x768 or somesuch stretched to fit a 16:9 monitor which looks awful.

At least it works. I find low-res bios screens reassuring... something I can depend on.

Maybe instead of spending effort providing low res fallback options, we should be spending more effort making high res GUI-based options more dependable?

Re: macOS Sonoma Boot Failures

#148
post #5

See also his twitter for some speculation as to how on earth simply changing refresh rate would cause boot corruption: https://social.treehouse.systems/@marcan/111329614147717090 >Why? I can tell you why: because Apple hates display modeset flicker, and switching modes between ProMotion on/off causes a modeset flicker, so of course they made it so that is stored in nvram somewhere and applied when the screen is turne…

The messiness of resolutions during boot always annoyed me on PCs. It was understandable back in the days of BIOS, but ith the advent of UEFI it seems like it should be possible to run EFI config screens and the like at monitor native rez (or at minimum, native aspect ratio) but I’ve never seen this… it’s always 1024x768 or somesuch stretched to fit a 16:9 monitor which looks awful.

There's a lot going on there. To prevent flicker, you not only have to preserve the screen resolution, but also all the graphics card memory and state and hand it off through stages of boot from efi to the os.

As an analogy this would be sort of like rebooting the OS in place while preserving all the running apps, network state and USB connections without resetting anything.

These kinds of things are possible, but have lots of corner cases.

Re: macOS Sonoma Boot Failures

#149

Earlier quoted context omitted.

EFI config screens should be text mode only, full-stop. So they can easily be used over serial console redirection. Ran into one recently that was high-rez graphical. It needed a USB mouse to change critical settings because the tab order for the onscreen widgets didn't work. Anyone responsible for creating graphical EFI config screens should stop writing software for the good of humanity.

Text-only BIOS setup was the norm for a long time before the stupidly bloated EFI graphical stuff became common. Even then, there were the better full-featured TUIs: https://upload.wikimedia.org/wikipedia/commons/0/05/Award_BI... https://liveusb.files.wordpress.com/2010/05/awardbios-firstb... And the simplified crap with tabs that often came with prebuilt PCs but later seems to have spread to others too: https://cdn.…

> Text-only BIOS setup was the norm for a long time

I've had a GUI BIOS setup on almost every PC I've owned since the first 486 I built back in 1993.

Re: macOS Sonoma Boot Failures

#150
post #51
post #46

Earlier quoted context omitted.

This is depressing. They clearly have they ability ($$$) to do the required amount of manual QA, but don't. Or there was QA and someone decided that your case still wasn't enough to hold up the release. In my mind, when we pay that ridiculous Apple premium on RAM and storage, we pay for excellent quality in SW/HW. They also need to deliver that quality.

Or they did QA but just happened to miss this issue. Most companies would consider "the upgrade sometimes bricks the device" to be a release-stopping bug, I'm betting Apple is among them.

"You're updating it wrong." —Steve
Post reply on HN