Contribute
Register

[solved] Dell Inspiron 15 7559 - "OSInstall.mpkg missing"

Status
Not open for further replies.
Hey all,

The reinstall with Sierra and using Sierra's NVRAM is a project still in the works, so I tried to see if the md5 checksums of both macOS High Sierra Beta.app's were the same in the meantime, and I found something a bit interesting:

Code:
Duncans-iMac:~ duncan$ tar -c /Applications/Install\ macOS\ High\ Sierra\ Beta.app | md5
tar: Removing leading '/' from member names
e606bb45ceb54c0ceaed089181bb3f82
Duncans-iMac:~ duncan$ tar -c /Volumes/Install\ macOS\ High\ Sierra\ Beta/Install\ macOS\ High\ Sierra\ Beta.app | md5
tar: Removing leading '/' from member names
6527eb8427a261823f35be369adb8033

The MD5's for the two installers (desktop on top, installer on bottom) are different! I'm not sure if that's because the installer one is on the installer, or there are special files, but I found this interesting, and it might be the root of the problem...

I've also tried recreating the "install_osx" USB many times now... :think:

-Duncan
 
Hey all,

I've attempted to "re-build" my installer (basically starting from scratch and only adding the things that will let me boot into the installer)... It boots into the installer fine, but the error still shows up!

At this point, I'm more concerned at the current fact that the NVRAM doesn't seem to be working, as with or without EmuVariableUEFI-64.efi, no nvram.plist is being created! I've searched high and low, and I can't find any plist...

I wonder what the probable cause for this could be. I might try re-installing Sierra and then attempting to upgrade to High Sierra with NVRAM confirmed working on the Sierra install... (since we can't have RC-scripts on installer USB)

-Duncan

No nvram.plist expected when using native NVRAM (nvram data is stored in NVRAM).
No nvram.plist expected without RC scripts (when using EmuVariableUefi-64.efi).
 
No nvram.plist expected when using native NVRAM (nvram data is stored in NVRAM).
No nvram.plist expected without RC scripts (when using EmuVariableUefi-64.efi).

Yep! Thank you for reminding me :thumbup:

Is there any way to test that native NVRAM is working? (w/o EmuVariableUefi-64 & RC scripts) Is adding values into the macOS nvram and then seeing if it persists between reboots (via "nvram -xp") a valid way to test if native NVRAM works? :think:

And is there any way to "manually" "mount" the OSInstall.mpkg? (basically to bypass the need for NVRAM working) That could be an interesting approach to take too ... :think:

Thank you for all the help so far!

-Duncan
 
Yep! Thank you for reminding me :thumbup:

Is there any way to test that native NVRAM is working? (w/o EmuVariableUefi-64 & RC scripts) Is adding values into the macOS nvram and then seeing if it persists between reboots (via "nvram -xp") a valid way to test if native NVRAM works? :think:

And is there any way to "manually" "mount" the OSInstall.mpkg? (basically to bypass the need for NVRAM working) That could be an interesting approach to take too ... :think:

Thank you for all the help so far!

-Duncan

On a working install without EmuVariableUefi-64.efi, you can test nvram with the 'nvram' command line utility. Read 'man nvram' for more information.
 
On a working install without EmuVariableUefi-64.efi, you can test nvram with the 'nvram' command line utility. Read 'man nvram' for more information.

Alright, I have a couple of somewhat interesting developments with managing NVRAM.

First, I'm convinced for now that the native NVRAM in my laptop works, as I performed the test where I added a test value (i.e. "sudo nvram test=1"). Now note the sudo in the command. That was pretty much vital in manipulating the NVRAM, as I forgot to use it otherwise, and I wasn't seeing the reults I was expecting...

Nonetheless, my test variables would persist throughout reboots and shutdowns (according to the nvram utility). I then cleared the NVRAM (using "sudo nvram -c" instead of "nvram -c", and it's very important that sudo was used). The NVRAM persisted as being cleared until the next reboot, and then I saw that the NVRAM values were "refreshed".

Seeing this, I was thinking, "oh, maybe it'll actually work this time!" So I boot into the installer (with clearing the NVRAM the reboot before), and lo and behold! It didn't work ...

The only difference that I saw was that it prompted for a language selection at the beginning of the installation (making it evident to me that the NVRAM differences were "noticed" by the installer), but the "OSInstall.mpkg" error was still persistent...

Now these findings lead me to thinking - if my native NVRAM works and persists, why am I still getting the error? :think: Even after a "fresh NVRAM wipe", the error still persists...odd...

Now this might not be related, but I was also noticing that the time in macOS wasn't updating. For example, I was testing various things yesterday (Friday) on the makeshift macOS Sierra installation that I put on the laptop, and when I booted up the laptop for the first time today (Saturday), the time still showed the date and time of when I used the laptop on Friday. The minutes weren't updating at all or anything... :think:

This persisted across reboots, so this led me to thinking it was a BIOS issue. I boot into the BIOS, and the BIOS time wasn't (and still isn't) updating! For example, when I began my daily testings (which led to the creation of this post), I set the time in the BIOS to "21.22.15" (hh/mm/ss). Now when I'm writing this post, the time still persists at "21.22.15"!

I wonder if my CMOS battery might need to be replaced? :think: I'm not too sure as to why the time wouldn't update in the BIOS, but I'd say that's something to look into as well (although as I said it might be unrelated, but since it was a problem with the BIOS/UEFI, and UEFI/NVRAM go hand-in-hand, I thought it was worth mentioning)...

Suggestions? :lol:

Sorry for the long post, and thank you for all your help!

-Duncan
 
Alright, I have a couple of somewhat interesting developments with managing NVRAM.

First, I'm convinced for now that the native NVRAM in my laptop works, as I performed the test where I added a test value (i.e. "sudo nvram test=1"). Now note the sudo in the command. That was pretty much vital in manipulating the NVRAM, as I forgot to use it otherwise, and I wasn't seeing the reults I was expecting...

Nonetheless, my test variables would persist throughout reboots and shutdowns (according to the nvram utility). I then cleared the NVRAM (using "sudo nvram -c" instead of "nvram -c", and it's very important that sudo was used). The NVRAM persisted as being cleared until the next reboot, and then I saw that the NVRAM values were "refreshed".

Seeing this, I was thinking, "oh, maybe it'll actually work this time!" So I boot into the installer (with clearing the NVRAM the reboot before), and lo and behold! It didn't work ...

The only difference that I saw was that it prompted for a language selection at the beginning of the installation (making it evident to me that the NVRAM differences were "noticed" by the installer), but the "OSInstall.mpkg" error was still persistent...

Now these findings lead me to thinking - if my native NVRAM works and persists, why am I still getting the error? :think: Even after a "fresh NVRAM wipe", the error still persists...odd...

Now this might not be related, but I was also noticing that the time in macOS wasn't updating. For example, I was testing various things yesterday (Friday) on the makeshift macOS Sierra installation that I put on the laptop, and when I booted up the laptop for the first time today (Saturday), the time still showed the date and time of when I used the laptop on Friday. The minutes weren't updating at all or anything... :think:

This persisted across reboots, so this led me to thinking it was a BIOS issue. I boot into the BIOS, and the BIOS time wasn't (and still isn't) updating! For example, when I began my daily testings (which led to the creation of this post), I set the time in the BIOS to "21.22.15" (hh/mm/ss). Now when I'm writing this post, the time still persists at "21.22.15"!

I wonder if my CMOS battery might need to be replaced? :think: I'm not too sure as to why the time wouldn't update in the BIOS, but I'd say that's something to look into as well (although as I said it might be unrelated, but since it was a problem with the BIOS/UEFI, and UEFI/NVRAM go hand-in-hand, I thought it was worth mentioning)...

Suggestions? :lol:

Sorry for the long post, and thank you for all your help!

-Duncan

Do CMOS reset.
 
Do CMOS reset.

That finally did it! Resetting the CMOS (on the hardware level, taking out the coin battery and all) on this laptop basically required me to take the entire chassis apart (since it was buried deep in the laptop). Almost broke the thing.... I am not doing that again! :lol: If it happens again I'll just send it in for warranty (as I'm still covered)...

Anyways, after fully resetting the CMOS, native NVRAM and the BIOS time issues were fixed! And consequentially, I was able to install macOS High Sierra on my laptop! :thumbup: I'm writing this post from the running High Sierra right now, and I've spent the last day or so "rebuilding" my installation to be as fully functional as possible...

I did run into some other issues with post-installation, but I'll post those in another thread, as it's not relevant here...

Thank you so much for all the help everyone! :D

-Duncan
 
That finally did it! Resetting the CMOS (on the hardware level, taking out the coin battery and all) on this laptop basically required me to take the entire chassis apart (since it was buried deep in the laptop). Almost broke the thing.... I am not doing that again! :lol: If it happens again I'll just send it in for warranty (as I'm still covered)...

Anyways, after fully resetting the CMOS, native NVRAM and the BIOS time issues were fixed! And consequentially, I was able to install macOS High Sierra on my laptop! :thumbup: I'm writing this post from the running High Sierra right now, and I've spent the last day or so "rebuilding" my installation to be as fully functional as possible...

I did run into some other issues with post-installation, but I'll post those in another thread, as it's not relevant here...

Thank you so much for all the help everyone! :D

-Duncan

Marked solved.
 
Hey all,

Sorry for bringing up a solved thread again...
Just wanted to add that right after this problem was solved, the problem occurred again (after a couple of reboots and some other things, probably disconnected battery), and the UEFI not saving the correct time (and not updating it automatically) ended up being a defect with the laptop motherboard (including CMOS and all that stuff...). Shipped it in to be repaired and just received it earlier today! Hopefully all will work well this time :)

-Duncan
 
Hey all:

I'm attempting to install the macOS High Sierra Public Beta, and I'm having a bit of trouble getting the installer to start...
Everything boots fine and well, but the only problem I get is that once it boots into the installer, it gives the error that the installer could not start because "the path /System/Installation/Packages/OSInstall.mpkg is missing."

I have tried using the "real" upgrade path (downloading the Public Beta from the App Store, running it using the Public Beta Access Utility, and running the installer on the boot drive), and it leads to that error. I've also made a bootable USB using createinstallmedia, and it also returns the same error.

I've checked the actual path that it's complaining about (/System/Installation/Packages/OSInstall.mpkg, it's hidden), and the only folder present in both installations in the /System directory is /Library. Is this normal?

I've never had this problem before so I'm very curious to see as to what would be causing it.

If you guys have any ideas please feel free to share!

Thank you!

-Duncan
Hi Duncan,

May i ask how you were able to Hackitosh you 15 7559, I am hoping to do the same for me but not sure which files required or the complete setups, hoping to get High Sierra 10.13 beta 5 on with the new file system.

Thank you Duncan
 
Status
Not open for further replies.
Back
Top