Um schreiben oder kommentieren zu können, benötigst du ein Benutzerkonto.
Du hast schon ein Benutzerkonto? Melde dich hier hier an.
Jetzt anmeldenHier kannst du ein neues Benutzerkonto erstellen.
Neues Benutzerkonto erstellenHör du mit UniBeast auf!!! Ich nehme da immer Tinu, aber das ist das gleiche wie CreateInstallMedia.
Und Vollzitate sind hier nicht erwünscht
Tnu actually uses createinstallmedia but it adds checking and preparation operations to it, so it's a bit more complicated than what you said but it's made to ensure the success of the installer creation process
Du verwirrst mich mit dem Hin&Her zwischen MAC und Hackintosh.
Unter welchen OS versuchst Du deinen Install-Stick zu erstellen? Unter TINU geht kein Terminal auf. Ich verstehe den Problem nicht, bitte mehr Info.
The latest tinu 3.0 beta 3 of tinu asks for the password in the terminal everytime you open it because it tryes to avoid a common problem with sip enabled on catalina and newer systems, i am working on the beta 4 with improovements to all of this and it will ask for this just when the app is running on a system affected by the problem and also to avoid asking the passowrd 2 times to achieve that
Alles anzeigenZunächst von mir erstmal ein herzliches Willkommen im Forum
Deine Hw sieht gut aus, trage diese bitte in dein Profil ein (Vgl mein Profil). Zunächst würde ich dich bitten, den Bootstick neu zu erstelle. Am besten machst du das mit Tinu, denn die Tomaten Tools werden bei uns nicht supported. Dazu kannst du folgende Anleitung nutzen
1.1 Installations-Stick erstellen
Gehe ich richtig in der Annahme, dass du dich bereits auch hier eingelesen hast Beginner guide ? Falls nicht, würde ich dich bitten, das noch nachzuholen
Als EFI bzw. Clover Vorlage kannst du entsprechend deiner CPU hier anfangen
Install-Stick für diverse System-Varianten (High Sierra 10.13.6, Mojave 10.14.6 und Catalina 10.15)
Welchen Bootloader du verwenden möchtest liegt ganz bei dir. Open Core ist im Gegensatz zu Clover zukunftssicherer.
Liebe Grüße Wolfi
The guide for tinu is outdated since new versions of the app brought huge changes ans semplifications for the ui, as the author of the app i don't reccommend that people use the outdated 1.1 averion and that they just switch to use the latest betas for version 3.0
About beta 4 i am laying down some groundwork for localization and i am starting to do that by remooving a bunch of hardcoded ui-related strings from the app's code and mooving them to external .json files located into the app's bundle, this will make ui management somewhat easyer since there is no longer the need to mess with the code and also since the ui stuff will be located into external files it will be easily editable and so new languages can be added even without using xcode.
This stuff is in very early stages now and still doesn't work for a bunch of reasons (like the app being compiled just to target english and also the fact that the vast mojority of the ui stuff isn't implemented via json files but rather in the storyboards or via hardcoded stuff) of course this will change and i'd really like to give you a version of the app featuring german support in the future (and for that i will need some people to take care of the translation).
To take a look you can see what i have done in the latest commit on github in the development branch https://github.com/ITzTravelInTime/TINU/tree/development
About the github repo should i commit my latest work to the main branch or just keep using the development branch for that? and so leaving the main branch for release code only?
Mornin' ITzTravelInTime and thanks for the heads up...
If TINU has issues to temporarily log stuff within its own file structure, wouldn't it be feasible to pipe this data to a file within the user context, i.e. ~/Library/Preferences (configurations) or ~/Library/Logs (log files)?
Hi, for the files the diagnostics mode needs a .sh File to run the tinu executable from the terminal and that file is located inside the app right now and needs to have the executab le attribute in order to be successfully executed by the terminal, but i guess you are right i can just dinamically create the .sh file in ~/Library/Preferences or in any other folder in which my app has free access and then launch tinu from there, i have to do some research and try it out.
ja ich habe es mit Tinu 1.1 erstellt und auf der EFI Partition den Clover und Boot Ordner kopiert
TINU 1.1 is an old version from 2017, please don't use that since it's pretty buggy and lacks a lot of needed features and it won't work with a lot of macOS installers
CMMChris Ja, das Ergebnis von TINU und createinstallmedia-Befehl ist dasselbe. Der Prozess ist aber anders, weshalb bei TINU Buchstabendreher, fehlerhafte Pfadangaben oder Fragen nach der Formatierung praktisch keine Rolle spielen. Für mich sympathisch, da weniger fehleranfällig.
Auf jeden Fall wundere ich mich, dass der Hack noch nicht läuft.
A reason for that is that TINU just makes lots of checks and closes all the possibly conflicting stuff, TINU is not just a GUI but rather a more sophisticated app which avoids most common errors to let the user have a better time creating installers, i mostly talk about it as just a GUI because in this way people can understand better what it does, even if it's not very accurate.
TINU hat in letzter Zeit bei mir auch öfter gezickt. Formatiere den Stick mal vorher mit dem Festplattendienstprogramm mit HFS+ und GUID.
That's wired, i have tested the formatting plenty of times with success, what's your issue precisely?
TINU geht bei mir nicht (Impossible to use dieagnostic mode ERROR CODE: 1)
known error, moove tinu to the desktop and you should no longer have it
Ja, die meldet:
known bug which is being worked on, moove the app to the desktop and it should no longer be there
Proper catalina and big sur support has been added with beta 3, so i reccommend all the people to just use the latest beta and, to avoid the bug, just moove it to the desktop before opening it, because apparently the desktop is threated differently from other folders in terms of sandboxing, this issue is being worked on and it will be at least improoved with beta 4
HAI in your previous post you were using a version from 2017 which was coded poorly (respect to how i write code now) so go to github and grab the latest version of TINU (3.0 beta 3): https://github.com/ITzTravelInTime/TINU/releases
HAI Checks for installer app size and volume size will be added with BETA 4, those are currently tested and working and all the info in the app have been updated, i just need to update the github documentation when i release the beta
Alles anzeigenZusammenfassung:
Hardware:
Desktop PC, Intel Pentium E5500, Gigabyte Board G41M-ES2L
4GB DDR2 RAM, ASUS Geforce210
Vollständige El Capitan DMG laden und auf einem MAC oder wie bei mir in einer VirtualBox mit MAC einen bootfähigen USB Stick erstellen.
Socket 775 cpus are pretty cheap on ebay, he can get an E8XXX or a Q8XXX/Q9XXX for cheap and install High Sierra easily and without changing gpu (but i strongly reccommend at least 4gb of ram and an ssd), To get catalina and mojave running on that system he will need the right gfx card and a couple of kexts (mouSSE and telemetrap), personally i got Big Sur Beta 1 to boot on my E8400 with a geforce gt 710 and an ssdbut that was not easy to achieve and required using some of the same stps used by people installing this version on old macs with similar cpus
Das ist prima
dann kannst du dir mit tinu einen Bootstick für catalina erstellen.
TINU officially supports that and Big Sur with the latest BETA release you can find here: https://github.com/ITzTravelInTime/TINU/releases
It turns out that the problem was the app not having the needed permitions with SIP enabled so the solution is running TINU from the terminal which has all the needed permitions, but this is still experimental and the way it works will change.
zum übertragen des osx-app kannst du z.b. tinu nutzen
As you can also read here: https://github.com/ITzTravelInTime/TINU/wiki/FAQs
TINU does not just copyes over the installer app, it runs the createinstallmedia executable wich makes bootable the installer drive by creating all the boot files a mac needs inside invisible folders
Tinu geht leider nicht "unable to run in diagnostic mode"??
Danke trotzdem für den Hinweis
Known bug moove tinu to the desktop and it should not do that, i am working on it for version 3.0 BETA 4
Die Install.App lässt sich nicht zur Erstellung eines Installations-Stick nutzen. Weder mit "TINU" noch mit "Pandoras Box". VMWare Fusion verweigert ebenfalls die Install.App.
Use TINU 3.0 BETA 3 which added proper Big Sur support: https://github.com/ITzTravelInTime/TINU/releases
I has been a while since i last updated this thread, i have released a new version, it is version 3.0 BETA 3 which added support to catalina and big sur and a bunch of other things, you can find it here:
https://github.com/ITzTravelInTime/TINU/releases
About the future plans:
1)I am currently working on BETA 4 and i am keeping updated the development branch on github with all the new changes i made, you can find it here to see which is the stuff i am working on: https://github.com/ITzTravelInTime/TINU/tree/development
2)The final release 3.0 will came after beta 4 and after a final beta 5 (which will facus on bugfix), i hope to get this done by the end of sptember, but i still need to spend time debugging and doing what's left on my todo-list.
3)The release after 3.0 will be a total conversion of the 3.0 release to swift 4 or 5 and ported to xcode 11 or 12 (in case of xcode 12 i will absolutely try to get the thing working on Apple silicon Macs using an universal executable, but i will need to put my hands on an apple silicon machine somehow to do debugging, or it will be just pubblished as untested together with the intel-only binary)
Just FakeSMC, or Kexts aren't injected in general?
In some instances it loaded the kx audio driver (which i use for my sound card) but it seems to me that important kexts are not loaded, i will try different configurations to try to have kexts loaded, but for now i don't see any loaded kexts
EDIT:
I switched back to clover 5119 modded version and to use the config.plist kernel patches and it seems that i have kext injection back i am still trying with different kext combinations. About the kernel panic if you read the symbols it looks like an error when retriving some pci device/pci bus features, so perhaps a custom ssdt is needed afterall? wiredly it's just a big sur problem, for sure some stuff about how the os treats pci devices has changed
EDIT 2:
Even with kext injection working and fakesmc or virtual smc loaded i still get the same kernel panic, so has anyone ever tryied installing big sur on x99 using clover with any success?
Doesn't look to bad, you might try to disable RebuildAppleMemoryMap and SyncRuntimePermissions as well as DevirtualiseMmio. If you can't get past boot.efi Verbose, reenable DevirtualiseMmio. For further debugging you will have to get the OpenRuntime Debug log. I'd recommend to check ACPI and BIOS Settings first. Which BS Version are you trying to boot? Does boot.efi console logging show, that the prelinked kernel is being used?
I got this same issue with beta 1 and beta 3 which i have installed on an ssd unsing my macbook pro, i took those ocquircks setting from an oc config file used in a system similar to mine, i have also upgraded my clover kernel patches according to the first post of this thread, the bios settings are fine, i can use all of the previous macOS versions just fine with the same clover efi folder, and i don't see any acpi error in the preboot and during early boot. i will try modifing the ocquircks with the settings you mentioned and then let you know, i have also read something about intel HEDT systems requiring a custom SSDT-RTC0 on big sur because of oem motherboard vendords having some limitations with their rtc implementation, but i don't know if this applys to gigabyte mobos as well and how the ssdt sould be made in my case (https://dortania.github.io/Ope…otloader-and-config-plist)
EDIT: No difference by changing the ocquircks settings i just get the same kp, and i have also seen that i need the DevirtualiseMMIO in order to boot
EDIT 2: i managed to film the boot process using slow motion and i saw that fake smc can't be loaded, i thought that just virtual smc was the problem since fakesmc booted successfully big sur on my socket 1150 machine but i guess i was wrong.
This looks like either an OCQuirks configuration issue or ACPI problem. Check early boot process to make sure that no ACPI Errors show up. I'd need a little more information about your current configuration in order to pinpoint OCQuirks issues.
Have you had a shot with most recent Clover master? Kext Injection should work at least when forcing prelinked kernel now, so no more Kernel UserPatches necessary (You might consider adding automatic NVRam Injection for the necessary values to force prelinked for now as I have done in my Clover Mod). Can't tell about KC implementation though, haven't had the time to take a look at it yet. 5121 should be able to detect the KC Header in order to execute patches but I don't know if these actually suceed or if there are incompatibility issues with Clover or even the KextInjection mechanism itself when using KernelCollections.
I am using the modded version of clover 5119 with the ocquircks driver, this is my ocquircks plist file
I get this kernel panic when trying booting on my x99 system (featuruing an i7 5820k, a gigabyte x99 soc champion and an r9 280x)
I upgraded my catalina efi folder according to what i read here and i have seen that i got kext injection to work properly but i can't boot because of this.
