Live data from Hacker News

macOS Sonoma Boot Failures

github.com

161–170 of 290 posts

Re: macOS Sonoma Boot Failures

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

i heard these new fangled jibjabs don't even have audible POST beeps.

Re: macOS Sonoma Boot Failures

#162

First I've heard of any issues.. I have done a couple upgrades already with no issue. I'm sure there are some scenarios where it fails, but Sonoma has been out a while with millions of users being prompted constantly to upgrade. Feels like less than a "you're holding it wrong" problem. HN is obv going to bring out the edge cases, but it doesn't seem like the world is on fire with "Sonoma Bricks" by any means.

Do you dual boot? I've got two bootable OSX partitions on my mac and this hit me when I updated.

Re: macOS Sonoma Boot Failures

#163

Earlier quoted context omitted.

Apple still hasn't put up any official page about the issue though, nor does it appear they've pulled the update. Even if it missed QA, why haven't they made any official comment?

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.

Re: macOS Sonoma Boot Failures

#164

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

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

Re: macOS Sonoma Boot Failures

#165
post #152

Earlier quoted context omitted.

By the standard of "do you ever need to consult forum posts to solve a problem", sure, Linux is worse than macOS. By the standard of "do you ever need to consult forum posts to fix hardware that has apparently been bricked by a software update", macOS seems to be considerably worse. At least, that's my experience. I've never had hardware damaged by Linux, which I've run almost exclusively. On the other hand the one A…

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

Re: macOS Sonoma Boot Failures

#166

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

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

The GUI was rendered in text mode. It's called a TUI (Text-based User Interface)

Re: macOS Sonoma Boot Failures

#167
post #88

Earlier quoted context omitted.

It's a device bricking bug. For a $2.5-10k device.

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 requires fairly expensive equipment (another $2.5-10k device), somewhat easy to acquire software, and the appropriate set of instructions, to overwrite the device's broken firmware with a working copy; you don't have to open up the device and plug a JTAG adapter, but using the DFU protocol is very similar to that, since in both cases you're writing directly to the firmware under control of an external device. This is not like "BIOS FlashBack" and similar on non-Apple PCs, in which the device can rewrite its firmware by itself from a common USB stick.

(Also, about data loss: a device with removable storage could get bricked without any data loss, and fixed also without any data loss, simply because the data storage is separated from the firmware and from most of the hardware. It's Apple's insistence on non-removable storage which risks losing data when something else makes the device fail to boot.)

Re: macOS Sonoma Boot Failures

#168
post #39

Today I had to DFU restore my macbook because I wanted to reinstall it, but built-in restore over the web did not work. My base system was 13.2, it downloads all the files for 13.6, it filled bar to 100% and then spewed error. It's obvious that it's some incompatibility between 13.2 base system and 13.6 install. Apple quality is atrocious these days. One would have thought they would test the most basic scenarios bef…

Yeah the Apple bootloader and restore stuff scares the shit out of me. The network access requirement, firmware on SSD and hardware lock are always lurking waiting for the most inconvenient time to go wonky when I hose something. Conversely windows, just got a USB stick in the drawer I can boot off.

> Conversely windows, just got a USB stick in the drawer I can boot off.

It goes further than that, on many motherboards even a failed firmware update can be fixed through a random USB stick from the drawer, you just need the right BIOS file to put in it.

Re: macOS Sonoma Boot Failures

#169

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.

In the same period, 10-12 years ago, both androids and iPhones bricked themselves if there was no storage left on the device. Both needed somes bytes on boot and if they couldn't write on disk, they failed to boot.

Re: macOS Sonoma Boot Failures

#170
post #118

Earlier quoted context omitted.

Then you'd need scaling and all that. Seems a bit overkill for something people rarely use.

scaling? nah, I'd say to just choose at runtime a sane text size (only to avoid using the same pixel size on a 1024x768 as a 5k screen) and set the number of rows and columns to fit the screen. Even if there isn't enough to fill the screen that's fine. > Seems a bit overkill for something people rarely use. Okay, but a lot less so than a full GUI with mouse and thousands of colors, like many motherboards have gone to…

The "sane text size" is naturally going to be the 80x25 text mode (720x400) which is what those config screens were originally defined for. Monitors will usually upscale lower resolutions anyway.
Post reply on HN