experchange > mac.misc

Your Name (12-05-18, 11:01 PM)
From MacRumors.com ...

Apple Releases macOS Mojave 10.14.2, Resolves 2018 MacBook Pro
Issue With External Displays and Other Bug Fixes
--------------------------------------------------------------
Apple today released macOS Mojave 10.14.2, the second update to
the macOS Mojave operating system that first launched in
September. macOS Mojave 10.14.2 comes three weeks after Apple
launched macOS Mojave 10.14.1 with Group FaceTime support and
new emoji.

macOS Mojave 10.14.2 can be downloaded by going to the "Software
Update" section of System Preferences, a new installation method
that was introduced with the Mojave update.

The 10.14.2 update introduces performance improvements and bug
fixes for issues that weren't addressed in macOS Mojave 10.14.1.
There were no major feature changes discovered during the course
of the beta testing period.

macOS Mojave 10.14.2 release notes:
- Adds RTT (real-time text) support for Wi-Fi calling.
- Adds a menu item to News for opening a story in Safari.
- Resolves an issue that may prevent iTunes from playing media
to third-party AirPlay speakers.

Enterprise-related:
- Allows administrators to enable FileVault via MDM for mobile
accounts and users created by MDM.
- Allows users to reset their login password at the login window
when that password has expired via a password policy.
- Resolves an issue that prevents displays from working when
connected to MacBook Pro models introduced in 2018, if certain
third-party USB graphics devices are also connected.

<https://www.macrumors.com/2018/12/05/macos-10-14-2-released/>
Anders Eklöf (12-07-18, 12:30 AM)
Your Name <YourName> wrote:

[..]
> connected to MacBook Pro models introduced in 2018, if certain
> third-party USB graphics devices are also connected.
> <https://www.macrumors.com/2018/12/05/macos-10-14-2-released/>


Anything about solving the issue with some Fusion Drive iMacs being
rendered unusable becuse they can't load drivers for Ethernet, Wifi,
grahic drivers for Retina among other things? An get super slow...
David Empson (12-07-18, 01:21 AM)
Anders Eklöf <andekl_no> wrote:

> Your Name <YourName> wrote:
> > <https://www.macrumors.com/2018/12/05/macos-10-14-2-released/>

> Anything about solving the issue with some Fusion Drive iMacs being
> rendered unusable becuse they can't load drivers for Ethernet, Wifi,
> grahic drivers for Retina among other things? An get super slow...


Many of those symptoms sound like another instance of a lingering bad
configuration file from a much older Mac OS X version which started
causing serious problems in Mojave. I've been helping someone with this
recently, in the comp.sys.mac.system thread titled "going from High
Sierra to Mojave (and back)", starting at Message-ID:

<1nz9fev.b39am51aijufdN%dempson>

I found about it from this Apple Discussions thread (which did not go
into technical details):



See if you have a file /private/etc/sysctl.conf and if so, have a look
at its contents (it is plain text).

Summarising the details gathered in the other thread:

Apple doesn't create that file but it is supported and sometimes
installed by third party software. Its purpose is to change sysctl
settings at startup, overriding the system defaults.

For the person with the problem in the other thread, that file had been
installed by a third party utility probably in 2005 to improve broadband
performance on Mac OS X 10.4 Tiger. The file remained there in
subsequent macOS upgrades and migrations, and the problems appeared on a
2013 iMac after upgrading to Mojave.

The file was overriding these sysctl settings:

kern.ipc.maxsockbuf
net.inet.tcp.sendspace
net.inet.tcp.recvspace

The assigned values were greater than the defaults on Mac OS X 10.4 but
the first one was an order of magnitude lower than the default used in
Mac OS X 10.5 and later. It appears that low setting causes major
performance issues and networking failures on macOS 10.14 Mojave but
didn't have an immediately noticeable impact on mac OS 10.13 and
earlier.

The default kern.ipc.maxsockbuf setting on Mac OS X 10.6 and later is at
least 4194304 (higher in recent macOS versions if your Mac has more than
4 GB of RAM). Mac OS X 10.5 had a default of at least 8388608.

The bad file in question was setting kern.ipc.maxsockbuf to 512000.
Lewis (12-07-18, 02:19 AM)
In message <1nzfsuz.1qhnv001drbm4pN%dempson> David Empson <dempson> wrote:
> See if you have a file /private/etc/sysctl.conf and if so, have a look
> at its contents (it is plain text).


There's no need for /private. /etc/sysctl.conf will point to the same
file.

And, since the file is empty be default on macOS, it's safe to simply
delete it.
Anders Eklöf (12-07-18, 11:15 PM)
David Empson <dempson> wrote:

[..]
> least 4194304 (higher in recent macOS versions if your Mac has more than
> 4 GB of RAM). Mac OS X 10.5 had a default of at least 8388608.
> The bad file in question was setting kern.ipc.maxsockbuf to 512000.


Sounds really promising. My sysctl.conf file is from 2006 and fits the
descriprion exactly. Probably inherited from a G4 Cube or iMac G5.
I'll try it when I have time to handle a second failiure and fallback to
High Sierra :-)

I've already renamed the bugger.
Anders Eklöf (12-09-18, 11:16 AM)
Anders Eklöf <andekl_no> wrote:

> David Empson <dempson> wrote:
> Sounds really promising. My sysctl.conf file is from 2006 and fits the
> descriprion exactly. Probably inherited from a G4 Cube or iMac G5.
> I'll try it when I have time to handle a second failiure and fallback to
> High Sierra :-)
> I've already renamed the bugger.


Followup: Installed 10.14.2 and it appears to work like a charm. As you
can see even MacSOUP still works (I know - it won't when 32-bit support
is dropped...)

Anyone got an idea what third party program may have tweaked the buffer
parameters?
Lewis (12-09-18, 04:28 PM)
In message <1nzjdq9oecijyieqxx3N%andekl_no@saaf_spamse>Anders Eklöf<andekl_no> wrote:
> Anders Eklöf <andekl_no> wrote:



> Followup: Installed 10.14.2 and it appears to work like a charm. As you
> can see even MacSOUP still works (I know - it won't when 32-bit support
> is dropped...)


I have a few apps that don't look like they will be updated, so I am
planning on keeping a 10.14 install active in another volume on my boot
drive (I currently have three Oses on my boot drive, current High
Sierra, current working Mojave and current(ish) bare Mojave.

> Anyone got an idea what third party program may have tweaked the buffer
> parameters?


Everything I've seen on this indicates that various ISP software are
almost always responsible for these changes.

I remember making some necessary changes to the file back in the early
days of OS X to increase the file handlers.
Chris Ridd (12-09-18, 05:50 PM)
On 09/12/2018 09:16, Anders Eklöf wrote:
> Anders Eklöf <andekl_no> wrote:
> Followup: Installed 10.14.2 and it appears to work like a charm. As you
> can see even MacSOUP still works (I know - it won't when 32-bit support
> is dropped...)
> Anyone got an idea what third party program may have tweaked the buffer
> parameters?


It may have been Apple itself, which offered some sort of Broadband
Tuner download that essentially just set that file.
David Empson (12-09-18, 09:14 PM)
Chris Ridd <chrisridd> wrote:

> On 09/12/2018 09:16, Anders Eklöf wrote:
> > Followup: Installed 10.14.2 and it appears to work like a charm.


Excellent. Glad I was able to point you in the right direction.

> > Anyone got an idea what third party program may have tweaked the buffer
> > parameters?

> It may have been Apple itself, which offered some sort of Broadband
> Tuner download that essentially just set that file.


Aha - I still have a copy of something from Apple called "Broadband
Tuner" in my archives for Mac OS X 10.4. (I don't think I ever used it,
as I didn't have the problem file on my system.)

Digging inside it with Pacifist, I find that it has a postinstall script
with these now familiar chunks of file content:

$sysctl_block =
"#\n" .
"# Tuning network for broadband\n" .
"#\n" .
"# START\n" .
"";

@sysctl_commands = (
"kern.ipc.maxsockbuf=512000" ,
"net.inet.tcp.sendspace=131072" ,
"net.inet.tcp.recvspace=358400"
);

$sysctl_block .=
"# END\n" .
"";

The script writes that data to "/private/etc/sysctl.conf"

It also has code to check if those settings are already there (or with
different values) and bail.

It appears to have an uninstaller as part of the package.

We have a cause and effect, and I will be filing a bug report against
Mojave since this is an Apple-supplied patch which later upgrades did
not delete and it has started to cause a major problem.

I can't see Broadband Tuner listed on support.apple.com/downloads but it
is probably old enough to have been archived by now.

My downloaded copy is dated 2005-11-29.
Chris Ridd (12-09-18, 09:43 PM)
On 09/12/2018 19:14, David Empson wrote:
> We have a cause and effect, and I will be filing a bug report against
> Mojave since this is an Apple-supplied patch which later upgrades did
> not delete and it has started to cause a major problem.


It is a bit unfortunate, but then how much hardware that could run 10.4
can also run Mojave? I'm trying to work out how that particular file
could have survived for so long.
nospam (12-09-18, 09:47 PM)
In article <pujr8f$rus$1>, Chris Ridd <chrisridd>
wrote:

> > We have a cause and effect, and I will be filing a bug report against
> > Mojave since this is an Apple-supplied patch which later upgrades did
> > not delete and it has started to cause a major problem.

> It is a bit unfortunate, but then how much hardware that could run 10.4
> can also run Mojave? I'm trying to work out how that particular file
> could have survived for so long.


multiple migrations.
David Empson (12-09-18, 11:34 PM)
Chris Ridd <chrisridd> wrote:

> On 09/12/2018 19:14, David Empson wrote:
> It is a bit unfortunate, but then how much hardware that could run 10.4
> can also run Mojave? I'm trying to work out how that particular file
> could have survived for so long.


Migration.

Given a 2012 or later iMac and a 2007 or earlier iMac (including PowerPC
models as far back as 2003), this could be as little as a single
migration from an older Mac that was at some point running 10.4 or
earlier to a newer Mac that is now being upgraded to 10.14.

I don't have the right combination of models to test using iMacs, but I
can do a test involving older Intel Mac Mini models to confirm it is
possible for this file to survive through an example sequence of
migrations and upgrades from 10.4 to 10.14.
Lewis (12-09-18, 11:37 PM)
In message <pujr8f$rus$1> Chris Ridd <chrisridd> wrote:
> On 09/12/2018 19:14, David Empson wrote:
>> We have a cause and effect, and I will be filing a bug report against
>> Mojave since this is an Apple-supplied patch which later upgrades did
>> not delete and it has started to cause a major problem.


> It is a bit unfortunate, but then how much hardware that could run 10.4
> can also run Mojave? I'm trying to work out how that particular file
> could have survived for so long.


Easily, for many mac users.

It is no longer the case, but it was not that long ago that I still had
preference files from the days of 10.0 and 10.1. The oldest ones I have
now are from 2012.

If you have migrated to new machines by simply restoring your current
system onto the new machine, those files will stay around forever.
Chris Ridd (12-10-18, 12:06 PM)
On 09/12/2018 21:34, David Empson wrote:
> Chris Ridd <chrisridd> wrote:
> Migration.
> Given a 2012 or later iMac and a 2007 or earlier iMac (including PowerPC
> models as far back as 2003), this could be as little as a single
> migration from an older Mac that was at some point running 10.4 or
> earlier to a newer Mac that is now being upgraded to 10.14.


Good point David and Lewis, I was assuming a single piece of hardware
getting OS upgrades over time and I'd completely forgotten about
migrations. Doh!

Apple may have forgotten about their broadband tuner package and it will
be interesting to see if they do something about your bug report.
David Empson (12-15-18, 04:16 AM)
Chris Ridd <chrisridd> wrote:

> On 09/12/2018 21:34, David Empson wrote:
> Good point David and Lewis, I was assuming a single piece of hardware
> getting OS upgrades over time and I'd completely forgotten about
> migrations. Doh!
> Apple may have forgotten about their broadband tuner package and it will
> be interesting to see if they do something about your bug report.


Bug report submitted.

Here is how I repeated the problem.

Mac Mini 2007:
- Installed a fresh 10.4.11 system on an external drive.
- Installed Broadband Tuner.
- Upgraded to 10.6.8.

Mac Mini 2009:
- Moved external drive over.
- Upgraded to 10.11.6.
- Confirmed Broadband Tuner's sysctl.conf was still there and still
affecting the sysctl variables.

[If my 2007 iMac was working reliably I could have done all the above on
a single computer.]

Mac Mini 2014:
- Installed a fresh 10.13.6 system on another external drive.
- Migrated from the 10.11.6 system (with Broadband Tuner).
- Confirmed Broadband Tuner's sysctl.conf got migrated and still
affecting the sysctl variables.

Observed no noticeable affect on system behaviour up to this point.

- Upgraded to 10.14.2.

Confirmed horrible behaviour with those sysctl settings. No functioning
network interfaces, other volumes won't mount, very sluggish.

- Unable to run the Broadband Tuner uninstaller because other volumes
won't mount while the system is in the bad state.
- Manually removed the /etc/sysctl.conf file and restarted.

Now works fine.

- Manually removed the hidden /etc/.BroadbandTuner.savedsettings file
(which still had the original values from Tiger).

- Tried installing BroadbandTuner directly in Mojave. Doesn't work
because it doesn't find suitable default settings to patch.

Broadband Tuner really only runs on Tiger (or possibly earlier
versions), so Apple will need to dig out a 2007 or earlier Mac to test
this. I included sysdiagnose reports for the Mojave bad and good states,
and a copy of the Broadband Tuner installer and the files it created on
my Tiger system (which remained all the way through to the
post-migration Mojave system).

Similar Threads