Live data from Hacker News

macOS Sonoma Boot Failures

github.com

181–190 of 290 posts

Re: macOS Sonoma Boot Failures

#181

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.

Phones are Apple's main business. At this point, Macs are second-tier. With Google, I suspect it's their engineering practice. Google doesn't like to make engineering mistakes.

Re: macOS Sonoma Boot Failures

#182
post #173
post #76

Earlier quoted context omitted.

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

And slows boot down by a couple of seconds. As long as the firmware sets a native mode, modern OSes can just inherit that rather than performing a modeset and we just ignore the entire problem anyway.

Re: macOS Sonoma Boot Failures

#183
When I saw the upgrade to Sonoma appear in my Settings I had a feeling the first version of this new OS would be buggy so I held off on it. Now extra glad I did! Gonna stick with Ventura for a while! Haha ! :)

Re: macOS Sonoma Boot Failures

#184

Earlier quoted context omitted.

The Apple Store is usually great with this stuff. If there's a documented problem that affects your hardware model and the given software versions, they're extremely unlikely to try to charge you for anything.

Documented by whom? Are you going to show a marcan post to them and claim it’s an Apple issue?

Marcan's post contains apple ticket numbers... presumably you show them those.

Re: macOS Sonoma Boot Failures

#186
post #165
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....

Right, this is what I meant by the EFI brick in my comment. And in my comment "I can't say I've heard of that happening", I meant bricking a device on a system update. That's the specific thing which seems to happen on occasion with macOS, but that I've not seen with Linux. I do grant that there have been some (very rare) instances like this where hardware can be bricked by a command run on a Linux system.

Re: macOS Sonoma Boot Failures

#188

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…

Somebody missed the memo: https://bwiggs.com/notebook/queens-duck/

Re: macOS Sonoma Boot Failures

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

[deleted]

Re: macOS Sonoma Boot Failures

#190

Earlier quoted context omitted.

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

To my horror, I recently had to visit the UEFI firmware setup of a Lenovo tablet.... That was touch enabled.

I did enjoy my Dell touchscreen-supported firmware setup when there was a menu 15 items long and an incredibly slow mouse speed.
Post reply on HN